November 25, 2015 // By Ryan Hanisco
Almost every organization I talk to is in some stage of rolling out agile development processes. The business case seems clear, agile has been around long enough to have matured into a coherent set of practices, and it just makes sense to many business leaders. Unfortunately, transforming this ideal into realized business value requires that many different areas of the business understand and invest in a new way to get things done.
In June of 2015, Forrester Research conducted a study on behalf of Magenic Technologies that talked with 100 business decisions makers to examine their expectations of agile development, the impediments they saw, and the ways that these challenges impacted their business. (See the full study here.) While there was a lot of really great data surfaced, one of the most striking gaps was between what these business leaded expected from agile and what they felt they actually got.
The number one benefit that business leaders expected out of an agile implementation was that this would bring improved technical quality. In fact, 74% of everyone surveyed felt that agile development would drive quality improvements. However, when these same respondents looked at the benefits they actually got, only 30% felt that technical quality was improved. This was the least often seen effect in the study. Clearly there is a huge gap here between expectations and reality.
Let me be the first to say that I don’t think that teams working in an agile environment produce poor code. I have seen agile be a transformative process that help teams work together in a more streamlined way and dramatically shorten the cycle between inception and the realization of business value. I do think there are a few things going on that drive that expectations gap in the technical leadership.
Know what Agile is and Isn’t – Agile is a way of working that makes the product king and helps the team to focus on the work that drives value early, respond to changing needs, and eliminate activities that don’t contribute to the final solution. Set your expectations on the things that matter like velocity, adaptability, and release quality. This helps the team become better and drives better outcomes.
Don’t Abandon Process that Works – Implementing agile is not an excuse to throw out all the strong coding practices you’ve been following. It simply gives you pause to evaluate whether something you are doing contributes. There is a temptation to treat a new process as a free-for-all, resist it.
Measure Quality Early and Often – Quality teams should be integrated into every step in the process rather than just as UAT in the end. If you weren’t doing this before, you can’t use the QA metrics before the implementation as a comparison as they are measuring different things. If your bug count triples, but the true cost of those bugs in rework, integration, and customer satisfaction drops by a factor of ten, you’re clearly ahead.
Set Reasonable Expectations – All teams go through an acclimation process when learning a new way to work. This means that there is some level of distraction that can happen early on as everyone comes up to speed and they learn to work with each other again. Put your metrics in the right place looking for rate of change (velocity, burn down, time to release, bug reactivations) and away from some of the more static metrics that might be PMO driven (lines of code, bug count, hours.)
The expectation gap for decision makers is real, but focusing on things that deliver value give you a truer measure of the team. Making smart choices about your development processes and measuring the right things will realign decision makers with the team as well as give you the biggest bang for your buck.
If you’d like to contact Magenic to learn more, email us or call us at 877-277-1044.