Articles, tweets, and cartoons describing the evils of agile are an Internet search away. A backlash against “soulless agile” – the charade of teams going through the motions without positive intent, simply because of a mandate, or because “this is just the way it is” – has contributed to the rise of new practices like DevOps. There have also been calls for developers to abandon agile altogether.
Indeed, some people are still faking agile.
The impact of fake agile practices is a struggle I face every day at Red Hat in my role of Chief Agilist for the Products and Technologies division. Fake agile practices have been a present reality throughout my career as an agile coach: Maybe you’ve observed some agile fakers, too. There’s the executive who knows agile has never solved their business problems before and has learned not to bother; the engineer who suffered through a 90 minute daily standup for ten sprints and rejects any process improvement as a potential threat; the project manager running that standup without an understanding of the impact it is having on team morale.
Fake agile has only served to disconnect these individuals from the systemic problems of their organization – and obscure a path to improvement.
How does a savvy leader spot fake agile? There will be warning signs, and if you look for them they will become obvious. Once you spot them, you can ask targeted questions to help your team correct course.
[ What's holding your team back? Read also: DevOps: How to overcome 4 perennial sticking points. ]
Fake agile focuses on output instead of outcome
In one of my first agile coaching experiences, the team implemented scrum within an IT department without involvement from our business stakeholders. We were so keen on the promise that this new process would help us get work to the customer faster. The reality of the technical situation was that rapid deployment was impossible, and so customer excitement and close engagement escaped us. In some cases, they requested a return to waterfall development.
Reflecting back, I realize that our failure was partially because we could not be obsessive about our customers’ experience in the software we were creating, or the process we were using to create that software. In attempting to both insulate developers from this reality, and prevent them from provoking business partners into an escalation by telling them how to do their jobs, we prevented the sides from learning from each other.
In the end, attempting to prevent these interactions caused them to happen anyway – only in a delayed and heightened manner. Ultimately, the software that we delivered wasn’t close to what the customer wanted.
So how do you spot this in your organization?
Ask your team these questions:
- What is your goal for the upcoming release? How does this achieve or solve a customer problem?
- Who are your stakeholders? Are they internal? External? Both? What opportunities do they have to provide feedback? How does their feedback impact the development process?
- If you don’t have customer engagement, do you and the team understand why?
- Have you discussed mitigating the inherent risks in low-engagement agile development?
- How do your teams deploy code and how often? Can they do so without human involvement? Is it often enough to keep the attention of customers and/or stakeholders?
Fake agile cares more about process than the problem being solved
I’ve often received emails that begin, “Can you help us deploy Scrum?” In the past I might have replied, “Let’s meet and talk about next steps,” but the business-minded person I am now asks skeptical questions: Why scrum? What does it do for us? Is it the right process for the team, environment, and company? Who is the “we” doing the requesting? Does everyone understand the expense and disruption involved in “deploying scrum?” In short, what is the problem you are trying to solve?
I want to caution against the idea that process frameworks are unilaterally bad. Folks have had success with scrum; I have even experienced it too. However, there is a nuance involved in how you implement process frameworks that is critical.
One of my successful experiences started out with a mandate to create a ‘devops team’ and to use Scrum. Many people on the team were excited to be there, excited to get started solving technical problems for the organization. However, they were not excited about the process, not excited about it being mandated on them, and almost all of the engineers were reluctant participants in agile. Did I, as their agile coach, allow for those process mandates to stay true? No. I asked them what they wanted to do and how they wanted to do it.
The team agreed to tolerate kanban, but only if it was lightweight. We refactored the original process that we were meant to use and adjusted it to fit the team’s needs. As time progressed, we continued to modify the practices. But only when we needed to.
The key here is that asking for teams to evolve and change should not be about fitting the team to a framework, but the process to the team. The team’s process, as a result, was a Frankenstein mismash of XP, Waterfall, Scrum, DevOps, with a sprinkle of Simon Sinek to make everything right. But it worked for us!
That experience helped to evolve my understanding of agile and created the foundation on which we modernized the Red Hat Enterprise Linux development team’s design, process and culture leading up to the deployment of RHEL8.
Ask your team these questions:
- What is the problem you are trying to solve? How does this framework solve that problem?
- How does this problem solve a business or customer need?
- What have you tried to do in the past? What did you learn?
- How do you know when the problem is solved? What is your measurement of success?
[ Are you holding your scrum master back? Scrum master: 5 signs you need to rethink the role ]
Fake agile checks a box instead of looking closely and evolving
Businesses should evolve. Indeed, I believe they must evolve or die. To directly adopt unevolved agile today would mean basing our practices on a manifesto developed by 17 guys in 2001. It’s clear that this blind and unreflective embrace of the well-known and out-of-date happened with the past embrace of waterfall and may be happening with the current obsession with DevOps, despite the unrelenting pace of our industry. How could these frameworks reflect the situation that we are in today? Technology moves too quickly for that to be true.
I’m frequently asked why I don’t mandate or standardize Scrum at Red Hat for the whole organization.
The reasons are practical and unavoidable: We must work with upstream software development teams and obtain community consensus for our merges, but Scrum is optimized for teams without outside dependencies. In our case, this aspect of the process simply doesn’t fit in with the state of open source software development and its specific requirements. This is why I allow for teams, organizations, and our company to guide where they want to take agile.
Guard yourself against repeating a past mistake that I have made: Evolve your viewpoint instead of trying to make sure boxes are checked – it is essential to avoiding fake agile within your own organization.
- There is no predefined right or wrong way – you must tweak for your conditions. Understand the business problem you are trying to solve first. Jumping to buying a solution, technical or otherwise, will not advance your goals.
- Know that this work does not end. There is no box to check at the end of the process. The work changes, teaches you something new, and you learn to continue to get better. Continuous improvement should be a fact of agile life for you and your teams.
- This is hard and messy human work. Work that is worth it because the folks who work for you and at your companies are worth it. As a leader, this is work that you must do, too.
“It is not the strongest of species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change.” -Charles Darwin.
[ How can automation free up more staff time for innovation? Get the free eBook: Managing IT with Automation. ]
