Agile development practices have been around for years and there seem to be evolutionary new flavors introduced almost daily. As a testament to its mainstream appeal, even PMI is releasing an Agile certification, opening the floodgates to an organization that has long been seen as the keeper of the Waterfall keys.
As more and more organizations scramble to work in an Agile way, it seems that there are as many failed or ailing attempts as there are successful ones, though I have seen studies putting the successful adoption rate between 20 and 75% — a huge range to be sure. Looking in from the outside and having worked with organizations making that jump, I have seen a number of trends that I want to call out. Unfortunately, these are not cited with scientific statistical rigor, but I am hoping they are helpful nonetheless.
Just for full disclosure, I manage a Project Office responsible for delivering a wide variety of development projects in a consulting environment. This affords a certain perspective favoring the business outcomes of adoption rather than the technical ones. Further, I am focused on using the correct methodology to meet the situation while building reusable organization assets and collecting performance metrics. So with that, here we go!
- Treating Agile as just a Development Practice rather than a Business Process — Working in an Agile way requires an understanding and realignment of your project selection, portfolio management, budgeting & funding process, requirements gathering and acceptance process. Assuming that none of the business functions will be affected and that just the development teams will work in an agile way leads to a cognitive disconnect between the business and the delivery side — a gulch that is often there before you even try to implement agile. This is especially true when Agile is a grassroots effort that is greenlighted without support.
There needs to be a clear understanding of what the organization will get out of the new process and where there are opportunities to remove barriers before they are even an issue. Failure to address these alignment issues will just lead to communication gaps and the business side demanding that you revert to the pervious practices.
- Using Agile Coaches who don’t have a Stake in a Delivered Product — Bringing in an agile coach can be a huge benefit to your organization as teams usually learn best by doing. Usually a team (and the business side) will need to go through a full release cycle before the process really sinks in and an agile coach can help you to identify risks and guide the team through this. Unfortunately, the coaches often will act as academics or shamans who want to sit in an advisory role with no real team deliverables.Always insist that the coach work with the team in a real-life product cycle and plan for the learning curve in your capacity planning. You’ll get a ton more out of it and will see better adoption. This also means that you’ll be working with a coach who is a practicing professional and able to get things done. Better yet, tie compensation to adoption metrics or success criteria for the release.
- Forgetting to do Sprint and Release Retrospectives — One of the biggest benefits to agile is the virtuous cycle of continuous improvement, building on the lessons from the previous iteration. When the going gets tough or there is a perceived lag in the project, this is usually the first area to be cut. This just bleeds the value out of the Agile process and perpetuates problems rather than learning from them. Repeat after me… “I will not cut Retrospectives! I will not cut Retrospectives. ” (Especially as they pertain to capacity planning.)
- Treating Agile Development as a Replacement for Planning or Requirements — Organizationally this is usually in response to poor planning or badly defined requirements. The thinking usually goes, “We end up in trouble trying to deliver against half-baked specs and unrealistic project plans, but if we have neither of those things, we’ll be free to just deliver (and no one can say we failed.)” That last part is usually subconscious.
If you can’t come to an agreement with the development team as to what you want to deliver or aren’t willing to staff the team appropriately, there is little hope that working in an Agile way will improve things much. Yes, letting the team interact with the business directly will help to specify what is asked for, but in my experience, the issues usually lies in poor arbitration between parties with conflicting needs. Agile don’t directly fix that. Failure to address the root problems can lead to additional churn and rework.
- Not Having a Vision of Done — This one might be a bit contentious, but every project needs a picture of done with acceptance criteria associated with it. Usually this is a set of stories, grouped into a release, with UAT criteria associated with them. As a consultant, I usually have to be much more specific than that as building a backlog against unlimited time and dollars usually doesn’t get us invited back. Just make sure that you have a clear picture of whether done is “good enough with a list of nice to haves” or if there is a more stringent criterion that you need to be shooting for. Not identifying that up front and structuring the team for it leads to bad things.
- Not Preparing the Business for Participation — It is essential that the business side of the organization have daily participation in the project. Most likely, they are used to an intense upfront requirements phase and then are ignored until UAT. Sure, they will still need to have initial engagement as the Product Backlog is built and the release plan made, but the ongoing participation often comes as a surprise and must be managed carefully. Often they are happy to do it, but springing that on them with little notice or input can hurt feelings and lead them to a feeling that the development team is needy and unsure of themselves, rather than following a prescribed process.
- Starving the Factory — Trying to treat each iteration as its own waterfall or expecting that all story elaboration will be done in sprint often leads to work starts and stops — especially as a team scales. Planning your stories and digging into the business drivers and needs one sprint ahead allows you to engage with your QA teams and Business Analysts to provide the fuel that the development team needs to keep the factory rolling. This is not a substitute for having the developers interact with the business directly, but it does take some of the burden off of them and can leverage the specialized skills of your BAs and QA folks. For me, this seems to be the best blend of sustained agility and supporting a scalable and even geographically distributed team.
- Expecting an Agile Experiment to Scale — So you wanted to prove that Agile can work and will be able to be adopted into your organization. You’ve pulled 4-6 of your top architects and high-potentials into a mini project because you expect them to be leaders of additional projects when you scale. The project goes great, the team blazes through the deliverables, and you’re ready to go! Right? RIGHT?
This is a great way to train leaders in the overall flow and tenets of Agile, but it doesn’t always paint a good picture of how this will work in a real environment, especially if you work with distributed teams, outsource groups, or 9-5 developers who are phoning it in. Once you have those leaders, make sure you do a real PoC with a realistic team to work the kinks out, especially around communication and code acceptance.
Wow, that was more typing than I had anticipated and I am sure as soon as I hit publish, I’ll think of 5 more that I just have to include. Maybe there will be a part 2. Hopefully this will save you a few headaches and help you to navigate the agile waters.