Original article written by Sarah Stewart and published on
So you’re an Agilist but you’re on a team that “doesn’t do Agile.” What do you do?
Let me share with you the story of my first “Agile-like” project. For all intents and purposes, it was a traditional (i.e. waterfall) project that spanned nearly three years. I’d already worked in the organization for several years before this. This was my fourth product cycle with them, and while we reviewed our team’s processes at the end of each cycle and put improvements in place, this was my first brush with anything like Agile. No one ever used the words Agile, Scrum, sprint, iteration, Scrum Master, Product Owner, or any of it. And yet, in this “near Agile” version, we applied the following improvements:
These were 7-12 person teams with 1-2 PMs, and typically an identical number of developers and test engineers. Test engineers wrote test automation and ran manual tests on the new work, while the developers wrote production code. Not exactly a Scrum team, but still a dedicated cross-disciplinary group focused on delivering small parts of the overall project.
Bi-weekly Internal Releases
In addition to traditional “alpha” and “beta” releases for select external customers, we released versions of the product every two weeks to internal customers to solicit company-wide feedback. In previous product cycles we’d done these “dogfood” releases monthly or less, but increasing the frequency sped up feedback. Officially, we weren’t required to integrate feedback until the next milestone (multiple months apart) but we did roll bug fixes and improvements into each dogfood build, and our internal users really liked that quicker response.
That faster turnaround was only possible with a robust and reliable suite of automated regression tests and a fully automated release process. We’d had testing and automation before but for this release we pushed further, tested earlier, and automated sooner as well. As a result, the more frequent releases didn’t damage our reliability. It was hardly “continuous” integration, but it was still a huge step forward.
Feature crews met regularly to demonstrate their new work to teams working on related features. This let us identify potential integration issues before they became a problem, avoiding lots of bugs and rework.
Teams of Teams at Scale
The project was a massive undertaking involving hundreds of people, six major applications, and dozens of integrated components. Our application alone had seven feature crews working with even more teams on other applications, all integrating into one application suite. Representatives of each team met weekly to coordinate on everything. We also created virtual teams across applications to coordinate more general concerns that affected nearly everyone, like security, localization, and user interfaces.
No one would have called this project Agile—not by a long shot. But Feature Crews looked a lot like Scrum Teams. Those bi-weekly dogfood releases led to some sprint-like practices, and the regular demos worked a lot like sprint demos. And with just a little squinting, our “team of teams” organization acted a lot like an Agile Release Train, with meetings run very similarly to Scrum of Scrums.
It was several more years before the organization took the leap to formal Agile frameworks, but by then the scaffolding was already in place. With these little starting elements (and more introduced milestone by milestone) the organization made the transition very naturally.
What We Learned
There are several takeaways from the way this project went. A lot of them will be familiar already to Agilists: start with a few changes, keep your scope focused, build on and share successes, and collect and act on feedback. But one I really want to highlight is the value of experimenting, even in a really large organization.
We undertook all these changes as an experiment, but with buyoff at every level of the organization. This was a huge, complex project with a vast range of different team types, working styles, and challenges within it. We didn’t drop in a cookie-cutter Agile process, but instead came up with changes the organization could tolerate that we thought would still make a difference. And that’s what succeeded, and that’s why people took to it so well, too.
The key to sneaking Agile into a team is tolerable, practical changes. Focus on small steps and single tools that will give people a sense of control and some excitement over the possibilities for future growth. And there are a lot of small-chunk Agile techniques and concepts that you can implement on traditional waterfall teams:
- Kanban Boards and WIP limits
- Small teams, or at least focused sub-teams (i.e. “Feature Crews”)
- Working from a prioritized backlog
- Moving from grand functional specifications to granular user stories
- Partial or full Test Driven Development / Behavior Driven Development
- Pair Programming
- Internal bi-weekly releases (i.e. internal sprints)
- Regularly scheduled team / feature demos
- In-flight retrospectives for internal improvements (rather than waiting for an end of project post-mortem)
- Daily (or regular) standup meetings to organize daily teamwork
And probably more (please add a comment if you think of anything I’ve missed here)!
There’s one other topic to touch on here, which is that some people have had bad experiences with poorly planned or badly managed Agile transformations. This can leave them with a strong negative association with anything “Agile,” often for understandable reasons. Feel out the organization’s environment before introducing these concepts. You might have to rename or reframe ideas to get such people to buy in. Be subtle and clever as you hide the Agile vegetables under the mashed potatoes. Also, if someone calls you out for it, rather than pushing harder, draw them out about their experiences and get them to help you figure out a good setup for the project.
For example, I worked in one organization that was very anti-SAFe (Scaled Agile Framework). Despite implementing what was basically a (slightly modified) SAFe transformation, we avoided using most SAFe terms to finesse the subject with upper management. For example, we called Release Train Engineers “Chief Scrum Masters.” It may seem a bit of a silly compromise, but it helped us get buy-in.
Again, Agile is about improving where it’s practical to do so. That’s a broadly applicable attitude. Small chunks of Agile are useful even without the full framework but getting people on board with you is key. If that means compromise (or telling your kids that fish sticks are “ocean chicken nuggets”), you’re still helping.
Good luck! And please feel free to comment if I’ve missed any Agile techniques that work well on non-Agile projects, or clever ways to introduce them.
About The Author:
Sarah Stewart, SPC5, CSP-SM, CSP-PO, CSM, CSPO
Sarah is a Senior Technical PM, Agile Coach, and consultant. She helps organizations, from individual teams all the way up to the enterprise level, adopt Agile/Lean practices and frameworks. She works as a coach, trainer, mentor, and writer. Read more of Sarah’s work on LinkedIn.