Agile processes are known to make IT teams more responsive, more productive, leaner, and more efficient. Those are all great benefits for the organization as a whole, but they aren’t exactly at the top of any developer’s perfect job wish list.
It doesn’t get more waterfall than this: Prior to updating software on the International Space Station, a 220-page system requirements specification (SRS) would be written, often years prior to software development. Then, developers followed these specifications to the letter, regardless of what made sense — and even though they literally never interacted with space, space station hardware, space station hardware engineers, astronauts, flight controllers, or instructors.
Once the code was written, it was tested twice by testers who never interacted with any of the above folks, either. Typically, years later, it would be uploaded to the space station computers by flight controllers. By this time, often the writers of the spec and the developers were gone, so no one had any idea what the original intent was.
[Don’t do it like this. Read 8 Ways To Fail At DevOps.]
In contrast, my next job was at an oil and gas startup. Boy, were we agile! Nothing makes you cling to Scrum or Kanban quite like chasing revenue to keep the lights on and the keyboards clicking.
Here’s what life looks like in the happy middle:
1. Prioritization Is Simpler
Established a backlog, perform a high-level prioritization, and stack-ranked the mediums and highs.
2. Everyone Is Armed With Information
If you start doing a daily stand-up in any circumstance, you learn a lot. Everyone on the team is continuously armed with information, which keeps showdowns and battles at bay. (Kind of like the peace-through-strength approach.)
I can say in all seriousness that brief five- to fifteen-minute standup meetings every day — in place of hours-long status meetings several times a week — have changed my life. Questions like how XYZ is project going, why something happened, or who was assigned an action are almost never asked — because everyone already knows. The team feels unencumbered and continuously informed, and the work can hum along at a steady pace.
3. Expectations Are Aligned
The root cause of all unhappiness comes down to two factors: poorly set expectations and unmet expectations. Guess how often the first one causes the second?
Agile does four things that help with this:
- The backlog sets clear expectations, especially if the team has bought off on an achievable scope in a sprint.
- The daily stand-up allows for resetting of expectations often enough that misalignment in expectations can be corrected quickly inside the team.
- If you’re also getting feedback from your consumer after each sprint, you can course correct continuously to positively impact your market. (No more waiting for months or, in the case of NASA, years.) The earlier feedback is incorporated, the less costly it is.
- If you’re honest in your retrospective and you hold them often enough, you kill small problems before they become big problems.
4. There Are Opportunities to Gamify
Agile is the only project management approach I know of wherein a deck of playing cards can be a seriously useful forecasting tool. I’m talking here of planning poker, which adds an element of fun to the process of assigning story points, among other benefits.
It also helps eliminate unconscious bias caused by “anchoring,” in which the first number spoken tends to influence the estimates that follow.
It’s important to have fun in other ways, too. In situations where a team gets ahead in its sprint, how is it rewarded? With more work falling into its members’ laps?
While working with a previous group, I decided to find out which KPIs were the executive team’s top priorities, and attach them to every story on our backlog. Then I told my devs that after the exec team sees us exceeding a threshold they care about, then we could work what we care about most for the rest of the sprint.
It turned into a bit of a game. I would try to get the highest KPI/story point ratio into each sprint, so we could devote more and more time to the fun stuff. Once, we managed to exceed the KPI threshold in the first five minutes, which meant we spent the rest of the sprint on tasks the team picked to do.
Thanks to this simple game, we made several other teams happy. We doubled our KPI threshold, we got the chance to relax on low-pressure work for a week or so, and we even got a little bit ahead on the next sprint.
5. There’s Always Cause for Celebration
Because Agile is about setting and continually checking off small goals, the opportunities for rewards and revelry are plentiful. We celebrate the hell out of meeting our commitments. We try to observe big achievements — like a major market-moving piece of code — and modest victories as well.
A few months ago, I asked a team to hit a pretty aggressive date. When they did it, I wandered into their stand-up meeting and thanked them, recognizing that I’d asked them to sacrifice to meet the goal. Their response? “Show me the money.” We ended up settling on a lunch for the team at an all-you-can-eat Brazilian steakhouse.
Can Agile Really Make Teams Happier?
Absolutely, unequivocally yes. The proper blend of Agile methods and mindset, keyed in to the company’s overarching waterfall goals, can maximize collaboration and minimize confusion and conflict.
Admittedly, most developers don’t consciously seek out positions offering excellent prioritization, transparency, alignment, gamification, and regular celebration. Apart from Brazilian barbecue, these usually aren’t the sexiest perks on offer.
But when all five elements are in place, anchored by the effective use of Agile processes, the members of your IT department tend to be less stressed, more empowered, and less likely to spend two years on obsolete space-station software. In other words, they’re happier. Happier dev teams not only stick around longer, they tend to make the project managers and executives happier, too.