Some common pitfalls on the road to being agile

Through our business endeavors at Visionpace and conversations at the Agile KC group, it’s pretty common that I hear of another company ‘going agile’. The term ‘going agile’ could mean a lot of things, but in general usually boils down to the fundamental belief the company in question has some problems/pains with their current development process, and have heard some good things form other organizations that have successfully implemented some sort of SCRUM or XP process. They figure that if it works for Company B, it will work for us. The success of this transition, and the effectiveness of the resulting process, depends heavily on a lot of factors like the company culture, the people involved and the project in question. Unfortunately, when I follow up to these conversations after a short time, I often hear about the failed attempts and misguided efforts and abandonment of the pursuit. It’s not that agile development doesn’t work. The problems that companies encounter most of the time when undertaking an agile approach are related to lack of planning, communication and expectations.

I bring this up, because I heard of another company ‘going agile’ recently. I wish them well. I wasn’t able to ask find out some specific information like who they have involved in the process, what they are doing, what their goals are, the scope of the project, etc. From what I gathered it’s a small team working within an organization that may or may not continue pursuing agile depending on the results of this project. It’s a good business move, to test the waters before you commit the ship. But like any R&D project, there are a lot of ways to fail. So I thought I’d share some of the common pitfalls I’ve seen in the past with the initial implementation of one or more agile practices in a more heavyweight environment.

Some pitfalls, and ways to avoid them are:

The organization does not commit enough people to the process, or does not commit the right people to the process.

• There is a misconception that since agile is lightweight, it can be done successfully with just one or two people. While technically it can, a small group often lacks the different perspectives that help define user stories, tests and an overview of the entire process effectively.
• Another common misconception is that developer A knows the most about the business processes, so he/she should be the one working on the project. The risk is that developer A is not suited to working in an agile environment that is going to be in flux. There will also be a lot of other pressures on the team as they work to get the project going. Being a business expert is good, but being more geared to working closely with the rest of the team is more important.

        The best way to mitigate this is to have some goals specified (more on that later) and review how the members of the team individually and collectively are suited for achieving those goals. Also consider what skills and expertise the team is lacking and either get those skills or bring in someone to coach the team until they acquire them. In the past, Visionpace has successfully worked with companies through first three or four iterations, at which time the process was understood well enough by the team that we scaled back our involvement. Another aspect to consider is making sure that the people on the team are motivated. The risk is that you’re changing the way people work and the tendency over time is for them to go back to what they know. A motivated individual, or better yet a motivated team, can help keep the process moving forward.

A second pitfall is that the organization thinks that by using agile, they don’t have to do a lot of up front planning and design, and interpret that to mean that they don’t have to have a plan for how the process will work.

• Often times there’s one or two individuals that have some experience with or knowledge about agile development, and the assumption is that they will be able to implement the process.

• The problems arise when the team starts struggling to define/refine the process along the way (during the iterations when they should be working on code) vs. having an understanding of how the process will work at the beginning of the project and incremental reviews at specific times throughout the project. (Have a plan for how it will work, and set up times       throughout the project for reviewing and adjusting the plan.)

• Other times, an organization will try to stretch too far and incorporate too many agile practices too soon. Sometimes it’s better to include a couple of practices and get them established and then add a few more each iteration.

        To avoid this lack of process understanding pitfall, make sure the team knows how the process will work for this project and how the process will be inspected and adapted throughout the project. Remember, the goal of an agile process is to develop working software in a predictable and efficient basis. A secondary goal of the organization in these instances is to define an agile process that carried beyond the current project. Plan time to review and work on both goals, so they don’t compete with each other.

A third pitfall when starting to implement an agile process for the first time, or even the hundred and fist time is not having  realistic expectations.

• The success stories that are touted by the agile community are real, but they weren’t achieved overnight.

• Just like learning how to become a good .Net developer takes time and experience, so does learning to work in an agile environment.

• The results when implementing agile are not black and white, but rather seen in shades of grey. Small, repeated increases in productivity and code quality add up over time.

        The easiest way to avoid this goes back to planning and reviewing the process regularly. If the organization understands what the problems they are working to resolve are, and how an agile approach is going to resolve them, it make for a clearer conversation about when the results will be realized.  Clear goals are also essential in setting expectations.

A fourth pitfall is the organization not being flexible enough in it’s incorporation of the process.

• One of the underlying aspects of agile development is to inspect and adapt. A company that looks to have the process defined and documented at the beginning of a project and not subject to change over the project life cycle is going to have a harder time with the ‘adapt’ part.
• Additionally the process may require resources that were not considered initially.

As a rule of thumb people change, markets change, businesses change, requirements change; so don’t expect the process to be static. It’s a good idea to review the changes to the process, and if it helps, keep that static, but the process must be allowed to adapt to the environment. Also, remember that a different project in the same organization may require some changes to the process.  The team has to be given time to fail, review, regroup, recover and move on. They don’t have to be given carte blanche authority, but they have to be able to commit to the goals and in control of the process enough to support that commitment.