Agile Methodology is considered the greatest project management tool to ever exist – so why is it so hard to get it right?
I always start by asking two simple questions: “Why are you using Agile and how do you know if it’s working?”
I rarely get a confident answer - even when asking the same decision-makers who implemented Agile themselves!
Agile Methodology is a set of concepts (rather than a strictly defined process), which leaves a lot of room for interpretation. Every team has their own spin on how to achieve a proper implementation. It was originally ideated in response to "waterfall" project management - loosely defined as planning an entire project an advance. Although it worked so well in existing industries, software project management required a new flexibility for two main reasons. First, projects missed every release milestone as there are too many complexities and unknowns that arise during the development process. And Second, the business requirements for any software rapidly change to chase the most efficient solution.
Enter Agile - an ultimately flexible form of software project management... built on the foundation that we cannot expect to fully understand the full scope of the work required. Accepting that our estimated release schedule is in fact – an estimate – is what gives the Agile methodology its power.
Accepting that our estimated release schedule is in fact – an estimate – is what gives the Agile methodology its power.
At it's core, a solid Agile implementation requires the project be broken down into short term goals spanning 1-2 weeks – each of which are able to be tested and released individually – and progress against those goals is tracked in regular intervals. Testing and releasing functionality in these regular intervals (dubbed "Sprints") enables the business side to tangibly assess the project's progress. A daily check-in within the software team identifies issues, misunderstandings, and new complexities at the earliest possible point. Project managers adjust individual workload to absorb the delays as much as possible and at the earliest time. This all adds up to confidence in the release schedule from both business and tech teams.
The most common mistake in Agile implementations is using Sprints to evaluate individual performance.
The most common mistake in Agile implementations? Using the progress towards each Sprint goal to evaluate individual performance, instead of for achieving a reliable release schedule (the true goal of Agile). If we agree that software estimates are inherently going to be inaccurate, why should we grade whether or not the engineers are able to complete their short-term goals within the estimated timeframe? It is, after all, an estimated timeframe… right?
For the software team, the most critical KPI they get is the average inaccuracy of the estimates themselves. Let's take a simplified example. If a team’s estimates are on average 15% high or 20% low, you gain accuracy by adjusting the schedule by the same amount. After working together for just a short time your team will be able to use weighted estimates to gain incredible accuracy in predicting the completion of short-term and long-term goals months in advance!
So what's the true value of Agile? Simply put, it is organization-wide confidence in a release date six months away.
Agree? Disagree? Drop me a line and let me know how you implement and measure Agile on your team!
