Building Agile Teams: It isn’t just for software development
Building Agile Teams: It isn’t just for software development

Teams are becoming the basic building block of organizations. Everyone is part of a team, or teams. Your immediate team maybe part of a bigger team, and you may belong to several small teams. Despite the potential consequences of teamwork, organizations are turning to teams to solve complex problems that cannot be solved by individuals. So with the ubiquity of teams, the question is: how do we manage teams effectively?

Although there are several potential answers to that question, one solution is to learn from a collection of methods created by software development teams. Agile development methodologies were created as more adaptable processes that build usable product at the end of short iterations. I am nowhere close to being a software developer, but I am sold on the merits of agile teams. I’m sure that software developers had very clear objectives in mind when creating these methods, but what they might not have realized is how well agile methodologies tap into so many behaviors that are conducive to effective and efficient collaboration. No matter what kind (or kinds) of team(s) you are in, you can benefit from implementing several of the principles and practices of agile development.

What exactly is agile?

In software development, agile is a blanket term for several iterative and team-based methodologies that provide an alternative to the dominant, rigid, linear processes (e.g. waterfall). The term “agile” came from a gathering in which representatives from many alternative software development methods (e.g. scrum) met and agreed upon four core values, which they called the Agile Manifesto. Although the exact wording of these values probably seems irrelevant to many types of teams, the ideas behind them are important for any team to be adaptive. For example, “customer collaboration over contract negotiation” is an important value for a team of business consultants. Your team may be hired to redesign a training program, but after analyzing the company you realize that the real problem isn’t employee skill level, but managers not giving clear goals and direction. If your team does exactly what the company asked you to do and makes the training program, then performance won’t improve and that company will likely not hire you again. All of the values in the Agile Manifesto could similarly be applied to almost any type of team.

Agile methods

Two of the more popular agile methodologies are scrum and kanban. Scrum uses a set process of fixed length iterations, called sprints. These sprints are usually around two weeks long and follow a procedure of:

  1. Initial planning,
  2. short daily meetings (stand-ups),
  3. sharing work that was completed at the end of the sprint, and
  4. reviewing things that could be improved during the next sprint (iteration review)

In the initial planning meetings, the team creates a list of everything that needs to be done, places those tasks in a backlog, and chooses a set amount of tasks that will be completed during that sprint. One of the fundamental principles of the scrum is that once the sprint is set, new tasks aren’t added.

Kanban is similar to sprint in several ways (e.g. planning, daily meetings), but it is more of a continuous process than sets of short sprints. Instead of focusing on moving the right amount of work out of the backlog to work on during a sprint, kanban uses a continuous flow of moving tasks from the backlog. The key to this method is that there are a limit to the amount of tasks that can be in progress. Once one task is completed, then and only then can another task be moved out of the backlog. This is visually depicted by a kanban board that lists the backlog and tasks that are being completed by the team. It can be either a physical board with sticky notes that move from backlog to in progress to completed, or a virtual version like Trello or Pivotal Tracker. This way team members can see where tasks bottleneck and reallocate resources to fix these bottlenecks and create a more streamlined process.

Some Transferable Practices

Although every part of the agile process doesn’t translate as easily outside of software development, there are several practices which capitalize on principles of exceptional team dynamics. Many of these practices directly relate to team innovation, and others are simply fundamental for any type of productivity. Each can be implemented in slightly different ways, as long as the fundamental principles are still intact. (Aspects I consider fundamental are in bold).

Planning meetings

Before the beginning of each project or sprint, the team needs to take time to plan the workflow. This is fundamentally a goal-setting process in which the team decides how and when the work will be accomplished. Goal-setting is key for both team and individual performance, so taking the time to set goals up front is crucial.

During the meeting, the work is broken down into tasks, and tasks are organized by importance in the backlog. The process of arranging all of the tasks also sets the groundwork for easily relating the project to the vision, or broad objectives, of the organization. Even though a planning meeting doesn’t necessarily require it, the team leader taking time to explain the purpose of the project and how it fits into the overarching vision of the organization is a best practice that will motivate the team and encourage innovation.

Stand-ups

Having short, frequent meetings encourage open communication among team members. I know that we all hate coming in for long meetings that just waste the day, but that is the beauty of a stand-up: it is short and to the point. Everyone shares what they completed since the last meeting and what they plan to do before the next meeting. This is also the perfect time to find bottlenecks in the process and let people know if they need to do something in order for your work to move forward, or ask for help moving forward on a task that had an unexpected problem. Open communication is foundational to effective team performance.

Stand-ups also encourage practices of effective team goal-setting. The goals are completion of specific tasks, the clear timeframe is the next meeting, and the goals are public, which increases accountability. Goal-setting is an excellent motivational tool that leads to better performance in almost every context.

Remember that we aren’t all software developers, so you should implement stand-ups in a way that is most effective for your team. If your work requires larger chunks of time with individuals working on one task, then daily meetings might not be beneficial, especially if there is nothing new to report. It could be demotivating for one team member to continuously say “still working on X.” Try out different frequencies, maybe weekly, but make sure to keep the elements of open communication and public goal-setting.

Kanban boards

Visual boards that depict the status of each task that needs to be completed are beneficial for many different reasons. First, kanban boards list all of the required tasks, which allows people to understand the significance of each task they do and how it relates to the larger project. This allows the team as a whole to have sense of task identity, or the feeling of ownership that comes with watching a full product be developed. Task identity is one of the core job characteristics that allows people to experience meaningfulness in their work, and thus is an important motivational tool that increases both performance and job satisfaction.

Second, kanban boards allow for more effective communication and collaboration. They show where work slows down so that one individual doesn’t get completely overloaded while another is sitting around waiting to contribute. If you look at the board and see that your teammate is struggling, you can easily step in to help and make the entire process more efficient. Of course, this works best when teams have interchangeable skills. In a more cross-functional team, like we have at Tilt365, there are certain tasks for which I can contribute pretty much nothing, but I can look for alternative solutions. For example, when I can see how many to-dos that Bob has on his board, I realize that creating an image for my blog is probably a low priority. I certainly can’t make the image myself, but I can ask if there is anything that was originally created for another purpose that could be used.

Visual depictions of work also create accountability to the team. One problem with teamwork is that some people may work less hard because there is no individual accountability. Sometimes it stems from intent to benefit from other people’s work (free-riding), while others perceive their teammates as lazy and don’t work as hard so as to match the low effort of others (sucker effect). Either way, the visualization of each person’s accomplishments create an accountability to the team because everyone will know if an individual is slowing the team down.

Iteration Review

At the end of a set sprint or large milestone (depending on your method), there is a meeting after the presentation of the results to review what didn’t work during that iteration. This is the perfect time for feedback! Many companies have begun dropping annual performance appraisals in favor of more frequent feedback, and iteration reviews are the perfect time to give feedback to the entire team, and hold the team leader accountable for actually giving feedback! Feedback is key to improving performance. People want to do well, and it is extremely demotivating to not know whether you succeeded in meeting your goals. It is difficult to improve if you don’t know how well you are doing.

Applying Agile

These are only a few easy practices that can be implemented to make our teams agile. Again, each team is unique, so the exact implementation of the methods do not have to be exactly how they were designed for software development. The key is to make sure that the process is conducive to goal-setting, encourages communication, creates a sense of task identity, promotes accountability, and has built-in feedback.