Blog

Everyone has an opinion: Agile works for tech, but not for business. Agile is a tool used by consultants to squeak the wheels and bill more. Agile transformation is just another buzz phrase. Agile is a fad. Even in the tech world, Agile is beginning to fall from grace. An increasing number of articles counsel developers to drop Agile and its many rules. Even the founder of one of the earliest Agile frameworks thinks that it’s time to abandon Agile.  Agile has its fair share of naysayers, and not without reason. Many have been burned by a framework that made big promises but led to bigger problems. 

Agile certainly has its limits, but for those organizations open to change, we have developed a point of view to help our clients find success while transforming their business. Even if an entire organization decides “not to go Agile” there are certain concepts and planning activities that can still add value when applied.

In this blog series we’ll introduce concepts and opportunities to apply big room planning, retrospectives, and velocity to teams outside of software development. We’ll share ideas that leverage the intent of these activities and reinforce the mindset that these efforts don’t have to be complicated. Before implementing any changes, keep in mind that simple is better, and then iterate from there.

It Doesn’t Have to Be That Complicated

This article by Lindsay McGregor and Neel Doshi describes how the principles of Agile can become inverted when leaders and organizations only go through the motions. The authors point out that this backwards setup is a symptom of a deeper problem: software organizations set up Agile processes and tools, but also build out detailed plans and comprehensive documentation, rather than allowing the teams to simply collaborate on delivering valuable products for their customers. Organizations can inadvertently overcomplicate the process, making it feel more like “small waterfalls” under the auspices of Agile.

Our experience has taught us to take a different approach. Things fall apart when people underthink the business case and overthink the implementation in search of panacea in a set of rules, roles, and rituals. 

Our take: understand the WHYs behind the Agile, identify why you think you need it, and only do what works. Go beyond that and you’re flirting with failure. 

Things Fall Apart 

Why does Agile fail in some organizations and not others? Why do so many business transformation programs fail? Among the reasons, here are some of the issues we think are most important (and a few ways you can mitigate them)

1. A Focus on Process and Not Customer Value: The Agile manifesto (which is only 68 words) values “Individuals and interactions over processes and tools; working software over comprehensive documentation.” Unfortunately, too many Agile implementations focus too much on “the process” as opposed to focusing on how the process is designed to add customer value faster. 

A simple fix: make sure each planning activity focuses on value-add outcomes. Focusing on solving problems, iterating, and learning to meet the needs of a customer (a customer can be a consumer, or an internal business stakeholder or customer) – will naturally lend itself to some evolution, and that’s okay.

2. Workers Fear the Unknown: Humans need habits, and in fact they can’t function without them;  so naturally teams of people need some level of organization and process to deal with the unknown and manage expectations and fears around change. As with any initiative that involves change, ‘the whys’ of an Agile implementation will be questioned, and should be clearly articulated consistently and frequently. Otherwise, as time wears on, Agile wears out. This is a guaranteed recipe for a failed adoption 

A simple fix: go slow, make sure employees understand why an element of Agile is worth embracing, and demonstrate the value of that element through storytelling or actual experience. 

3. Managers Fear a Different Unknown: Let’s be honest, waterfall can be easier for managing and reporting. A manager finds comfort in the 650 line project plan, even if that comfort is just an illusion. Red, Yellow, Green (RYG) statuses and percentages that can be applied to a timeline are easy to ingest and easy to report up the ladder. In an Agile adoption, a manager will often expect waterfall-like reporting, causing the team to reorganize their work to fit reporting needs and expectations. This can break the back of good iterative improvement.

A simple fix: the product owner can serve as the liaison between management’s reporting needs and the team’s work. It takes real effort to translate iterative progress into timeline reporting, but it’s not impossible.

4. Bad Press Around Agile: Some people think Agile is only helpful for software development; some think Agile isn’t helpful at all. Beyond the negative opinions, it can be hard for an employee to understand exactly how an Agile implementation will impact their job. All of this can limit your team’s appetite to adopt elements of Agile. 

A simple fix: keep it relevant. If you want to introduce a regular retrospective to your team, you don’t have to have them read the Scrum Guide. Take the time to package an Agile element in terms specific to your people.

5. Agile Tools Are Intimidating and They Can Replace Talking: An Agile implementation is often accompanied by new tools.  Along with adapting to a new organizational method, your team also has to learn how to use JIRA or Trello. This can be intimidating, and often mutates conversation into simple status reporting on stories. The tool replaces conversation and interaction, which is the opposite of what Agile teams should do (“Individuals and Interactions over process and tools”).

A simple fix: again, keep it relevant. You don’t need all the bells to do Agile well. If the tool helps, then make sure everyone understands why. If it doesn’t, then ditch it.  

Whether your organization is considering a full Agile implementation, or looking for opportunities to improve collaboration and iteratively deliver value, remember to start small, and build on success. If at times it feels like process for process sake, or the tools or frameworks are making it harder to collaborate, take a collective step back with the teams to review and make adjustments. Since every organization and culture are different, Agile processes are going to look different and that’s ok. What’s most important is that teams are empowered to iterate, experiment and adapt as they deliver value for their customers.

—

Do you have questions about how an Agile approach can help your organization meet its strategic goals? Our highly skilled consultants can help you turn a mountain-sized project into an attainable endeavor that will propel your organization in the year ahead. Click here to connect with our talented team!