Many years into my career in software development, I was introduced to the concept of “agility” and specifically leveraging the “scrum” methodology. We were trained up over the course of a couple of days which included silly activities to prove a point like making paper boats. I learned about 2 week sprints, sprint ceremonies (like sprint planning, daily stand-up and retrospectives), and best practices around estimation.
At the time, I was on a very lean team responsible for operating a platform that was licensed to a competitor for what I understood was a large sum of money. Our product was important to the bottom-line so consistently delivering value was the name of the game. I enjoyed the structure that sprinting offered and the constant tangible value delivery to our customer appealed to the dopamine receptors in my brain that get excited when I check something off my “to do” list.
During that time, I also learned about the “agile manifesto” and that there was a real career path for people like me who enjoyed solving human-centered problems. And since then, I’ve worked with a number of different large enterprises that employ various flavors of agile.
I say “flavors of agile” because, even within a large enterprise, I’ve seen teams operate slightly differently. And, ultimately, I think that’s the point. Frameworks are guidelines on how to operate and achieve success, but not exactly a manual on how to do it. Even the agile manifesto is less about what specific process to follow and more about putting collaboration and flexibility at the forefront to achieve better customer outcomes, in theory. In practice, I’ve found the best of intentions but mixed results depending of the “flavors” I’ve encountered:
(1) Highly Structured Agile
In very large organizations with large portfolios of interconnected digital products, it can become incredibly difficult to maintain alignment (i.e. how do we make sure everyone’s working on the right things at the right time?) such that business value can be realized (i.e. so the company can make / save money!).
This leads to a more structured approach that can sometimes harken back to traditional waterfall project delivery to help bring more certainty to the outputs coming out of the process. There are various frameworks to choose to help with this but the one I’m most familiar with is SAFe (Scaled Agile Framework for Enterprises).
PROs:
- Encourages vision/goal-setting and aligning teams around those for a Program Increment or PI (which is usually a period of approximately 12 weeks)
- Focuses on value-stream realization through the concept of a “release train” and the role of a “Release Train Engineer” (RTE); the RTE ensures many teams that need to work in parallel get to the proverbial station at the same time to provide value
- Encourages continuous exploration to ensure there’s a wide array of ready efforts to swap in case an effort is unexpectedly shelved
CONs:
- Requires highly skilled / specialized talent so not great for lean / less mature orgs
- Because “PI Planning” plots out the next 12 weeks, it can lead to teams being highly inflexible and less adept at adapting to changing business priorities
- Requires continuous exploration and discovery which can be difficult to achieve unless a concerted effort is made to distinguish strategy work (defining what problems to solve and hypotheses for solutions) from execution work (crafting and ultimately implementing detailed solutions).
(2) Adaptive Agile
Again, in mid to large sized organizations, there is often a need to find a way to organize around work that gets done. However, the highly structured approach may not offer a return on investment or may simply not align to how business is run.
This is where what I call “adaptive agile” comes in. Folks will take concepts and pieces of what might happen in a more structured setting and apply it within their level. This might include using Kanban boards to quickly churn through certain types of work efforts and adapting ceremonies to what you can achieve with the available resources (especially if teams may not be able to collaborate in person due to offshoring, remote work or generally not being co-located to a geographic area).
PROs:
- Highly tailored to an organization or team’s needs so long as value is delivered
- Adaptable to many different tools / trackers
- Easier to be nimble and adapt to changes in direction
CONs:
- Requires a high degree of thought-leadership to stand up and evangelize processes with cross-functional partners, especially when they stray from the norm (e.g. shifting daily sprints to twice a week instead to limit the burden on offshore team who need to attend this ceremony in highly inconvenient hours).
- Strategic focus may suffer as the “adaptive” approach can focus more on the execution (shipping) vs strategy (shipping the right thing to drive company value in some meaningful way)
(3) Fake Agile
In the past, I’ve joked with colleagues about “fake agile” but I think it’s worthwhile to legitimize this label and explain how I see this.
To put it simply, “fake agile” is when you attempt to adapt agile techniques but yield very few of the outcomes of the agile manifesto because, as it turns out, you aren’t really following the principles.
In my experience, this is usually the result of an organization transitioning too abruptly from traditional waterfall methodologies. In these scenarios, there’s a high degree of doing the thing for the loudest stakeholder which doesn’t usually yield scalable value.
And lack of value translates into other activities, most notably, the creation of user stories that don’t actually identify the end-users (e.g. stories that start with “As a Product Owner”) or stop short of defining WHY that end-user needs Engineering to build (e.g. As a Product Owner I want to build ABC widget). In this scenario, tools to track work effort are typically under-utilized limiting teams’ ability to track say vs do ratio to make sure they follow through on commitments. The end result is technology delivery timelines still take a long time and feel very waterfall in the sense that, despite waiting so long, no one is pleased with the outcome realized.
PROs:
- For many, working this way feels familiar because they are most adept with waterfall development
- Because of the rigidity around locking requirements in waterfall processes, teams may be less distracted by changes
CONs:
- Results can be inconsistent and tend to have limited long-term value
- Risk of burnout for employees who aren’t getting adequate agile training and therefore are ultimately doing a lot of busywork as opposed to value-adding efforts
As you can probably tell, there’s a Goldilocks in here and two extremes. Getting to the right amount of process to get valuable work done takes a commitment to continuous improvement, not unlike agility in software delivery. However, in the absence of that, agile coaches — who can embed with a team to help refine their practice — can be tremendously helpful, albeit, expensive. In lieu of dedicated coaches, experienced senior leaders who can help the organization transform around a clearer vision are likely to have a stronger impact.