Is it time to let go of agile?
A critical look at the difference between waterfall and agile
In a talk called “Agile is Dead” by one of the founding members who created the manifesto for agile software development, he claims we should scrap the word agile from our vocabulary (especially when used in the proper noun capitalized A form as in God). He claims that the word “agile” is an adjective, not a verb or a noun.
For the full talk, see the video below:
Agile is Dead * Pragmatic Dave Thomas * GOTO 2015
I tend to agree with his sentiments.
The problem it creates is that everyone calls themselves agile, even though decision making might take month or even years (as is typical in a large corporate and can’t exactly be described as agile, maybe just more agile than before?).
The true value of the work loses its lure because it is overused and exaggerated.
Keeping up with the Jones
The word “agile” tends to cause more confusion than clarity. The mainstream success of Scrum has made this confusion even worse, with the buzzword used abundantly to describe anything that someone deems to be (even just slightly) “better” than the proverbial Jones’ next door.
When you want to sell your service or product, you add “agile” or “Scrum” in the proposal and wha-la! you win the contract because your competitor didn’t. As if using a word is going to result in changes within your teams to make you more agile in delivery…
Or, when you are looking for talent as a recruiter you add “agile” or Scrum Certified as a requirement and wham! Your job spec sounds more enticing to talent than the one without these buzzwords.
Yet, I see so many companies and people say they’re “agile” because they changed their vocabulary but not any behaviors. A progress report is now called a sprint, even though there is no potential shippable product ready at the end of the interval. There has only been progress. Sometimes not much. Sometimes even in the wrong direction.
They have daily slack-bot stand-ups (“because slack is so cool and everyone agile uses it!”), or they use a more agile workflow tool (the typical “we-use-Jira, so-we-are-agile” syndrome). Yet, fail to understand why communication isn’t better or why work doesn’t flow better as agility promises.
It drives me insane.
And raises a big question. If Scrum is a process framework and a certified Scrum Master can help implement the process, why is it that it is not working?
Curiosity, I mean simplicity, killed the cat.
I believe the core strength of the Scrum framework is also the reason for its downfall. Scrum is marketed as a simple and lightweight process framework. Getting certified is as simple and lightweight though, requiring merely a 2 day training course and written exam, making it extremely accessible. Too accessible in my opinion.
The process is however not what makes you more agile. It merely allows you to uncover your failures faster. If you refuse to look at these and change your behaviours, tools, and processes, your merely moving the dirt around without actually cleaning anything. It’s like mopping a dirty room without throwing out the dirty water.
Or, it’s like expecting to get a chocolate cake without changing the ingredients you used to bake bread. The process is important, but the ingredients are key. No cocoa, no chocolate cake. Period.
The main ingredient to achieve agility is mindset and team dynamics.
Mindset beats process every time.
The good news is that mindset results in behaviours, and behaviours can be observed. And changed.
If you know what to look for…
2020 vision
So what do you look for to evaluate the level of agility? And what does a truly agile team look like? And should we be calling “it” agile in the first place?
I do believe ‘agile’ is a good, descriptive word. I don’t, however, think it sufficiently describes what exactly it entails and creates a misconception that it’s all fun and games. There is not enough emphasis placed on the need to slow down and carefully look at the monsters under the bed on the journey towards agility.
However, semantics aside, let’s leave the philosophical debate and rather look at what we can do.
To begin with, critically, and honestly, evaluate the true agility of your team or organization by looking at some of the most common behaviors (or rather mis-behaviors) and patterns.
It is by no means a comprehensive list but should give you a good idea of where you’re going wrong and what to do about it if you do.
1. Communication style
One of the most important things to look for is the main communication style within the organization.
In a waterfall, or less agile approach, communication is typically top-down. In group meetings (including the stand-up) the team tends to look at and report to the manager, team lead or Scrum Master. They also tend to refrain from raising issues, obediently performing tasks assigned to them by the team lead.
Contrary, in a more agile approach to business communication is driven mostly bottom-up. The team has the ultimate decision making power, not the manager. They say what work they will do and how long they need and they’re not afraid to speak up when they see a dysfunction or issue. They question everything. In an agile team setting, people tend to report to and look at each other rather than the leader.
2. Communication channel
Possibly even more important than who people communicate to is how they choose to communicate.
In a more waterfall approach communication tends to be in one direction with one person (usually the manager) speaking mostly at the team, softening harshness and avoiding conflict. Technology as an enabler for this type of communication means mostly digital communication is preferred. Slack conversations or comments in workflow tools like Jira or Trello is commonly substituted for group meetings to talk about things in person. Digital is also preferred for bearing bad news.
Remote work is preferable for teams who want to avoid conflict.
In a more agile approach the communication is honest and bi-directional with face-to-face interactions preferred. The tool is never more important than the person and is used when something needs to be remembered or tracked, supporting face-to-face communication, not controlling it. People sit together and frequently chat. They don’t wait for a meeting or any other form of permission to initiate a conversation. The Scrum Master or Agile Coach facilitates and enables conversations rather than lead it.
Remote work sucks. Or when they’re remote, they like showing their face on video calls and chat with each other even when they don’t have to.
3. Task assignment
A key behavior in a team that directly measures the level of responsibility (and thus agility) within a team can be observed with how tasks or work is assigned.
In a waterfall driven environment work is assigned to specific team members in a top-down approach by the manager, whereas an agile environment allows the team to pull (rather than push) work when they have capacity and when they feel competent to achieve the task at hand.
The manager may at times assign specific challenges, but mostly create an environment where each person has adequate opportunity to excel by ensuring there is a wide variety of tasks that will satisfy and challenge each person in the team, without pushing them beyond their boundaries.
For example, when someone seems overwhelmed, ensure there is adequate smaller tasks that can more easily be achieved. Or, when a talented resource seems bored, ask them to find a solution to a particular problem that gives them freedom to showcase their strengths and interests.
When no-one wants to pick a task, uncover the reason why and resolve that rather than force them to do it.
4. Decision making
Another key indicator of agility is the decision making process and style of an organization. The faster you can make (good and sustainable) decisions, the higher your level of agility.
In a less agile organization the boss is the ultimate decision maker and decisions are usually made in isolation with little to no input from the team. In a beginner agile team often rash decisions are made, which may seem fast in the short run, but soon need to be re-looked at.
Contrary, in an agile environment the team is the ultimate decision maker with decisions made collaboratively and slowly, with implementation fast.
People are assigned specific levels of authority that empowers them to act without always asking for permission first. When there is uncertainty, the team leader (or someone other that is seen as key) is asked and advice given in a coaching style rather than a directive style. The role of the team manager is to help the team make the right decisions, not to give them the answers to all the decisions.
5. Dealing with mistakes and failures
When a team is empowered to make decisions, it also means there needs to be room for failure. In an agile environment mistakes are owned and corrective and preventative action implemented to prevent it from happening in the future to minimize the risk and impact of the error.
In a non-agile environment mistakes are not acceptable and as a result is often hidden until it’s too late to resolve without pain or high cost.
Agile teams are all about transparency and responsibility.
6. Choice of tools
“We use Jira and Slack at work, so we’re agile”.
Personally, I don’t understand how this even became a thing in an agile community. Equating your level of agility in terms of which tools you use (to me) is insanity.
Changing a tool, compared to hand written, is slower, more expensive and much more limited in the amount of options it can manage at a specific time. And the tool is only as good as the information it holds. Garbage in. Garbage out.
It’s not the tool that matters, but how people use it. Closely look at the content of the tool to discover the actual behavioral patterns of the team.
On the other hand, wiping out something on a white board, adding another step to a workflow, or moving tasks around is fast, effective and most of all, tactile, which means more engaging.
The level of agility can be rated pretty accurately at a glance by the amount of visual artefacts and the frequency it changes. Too pretty and laminated and part of the furniture? Probably not very agile. Hand drawn, worn out and scribbled on? Probably more agile.
Another behavior to look for is the level of active interaction with these artefacts. In a less agile team the team passively observes from a distance whereas in a more agile team they own the artefacts on the wall and use it.
7. Talker or do-er?
Probably the easiest behavior that is an indication of an organization’s agility is the amount of talking that goes on. If the team can’t keep to a 15 minute stand-up time limit, start looking at why and raise the false agility flag.
Is it because one person is talking too much? False alarm. Is it because people are giving reasons and explanations and defending themselves because they didn’t achieve their goals? Jackpot.
A non-agile team often consists out of talkers who talk around issues and want to create the perception of being busy.
An agile team, on the other hand, prioritizes action. Rather than talking about something ,they will go and do it and show, rather than tell.
Actions speak louder than words.
8. Feedback
At the heart of agile is shorter (and more honest) feedback loops. The entire Scrum model is based on the continuous improvement P-D-C-A cycle where feedback is the essential tool to consistently and continuously aim to shorten the gap between where you are and where you want to be.
In a less agile organization, feedback loops are long, with yearly or quarterly formal performance reviews. Typically, the manager waits until the performance review to give feedback and feedback. Also typical is waiting for everything to be complete and ‘perfect’ before you start.
Agility is essentially about feedback and looking through the lens of learning and curiosity.
In an agile organization feedback loops are short and results in immediate action. There are frequent, small conversations throughout the day (in person, Slack doesn’t count). There are at least daily check-ins with the entire team and conversations happen in real-time.
See an issue? Raise it. Now.
See a desired behavior? Praise it. Now.
Don’t wait.
8. Team structure
A less agile team consists of a bunch of people sitting in the same physical location and working on the same project, but little to no interaction between the different parts. Essentially, it is one-person teams sharing a physical space. They are usually grouped per functional area (designers together, testers together, programmers together etc.)
An agile team is more autonomous and collaborative. There’s often a healthy buzz as people pair, chat and help each other solve problems. Even if they’re working remotely, they always include others in important decisions.
Everyone is involved in the decision making and each team has all the skills needed to achieve the sprint goal. Each person in the team has a unique superpower, with people knowing each other’s strengths and weaknesses.
9. Handling constraints
A core principle of agile software development as stated in the manifesto is responding to change over following a plan. A key question to evaluate your agility is:
How does your organization handle unplanned events or feedback?
An agile team responds to change and adapt fluidly and easily. A non-agile struggles with change and tends to come to a grinding halt and wait for everything to get back on track before they continue the planned work.
A typical behaviour in a non-agile team is to respond to changing requirements with resistance. A more agile team welcomes it with a gamer’s mind.
An agile team looks for solutions. A less agile team complains about obstacles.
10. Leadership style
Agility demands a more coaching style of leadership with the leader serving as a facilitator rather than the oracle with all the answers. Humility is key to agile leadership.
In non-agile organizations the leadership (or rather management) style is mostly more autocratic with the leader feeling threatened when the team knows the answers to problems or can function without being managed.
The more agile style of leadership is typically predominantly servant-leader or transformational in nature, with trust and respect at the core of the relationship between leader and follower. The predominant leadership style in a less agile environment is more autocratic in style.
The goal of a more agile leader is to enable and grow their most valuable resource — namely the people who work for him. The goal of a less agile leader is growth at any cost, often at the expense of the people.
An easy behavior to for is observing how issues are handled. Do the leader respond with the answer or recommend an action? Or do they respond by asking a question?
Another behavior to look for is observing how impediments are handled. An agile leader doesn’t mind getting their hands dirty and does what is necessary to solve a problem. A less agile leader tells other people to do the dirty work.
Time for teal?
Looking at this list of behaviors, the process framework of Scrum and the list of techniques associated with agile, it’s clear that agility doesn’t have anything to do with the industry you’re working in or what process model or tools you use.
What matters is culture. And leadership.
Both, which has been around for much longer than the word “agile” or Scrum. Toyota, who is one of the key influencers who helped shaped Scrum, was more agile then than many companies running Scrum now.
So is agile dead?
Is it time to let go?
Personally, I would vote with a definite “yes”, and with a tear in my eye as it is close to my heart. Luckily endings are merely there to make space for a new beginning.
And that new beginning still needs a name, but it’s already here in the form of “teal”. “Teal” being as wrong as the world “agile” grammatically, but refers to whole organizations seen as living organisms whereas Scrum was born viewing organizations as a machine.
Related posts:
Originally published on Medium: https://funficient.medium.com/is-it-time-to-let-go-of-agile-33cfdce5bcea