Chris Savoie, director of product strategy at Workfront, has spent the past 12 years leading Agile IT teams. While the productivity improvements of Agile methodology are well documented, we rarely hear about how it affects IT morale. Here, Chris shares five things he learned along the way – and tell us how you can apply these to your own Agile dev efforts.

Chris Savoie, Director of Product Strategy, Workfront

October 10, 2016

6 Min Read
<p align="left">(Image: Sergey Khakimullin/iStockphoto)</p>

7 Dev Team Secrets IT Managers Need To Know

7 Dev Team Secrets IT Managers Need To Know


7 Dev Team Secrets IT Managers Need To Know (Click image for larger view and slideshow.)

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.

Over the past 12 years of working with and leading Agile IT teams, I've become interested in how Agile affects team morale, individual job satisfaction, and overall happiness at work. Given that I once spent seven years working with the federal government at NASA -- in the least agile environment you can imagine -- I do have a baseline to use for comparison's sake.

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.

Since then, I've settled into a happy middle ground, where our strategy is a little bit waterfall to meet long-term business goals, but our development processes are fully agile in order to let the market drive our outcomes.

Here's what life looks like in the happy middle:

1. Prioritization Is Simpler

I never want to prioritize things in any way other than a backlog. Backlogs should be up there with fire, sliced bread, and beignets in the life-changing invention hall of fame.

They're not only useful at the office. Recently, when my wife was feeling overwhelmed by a long list of to-dos to complete before our baby was born, what did we do? We established a backlog, performed a high-level prioritization, and stack-ranked the mediums and highs.

We got more done that weekend than we'd accomplished in the previous three months. We even did daily stand-ups for a couple of weeks to keep the momentum going.

2. Everyone Is Armed With Information

Yes, the stand-up meeting is a powerful thing. I've determined 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

In my view, 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.

About the Author(s)

Chris Savoie

Director of Product Strategy, Workfront

As Director of Product Strategy for Workfront, Chris Savoie leads core product research, strategy, and development. His previous professional experience includes stops in the oil and gas industry as both a product manager and a software consultant. He was also an instructor supporting human space flight activities at NASA's Johnson Space Center. His favorite numbers are 3, 7, 10, and 21.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights