Agile is a buzzword. These days, everyone is “doing agile”. Or so they say.
As much as people love to wear the badge of agile on their sleeve, there is a great deal of confusion swelling in the dark chasm between the aspiration of agile implementation and reality.
So what is agile?
It’s basically a philosophy of software development that prioritizes iterative development of working software and solutions through cross-collaboration and self-organizing teams.
Some of the confusion arises when teams equate the agile approach to using an “Agile framework” (usually capitalized).
Frameworks like these are attractive because they’re sold as simplified solutions to difficult project and process management problems.
Sure, these frameworks can be an important part of an agile implementation, but they need more. They need a firm foundation to stand upon.
It’s not enough to simply go through the motions and expect an agile approach to “just work”, especially when transitioning from a more rigid and traditional framework like waterfall.
In order to drive agile success, teams need to adopt agile philosophy. They need to change the way they think about work ownership, management, and their relationship and duty to customers.
Without this vital force, frameworks like scrum and kanban fall flat.
In this article I’ll investigate what it is that separates true agile from the “fake” agile that is often the differentiator between success and failure of a development team. Here’s a quick overview:
- What is fake agile?
- Why fake agile is bad for your teams
- Fake agile vs true agile: How to spot the difference
- Misguided agile leadership
- Understanding true agile
- Questions to ask to help you spot a fake agile team
- The need for agile training
- Tools for agile teams
Welcome to the theater of dark agile…
Agile skeptics seem to have an obsession with the macabre. Here are a handful of terms that have risen to describe the phenomenon that this article refers to as “fake agile”:
The list goes on. What they all have in common, apart from a grotesque metaphorical underpinning, is the lack of vital spark necessary to facilitate true agile success.
What is fake agile?
First of all, there is no standardized assessment for measuring agility. Agile is a philosophy, more than it is a framework. Or at least it was originally.
This is embodied in the statement “be agile”, in contrast to “do agile”.
The difference here is that in “being” agile, it shouldn’t matter what framework you use, because certain core values are upheld. Pretty much all “true” agile frameworks will share these same values.
Here’s a useful diagram from the US Department of Defence illustrating the foundational distinction between a successful agile framework and what they deem “Agile BS”:
Fake agile, on the other hand, is a type of waste. It’s a broken process.
When teams are churning out a higher amount of working builds with the intention of facilitating customer feedback, there is going to be a lot of waste; a lot of stuff that just doesn’t hit the mark.
Whether it’s due to heavy-handed management undemocratically forcing their agile agendas onto developers who just aren’t ready for it, or well-meaning project leads seeking to improve the productivity of their team by implementing a hot new methodology, the root of fake agile is a system that isn’t performing as well as it could be.
More specifically, fake agile is fake because it’s not truly upholding the principles of agile. Fake agile is sugar-coating (rebranding) traditional methodologies like waterfall with jargon.
Why fake agile is bad for your teams
“Scrum, done even fairly well, is a good framework. I’m quite sincere about that. It’s good to have a strong connection to the business deciding what needs to be done, and what needs to be deferred. It’s good to have all the skills you need to build the product right on the team. It’s good to build a tested tangible product every couple of weeks, and it’s good to show it to stakeholders, and it’s good to review how things went and how to improve them. I’ve studied, worked with, and thought about Scrum for years, and everything about it is really quite good. Not perfect, but really quite good.”
– Ron Jeffries, a creator of the Extreme Programming (XP) software development methodology.
Jeffries was specifically talking about scrum, but the point can be extrapolated to the abuses of agile in general. As a well-executed ideal, agile can be pretty good, but the reality is often not aligned with the concept.
This mismatch is called fake agile. What’s so bad about it?
Well, let’s look at some common beliefs of teams championing a so-called agile approach:
“We’re so much more productive now that we’re agile!”
“People over processes!”
“Working software is more important than documentation!”
“Adaptiveness and resourcefulness are more valuable skills than your ability to stick to a plan!”
While there is truth in these statements, many agile implementations twist them into a crude half-truth that lacks the vital life-force that every agile team needs – a proper understanding of the why behind agile.
Gabrielle Benefield gives a clear explanation of the dangers of crude agile approaches in her GOTO conference, titled Frankenbuilds; if Agile is so good, why are our Products so bad?.
I’d recommend the whole talk, but to summarize, her point boils down to the oversimplification of agile into a system which prioritizes quantity over quality.
She argues this crude “machine gun agile” approach that pressures teams to push out more regular working builds to increase the odds of getting something right creates a lot of waste.
To better understand the danger of a misguided fake agile approach, consider this example.
Imagine a project manager that has just announced during the daily stand-up that, thanks to their new agile approach, the team has successfully delivered 35 features, on-time and on-budget.
Impressive-sounding statistics, but who is going to use those features? How will they help the company provide more value to customers, and make more money? Why 35 features? Could the same result have been achieved with two or three features?
Fake agile vs true agile: How to tell the difference
Enough about vital sparks and vagaries, how do you actually tell the difference between real versus fake agile?
There are a few things you can look out for. I’ve listed a few key areas and clarified how a fake agile approach would differ from true agile.
The information is from a number of expert sources, namely the DIB Guide: Detecting Agile BS document, which the US Department of Defense Innovation Committee (DIB) published in open access on October 9, 2018.
True agile: Developers understand the importance of communicating and involving customers and users with the development and deployment process. They will share development progress and actively seek feedback in order to improve the process or product.
Fake agile: Developers are not interested in communicating with real users of the application (program testing and evaluation don’t count); if there is feedback, it is not continuous (only happens at the start of the project, for example).
Time management and diminishing returns
True agile: Prioritizes working builds and understands the importance of rapid iteration. New working builds either weekly or at least at the end of each sprint.
Fake agile: Attention to requirements over quickly deploying something useful. Rarely has a working build ready to show at the end of a sprint; working build is pushed to the hardening sprint or “next sprint”.
True agile: Developers are active and willing to take responsibility for their role in providing the customer with value, and improving upon their offering.
Fake agile: Developers defer responsibility and act like “it’s not my job”.
True agile: Processes are automated as much as possible to eliminate tedious manual tasks and focus on providing value to the customer.
Fake agile: Processes are mostly manual; lots of scope for automation.
Bonus: Using Process Street for agile automation.
Check out this video for a quick introduction:
Importance of functionality
True agile: Focus on iterative development of working software, where feedback from key stakeholders is crucial at every step.
Misguided agile leadership
The role of agile leadership is often misunderstood. Too often teams will have positions like scrum master and product owner assigned, only to find that in practice those individuals are performing the exact same functions as a project manager in any typical development framework.
A common theme with this problem is the idea that there must be a “single throat to choke”. This is expected in traditional development structures, where the project manager is essentially responsible for making sure each member of the team is getting their work done.
Agile is different because the nature of responsibility is fundamentally different. Individuals in a high-performing agile development team should have a shared sense of responsibility.
If anything, the “single throat to choke” is the collective throat of the entire dev team.
Product owners and scrum masters are there to fulfil key roles like reporting back to business owners and communicating with stakeholders, but their roles are fundamentally different to a typical project management position.
This difference in managerial approach also highlights the difference in attitude towards punishment and fear in the workplace environment.
If individuals are afraid of the punishment they’ll see if they fail, their creativity and innovation is quashed. This kind of fear doesn’t motivate; it simply drives numbers and discourages experimentation.
Fear of punishment also pushes people away from responsibility. If your team knows they will be scalded if they don’t perform, they will inevitably fail more because individuals will spend more of their energy avoiding accountability rather than focusing on doing their best work.
In pursuit of “true” agile
“We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.” – Agile Manifesto
The Agile Manifesto was written way back in 2001, at the turn of the century. It’s an obvious starting point for trying to understand what it means to “be” agile versus to “do” agile.
To simplify it a bit, think of it like this: “Be” is the philosophy. “Do” is the framework.
At its heart, it is a philosophy that precedes any individual framework or methodology. Each framework will apply the values and principles differently, but the foundation remains the same.
Ultimately, the goal of “true” agile is to guide the timely development of high-quality, working software with the best interest of the customer in mind.
Four core values of agile
The Agile Manifesto (also known as the Manifesto for Agile Software Development) outlines four core values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The 12 principles of agile
It goes on to declare 12 additional principles:
- Satisfying customers through early and continuous delivery of valuable work.
- Breaking big work down into smaller tasks that can be completed quickly.
- Recognizing that the best work emerges from self-organized teams.
- Providing motivated individuals with the environment and support they need and trusting them to get the job done.
- Creating processes that promote sustainable efforts.
- Maintaining a constant pace for completed work.
- Welcoming changing requirements, even late in a project.
- Assembling the project team and business owners on a daily basis throughout the project.
- Having the team reflect at regular intervals on how to become more effective, then tuning and adjusting behavior accordingly.
- Measuring progress by the amount of completed work.
- Continually seeking excellence.
- Harnessing change for a competitive advantage.
Questions to ask to help you spot a fake agile team
As well as asking yourself how fake agile is different from true agile, you’d do well to ask the teams you’re working with directly.
Often you can glean some real insight into the way they work with simple questions like these.
Question one: “How do you gather feedback?”
Agile depends on feedback from the customer to work properly.
Less experienced dev teams may be satisfied with one or two feedback forms (that take about a month to get back) but in reality this isn’t good enough.
Agile feedback should be continuous and built into each step of the release cycle.
Teams that see feedback as the exception are the ones that are not doing agile properly.
Question two: “How much has the team budgeted on that project to accommodate customer feedback?”
Getting feedback is the first step, but unless the team has a working infrastructure to assess and implement that feedback as part of their development cycle, it’s as good as a blank sheet of paper.
An important part of this consideration is the team’s budget.
How much of the budget is reserved for addressing feedback, or in other words, how much of it is reserved for the unknown?
The response to this question might be a confused one, in which case it’s clear there is a lack of proper agile understanding.
The need for agile training
Employees need to understand the philosophy behind the agile approach.
It’s important that everyone understands how to “do” agile as well as how to “be” agile.
Much of the confusion and failure of Agile In Name Only (A.I.N.O.) approaches stems from the lack of proper agile training.
Here are some reasons why it’s super important that you spend time with proper agile training.
High cost, zero reward
Are you sure you’re actually benefiting from your agile implementation? Transitioning to an agile development framework can incur extra overhead, and if there isn’t proper training, this additional cost becomes a waste.
Simply adding a regular stand-up meeting and calling the month a sprint won’t magically transmute your processes into agile. Telling your team mates they’re self-organizing while they’re still being delegated and assigned work in the same way as before will confuse and frustrate them.
Agile training is necessary to avoid these confusions and make sure the maximum potential of agile is unlocked for the whole team.
Bad practices will breed and multiply
Stomp out bad practices as early as possible. The longer bad habits are left unchecked, the deeper they will burrow and the harder they will become to get rid of.
Agile training helps to uproot these bad practices before they can take hold and become even bigger problems.
You’ve probably got some vague idea about what it means to be agile. Most developers probably do. When there’s missing information, our brains fill in the gaps.
A great example is the scrum master typically falling back into the role of the project manager.
When teams aren’t properly educated about their roles and responsibilities in an agile framework, they will default to what they know, and old habits die hard.
A big part of agile training is helping people unlearn the bad habits they’ve grown used to.
That’s not to say that agile is “better” than whatever was happening before, but old habits can certainly interfere with the way agile functions, and it’s important to transition certain behaviors with proper training.
Avoid Frankenstein agile
This is similar to the need to train away bad habits, but the difference is here it involves a conscious bias about what each individual thinks is the best way to get things done.
They may have been doing a brand of agile at a previous company, and believe that is the best (or only) way to do it.
Often this will manifest in the form of Frankenstein methodologies that mix up parts of scrum with waterfall and all sorts of other different approaches, like picking out groceries at the supermarket.
This kind of mash-up approach can be avoided with proper training. When everyone is on the same page about the process and principles behind the agile approach, more work will get done and there will be less friction in the team.
Some typical tools for agile development
Here’s a list of tools that can be useful for agile development teams:
- Git: The modern development standard for version control.
- GitHub/BitBucket: Repository hosting, tickets, application integration. But which one to use?
- Jenkins: Incredibly powerful integration server.
- Ansible/Puppet: Configuration recipes and tasks for server support.
- Docker: Virtualization (containerization).
- Kubernetes: Container orchestration.
- Jira: Tickets, monitoring and management.
- Process Street: Rapid process prototyping and deployment, as well as business process management. It integrates with many of the tools above, like GitHub and Jenkins!
More agile resources:
- The 11 Agile Processes We Use to Run an Efficient Software Team
- Where to Start With Agile Software Development
- 7 Software Development Processes to Engineer Your Success
- How to Improve Your Software Development Culture and Product Quality
- Scrum Project Management Checklist
What do you think is the most important aspect of a successful agile implementation?