Once You Go Agile, You’ll Never Look Back

Once You Go Agile, You’ll Never Look Back

beach-ocean-people-1756665

Long before I was an agile coach, I spent my working days as a project manager (PM) in a traditional project setting, usually operating within an ironclad waterfall domain surrounded by rigor, process, tollgates and heavy oversight. Today, I do something different, I train and coach software development teams and organizations on how to be more agile. My daily work evolves around change, spending part of my day focused on helping people accept change and another part coaching people how to handle change.

The project management style I used earlier in my career differs greatly from the approach I use today. Back then, being a PM meant that you had to follow the “plan” and avoid change (change was bad). This is known as the plan-driven approach of project management. Eventually, I became certified with the Project Management Institute as a Project Management Professional (PMP).

It was late 2006 when I first discovered the agile world of software development and project management. My discovery was brought on by my desperate search to find a way to help me deliver a critical project deliverable to my customer within two months, and adapt the project’s plan along the way to match the customer’s needs as they evolved and matured.

After making that discovery and committing to agile, I never turned back. After experiencing the successes with agile, the old way did not make sense anymore nor did it match my style of work. The old way never worked as well as agile, and could never deliver results so quickly or regularly. One of secrets of agile is that is all about the people involved.

Why it’s better

Agile projects that follow an agile methodology like Scrum or eXtreme Programming (XP) are vastly different in composition and operation than ones following the waterfall model. A team’s composition and operation is one area of difference. Before getting too deep into team dynamics, it is important to provide a little background on waterfall and agile.

Many agile coaches like me have experience in the traditional “waterfall” world, and transitioned to using agile methodologies in place of the traditional approach to project management and style of working with teams. Waterfall has been around for a long time, and in 1970, Dr. Winston Royce described in his paper “Managing the Development of Large Software Systems” that the waterfall model is somewhat flawed in nature for software development projects. Waterfall is a set of project phases that flow into one another like a waterfall: requirements specification à design à construction, integration à testing à installation à maintenance.

Software development work within waterfall is done in silos, and typically passes from one group to another as the work moves through its phases. The team doing requirements may not work with those doing design. The teams doing design may interact very little, other than at a phase tollgate, with those doing construction, and so on. Waterfall handles the work done in each phase distinctly, and draws upon the resources and skills of those specialized in that phase’s domain. For example, a business analyst will work in the requirements specification phase, whereas a developer will mostly be involved during construction.

The waterfall model relies on knowledge at the beginning of a project. Team members build a large plan and design upfront. This large upfront design requires a lot of time and resources to research, analyze and elicit requirements. It also assumes that we know everything in the beginning and that we will not be changing anything along the way. Agile does not operate this way.

In an agile project, the design emerges over time through small increments delivered to the customer. Agile practitioners believe that the best designs evolve and emerge through customer collaboration and the utilization of cross-domain teams working closely together. An agile approach identifies the large capabilities of a product and delivers the highest valued pieces first. The team breaks down the larger capabilities into finer details just prior to working on them. The product is handled in small chunks, and is built piece by piece in short iterations (usually two weeks in duration). On a daily basis through the project, the customer gives feedback and the team and customer work closely with each other. The agile cycle goes like this:

  • Identify the small product chunk to be worked on in the upcoming iteration;
  • Work with the customer to elaborate the details;
  • Build the product during the iteration;
  • Get feedback as often as possible and adapt the product during the iteration;
  • Demonstrate the product at the end of the iteration;
  • Hand off the product to the customer; and
  • Repeat the process for the next iteration.

The people factor

Agile is a powerful methodology when applied well in a project environment. One of the aspects that make it successful is the way people operate while using agile. Since the iterations are short, and requirements evolve during the iteration through close customer collaboration, it is crucial that teams work well with one another and there is an open line of communication between them. Operating in phased-based silos as seen in the waterfall model will not work with agile.

In agile, there is no time to do hand-offs. Designers do not work alone and away from programmers, programmers do not work in a vacuum from testers, and so on. Instead, during each iteration team members work together to create the design, build the product, test its functionality and demonstrate it to the customer. In this case, a cross-functional team comprised of designers, analysts, programmers and testers is the best way to manage the work. The entire team is present during planning with the customer, so they can bring their own expertise and domain knowledge to the session.

Every team member has unique experiences and expertise. The agile team learns from each other during the iteration. Through close collaboration, constant feedback, and knowledge sharing, team members become more effective and content with their work. All of the work that would have been done in separate phases is now melded together into two-week iterations.  There are a few ways to bolster the effectiveness of an agile team:

  • Co-locate the team – if possible, move the team together. The best agile teams are those that sit next to one another. This breaks down all communication barriers and takes the guesswork out of where people are and what they are doing.
  • Team autonomy – let teams make their own decisions about direction and how they want to operate. This will empower the team and will allow them to find their natural way of working with one another.
  • Limit other work – teams that can be fully allocated to an agile project are oftentimes the most effective. However, allowing someone to be 100 percent allocated to a project is not always the reality. If the person cannot be 100 percent on a project, then limit other work as much as possible. Since iterations are short, it is important that team members are available as much as possible to one another.
  • Clearly define the objectives – teams that trust each other and are autonomous will figure out the best way to meet their objectives. Each iteration should have a clear development goal that can be achievable and kept small in relative comparison to the whole project.
  • Train them – give team members knowledge about agile that they can use. It is important for all team members to understand the basic tenets of agile.

Not without challenges

There are many challenges with teams operating in an agile project environment. Some challenges come from within the team. Some team members may not like working in a cross-functional team, and others may not be able to be dedicated to the team for the majority of their total work allocation.

Other challenges can come from the organization. Management may not fully allow teams to be autonomous, because they are not trusting of the agile process. Sometimes the reporting structure of a functional organization is restrictive and places limits on team flexibility or communication.

In my experience as an agile coach and trainer, I have found that the vast majority of projects and people who have moved to agile have found the benefits far outweigh the costs of change. I have seen teams become more productive, happier and willing to take on bigger challenges. Breaking down the cross-domain barriers and allowing the agile process to take place will greatly improve project outcomes and product quality. To me, agile is the more natural way of building software.

Leave a Reply