Over the years I’ve delivered hundreds of software projects into production, some big and some small, but all valuable to the organization. As a leader I honestly didn’t care if we used Agile or Waterfall, I was only looking for the best way to deliver.
Just to cover all the bases, Waterfall as an approach was first mentioned in 1956, according to Wikipedia. It assumes you have complete and total knowledge represented in written Requirements at the very start of the project and the remaining tasks of Design, Implementation, Verification and Maintenance are just obvious tasks to complete based on the perfect upfront requirements. If you’ve every done any small or large construction project on your house, clearly you know this model is flawed. In the waterfall model you’d NEVER make a second, third, fourth trip to the hardware store to get more supplies to complete your project because if you had perfect vision at the start you’d have a perfect shopping list. In contrast, Agile assumes you have limited knowledge at the start of any project and that you’ll have to adjust as you move forward and discover various realities. That seems more reasonable given my experience in construction projects of all kinds!
In addition to my personal experience, I’ve also talked to dozens of organizations that want all of the benefits of Agile but don’t want to change their culture, adhere to more disciplined development approaches or really even understand the software development process changes they are about to undertake with Agile. The most dangerous place you can lead your organization is into what is often called “Agilefall”, it’s not Agile but it’s also not Waterfall and it almost always ends very badly.
Let me take a moment and describe Agile from the 50K foot level.
At it’s heart, Agile is a metrics driven approach and there is only ONE metric you MUST care about, which is velocity. By definition a story represents a customer requirement and story points are just an estimate of development effort to delivery a specific story. So, velocity is the number of story points your organization can delivery with high quality in a given period of time. That’s your velocity. So if you have a software requirement that breaks into 50 stories and together the team estimates it will take 300 story points to delivery those 50 stories with high quality AND the team is delivering 30 story points every week, then you are looking at 10 weeks to get those 50 stories done, right? (300 story points / 30 story points per week = 10 weeks to complete). So why do you care about velocity? You care because predictable delivery in software development is the gold standard. Being able to have high confidence when a project will be delivered is extremely valuable to your organization, but you cannot know that without knowing your organizations aggregate velocity. As I said this is a VERY high level fly over the Agile forest and we’ll explore many more nuances in the coming posts, but sadly, very few organizations know their velocity so customers are constantly disappointed.
Here’s where the leadership part comes in, if YOU’ve promised those 50 stories in 6 weeks without understanding your team’s velocity then YOU, as the leader, have to own that error and inform whoever you promised that either they have to wait longer OR they have to trim scope. In Agile there is no “just get ‘er done” hero moves….that would be waterfall.
If as a leader you or the people you’re reporting to cannot tolerate that much honesty, then don’t do Agile. If your teams aren’t willing to transparently track their work so everyone knows if their true velocity and if the initial estimate was close to correct, then don’t do Agile. If you have customers who look at the software development process as a confrontational exercise with winners and losers then don’t do Agile, you’ll never get the collaboration you need to truly build the correct product. Go back to Waterfall.
So, why SHOULD you do Agile?
If you’re in the software delivery business you’ve likely see the chart below. It is the Chaos Report from the Standish Group. They survey thousands of projects and quantify what makes projects successful, challenged or failures. In this cart they have separated those metrics by development approach. Overall Agile was more than three times more likely to be successful and three times less likely to fail that Waterfall.
I’m sure that all looks good and what wise leader or organization would pick an approach that was three times more likely to fail? So, what’s the catch? The catch is that to actually do Agile and do it well your culture, both business and technical, is going to have to evolve and your going to have to actually track real development metrics and not just count the money. Additionally, if you are a very large organization and want to scale this to hundreds, thousands or tens of thousands of developers you need to adapt a Agile scaling framework, such as Scaled Agile and you are going to have to eventually change your project portfolio approach. So, it’s not easy but in addition to avoiding failure you’ll also go faster, waste less money on requirements customers really don’t want and have happier customers.
So next week we’ll explore how you get started, especially if you are a BIG organization.
Sue Rohde