We underwent a transformative change in our company two years ago when our organization went Agile. This change has been amazing in many ways, my personal favorite of which is the alignment throughout the entire enterprise on Engineering priorities, and the understanding of tradeoffs that go along with prioritization.
But there is a downside to Agile that we had not anticipated, and it is part of the reason that our Agile Transformation Lead says that “Agile is Fragile.”
Our Engineering leadership team (Management, Release Train Engineers, Architects) started to notice some of this as we became a more mature Agile organization. But first, a bit about developing software under a waterfall approach.
Agile, and specifically Scrum, avoids many of the waterfall pitfalls, but one of the few good things about waterfall is that projects have a finish line and with it a sense of accomplishment when you hit that date.
Combined-Effort “Wins” Feel Good
Sure, waterfall sucks for product development; everyone knows that. But one thing you can say for waterfall is that the entire team is marching toward what is typically a huge release that is due at some point far off in the future.
Now granted, you’re going to deliver something completely different from what the customer expects, will be unable to incorporate much learning into the process because the date isn’t changing, and you’ll probably miss the date and have to make up a new date. But there is something special about having that milestone looming and trying your damnedest to hit it.
The team typically puts in a crazy amount of effort, eating pizza together every night and getting little sleep. And when you do (finally) hit that date, there is a huge feeling of accomplishment, including a big celebration which includes the all-important recognition of a job well done.
So in terms of value to the customer, waterfall often fails. In terms of sustainable pace? Also not good. But in terms of coming together to achieve a common goal? Really good.
We follow the Scaled Agile Framework at our company, so the teams (by Release Train) do quarterly planning composed of Features (driven by prioritized Epics), which breaks down into Story backlogs for the scrum teams.
The Features tend to be what I would call bite-sized, so they are always small enough to fit into the quarter, and there tends to be somewhere between 10-30 Features per quarter per Release Train. Bite-sized work is great for our teams and our customers because they provide an opportunity to learn, pivot if necessary, and more continually deliver value.
The down side as I see it, and as you can now guess, is that there is never a “big win.”
Sprint after sprint, the teams crank out more Stories, which contribute to completing these Features. There are always more Stories in the backlog, and never a situation that we saw in waterfall with a huge deliverable that everyone can celebrate.
Blogger Alan Atlas likens it to a pond in this post, though “calm” may not be the word I’d choose. But complacency can set in; going through the motions of planning, developing, retrospecting, planning, developing, retrospecting, and so on.
The ceremonies get dull, less energy goes into continual improvement, and the lack of highs from big deliverables has the potential to create a feeling of an endless grind.
In a world of two-week sprints, milestones can be a way to achieve the feeling of accomplishment that comes from hard work over a longer period of time, and they give the team and the organization something to celebrate.
How can you prevent this slow transformation of high-energy developers into the walking dead? You’ve got to manufacture milestones.
How to Fabricate Milestones for Agile
How do you manufacture a milestone you might ask? Well a great way to establish a milestone is to follow a practice that the team should be using anyway, which is to capture the usage (data) of their software and create goals based upon that usage.
Creating a milestone driven by data can create substantive victories for the team.
A focus on metrics such as error rates, uptime, account adoption, throughput , clicks, etc. are all potential examples.
The team can cut those error rates in half, or add a “9” to the uptime, or double the current account adoption, or increase your requests per second by 50%, or any other important measurement which serves as a confirmation that the team has delivered value to the customer (or at least a proxy for that confirmation).
Great teams will create dashboards around these metrics and watch them day after day as they improve the system. When they achieve the milestone, celebrate it! Make a big deal out of it with the entire organization, not just with the team, just like you probably did after that monster release from your waterfall project.
Given the choice, we would choose Agile every time.
Our Engineering organization has been improved in countless ways, as has the rest of the organization. In order to combat the complacency that can set in on scrum teams, we have to create milestones that the organization can celebrate.
Using the data that the team is (hopefully) collecting anyway around their product, choose an important milestone that you can use to stick a flag in the ground and say “We did this!”
Your team will appreciate it, the organization will get excited about it, and everyone will stay motivated to tackle that next mountain!