Part 2 - Is Agile the Answer? Are You Asking the Right Questions?
David Moses
Looking for a Sr Manager or Director level Product, U.A.T., or Program/Project Department leadership role.
In Part 1 we looked at ensuring Agile methodologies are adopted for the right reasons. At the end of Part 1, I noted that Only 16% of respondents to the “State of Agile” survey reported a competent level of Agile practices across their organization.
Today we're going to look at quick and easy ways to determine how successful your organization’s Agile adoption is going.
For those of you who haven’t jumped on the Agile bandwagon yet, this is still a good primer, while part 3 of this series is all about easy ways to determine if your organization is ready to take the leap to Agile.
Now let’s look at the 3 key questions ask that will help gauge if your Agile projects are successful.
- Are Agile projects discovering defects earlier in the lifecycle than traditional projects?With Agile, issues should always surface sooner.
- Am I seeing fewer defects when I compare my Agile projects with non-Agile projects? Agile should improve the quality of a project while decreasing the cost of fixes because they are found earlier in the project.
- Are business stakeholders generally more satisfied with Agile projects? Agile should help Business and IT better communicate expectations.
As I said in Part 1 of this series, one of the benefits of Agile is that it allows you to screw things up earlier in the development lifecycle. This may sound like a joke and a negative statement but it is actually an incredible benefit. Why? Compare the cost of fixing a defect in the early development stage versus one in production and you get the idea. Discovering defects earlier saves an incredible amount of time and money. Enough money to justify the money you will need to spend on more people to man all those Scrum teams.
Working in smaller and faster iterations allows not only defects to be discovered earlier, but it also enables the business to make small changes as the project progresses. Compare that with Waterfall projects where usually the first time the business sees the product is at the User Acceptance Testing stage after all the main development and bug fixes are done. Early and often “nudges” means the end result is something with much higher quality and finer tuned to the needs of the business.
Discovering defects and making corrections/adjustments earlier in the project should result in fewer overall defects and changes. This means less work for everyone in the end.
Now the big question. What do you do if you aren’t getting the right answers to these questions?
To quote a line from The Princess Bride “When the job went wrong he (Vizzini the self described genius) went back to the beginning.”
This is great advice because most issues with Agile projects stem from not having the proper foundation that we discussed in Part 1; Team discipline, good requirements, and great processes. Managing a development project is often compared to herding cats. Herding cats equates to not having an agreement between all project teams (especially their management) on what processes to follow and most often a lack of discipline on the part of one or more teams working on the project. Does your project seem like the Wild West? It probably is!
Agile isn’t difficult. Having the proper foundation isn’t difficult. Herding cats is very difficult.
The key is you have to make sure all the cats understand what is in it for them if they behave.
In part 3 we’ll discuss the questions you’ll want to ask if you’re considering adopting Agile.
For more articles on this topic and to join a group with the goal of solving the issues we all face in the Enterprise environment visit: Enterprise-Us. We really are in this together!"