5 Ways Agile Boosted Our IT Team's Happiness - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

DevOps // Project Management
09:06 AM
Chris Savoie
Chris Savoie

5 Ways Agile Boosted Our IT Team's Happiness

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 Agile affects IT morale. Here, Chris shares five things he learned along the way, and how his IT team benefited in the process.

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.

(Image: Sergey Khakimullin/iStockphoto)

(Image: Sergey Khakimullin/iStockphoto)

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.

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 ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Ninja
11/2/2016 | 7:23:00 AM
Maybe we are doing Agile wrong
My experience with Agile is that management only sees one aspect: deliver faster. The idea, that no matter which approach is used, the same amount of dev work still needs to happen, does not seem to sink in. Instead, expectations and dealines are unreasonable and entirely detached from reality, because management thinks they can just put stuff on a backlog and it will happen instantly because they determined that we are Agile now.

We were more waterfallish before with proper analysis and design upfront after which dev and QA had a clear picture and could make more reliable commitments. Now with the unfounded idea that documentation is a bad word, we get three and a half bullet points with vage functional descriptions for an epic (such as "user friendly messaging"). When requestion business analysis to be done the request is rejected because the BAs are busy assisting customers to get the half-baked apps to work at least a wee bit so that the customer is not asking for money back.

Agile and its various implementations is great in theory, but fails miserably in practice. Especially Scrum where so many meetings and so much process is introduced that it even requires a Scrum master to manage it all. Worst of scrum is the arbitrary time boxing. That works OK if everything in an app is a CRUD page, but most of the time it is not or it is custom development that has no relation to other work already done so that estimating and determining velocity is impossible.

For a while we moved to a Kanban approach without any short sprints, but only release date as a target. Sadly, that flopped as well once management notices that we now get stuff done and started to pile up an insane amount of work and setting deadlines that are months before release date. The result is kludged together stuff, anything quick'n'dirty has to do. Bug fixing is no longer done as that would take away time from stuffing in more badly designed features. Reason given: we hit it early next iteration. Of course, that never happens.

From my experience, Agile in reality is the death of quality - exactly the opposite of what Agile tries to accomplish.
Why 2021 May Turn Out to be a Great Year for Tech Startups
John Edwards, Technology Journalist & Author,  2/24/2021
How GIS Data Can Help Fix Vaccine Distribution
Jessica Davis, Senior Editor, Enterprise Apps,  2/17/2021
11 Ways DevOps Is Evolving
Lisa Morgan, Freelance Writer,  2/18/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you.
Flash Poll