Almost two decades ago, a handful of people started a joint journey of "uncovering better ways of developing software and helping others do it". The first value was "People and Interactions over Processes and tools".
Scrum emphasizes the values of Openness and Respect. Coaches are expected to both exhibit and nurture a Growth Mindset.
And what to we do? The opposite!
Trigger Alert - this post will push a lot of hot buttons!
What have we become?
A large number of agilists get triggered really fast, really strong and really bad as soon as they read or hear certain terms. Why have the very people who proudly bear the labels of openness and respect, become so narrow-minded and show almost hostile reactions as soon as a few trigger words are uttered?
People who even dare to use certain words get stigmatized as "unenlightened" and "anti-agile" and are being told to "defend themselves" or apologize. This is neither open nor respectful towards the individual, much less towards their ideas. Is this the type of interaction with people that agilists looking for?
When have we stopped thinking or asking, "What does the other person mean?" Why do agilists go into full confrontation mode as soon as these words are uttered? How is that behaviour different from a fascist regime where everyone who thinks different must either be converted or eliminated?
Creating taboos and instituting thought crimes fosters an environment where true agility becomes impossible.
Trigger, trigger, trigger ...
It can be that you had bad experiences a hundred times and think you understand the antipatterns, but isn't it exactly what agile practitioners are trying to teach organizations - that past experiences are not necessarily indicative of what is the most appropriate thing to do in the current situation?
Each person has their own understanding of reality, which is why communication is needed to collaborate better. Presumption doesn't get us anywhere. How about listening, before arguing? Why is it so hard to keep those guns down until the other person made their point?
Now, let's see how much I can trigger you ...
Agile Project
Where do we start with an agile transformation? Let's start an Agile Project!
Ohh, I hear you shouting immediately, "There's no such thing as Agile Projects! You must do Product Development!" - can you even smell how dogmatic and close-minded this is? You're not inviting a discussion, you're ending it!
When an organization is operating in project mode, you must start somewhere, and starting with a single, decoupled project is significantly easier than starting by changing the entire organization's structure, management and process landscape. Starting with a single Agile Project allows you to separate concerns.
Fixed Scope
We need to fix the scope for our Agile Project.
Your answer is clear: "We're Agile! That's Big Upfront Design, Waterfall!" Proposing to make the scope known upfront is met with arrogance and disdain. You wouldn't even bother to ask, "what do you mean by fixed scope", because fixed scope indicates that this person just doesn't get it.
Have you ever considered that self-organization happens within a context, and clear boundaries help teams to reach excellence?
Fixed scope doesn't mean writing a Detailed Specification Document. A team's scope is already fixed when the team is supposed to build spacecraft and not washing machines. Scope can be re-negotiated when it becomes a blocker, but operating within a fixed boundary enables teams to focus ... do you remember someplace where focus was acually considered a virtue? What do you focus on, when everything goes?
Milestone Date
Investors want to know when they can see something and want a roadmap with milestone dates. They expect a Return on Invest at some point. Within a corporation, senior management acts as an investor.
I know that you're going ballistic, "We can't know what or when!" - calling the request unreasonable and insisting on a free pass for the team.
Oddly enough, I have never seen any agilist who would invest their own money into a business unwilling to commit to results, dates or ROI - everyone buys stock from companies that announce fiscal targets and product release dates ahead of time. Where does that hypocrisy come from?
Investors pay all the bills, including the team's salary. The answer, "We do frequent Reviews" is not helpful without a specific date when it's possible to make a decision on whether to pull the plug or to proceed.
Running this decision multiple times per month would put a tremendous amount of stress on the team and promote unsustainable behaviours. Quarterly milestones give the team sufficient room to breathe and allow the business to make wise investment decisions.
After all, the business also wants to be agile - being able to spend the money on the most important initiatives, and not just let your team locally optimize what they build!
Product Roadmap
Our stakeholders want to know our product roadmap - what they can expect in the next year or two.
A roadmap instills confidence that you know what you're doing and aren't getting tossed about by every wind.
"That's not Agile", I hear you scream!
We have a product vision and a product backlog. Some items in the backlog are keys to business growth, others are just work. Take the keys and arrange them on a probable timeline. There is your roadmap: Was that so hard?
Being agile doesn't mean you stop caring about where you're going- it means that you're ready to change direction as needed. And guess what - nobody cares whether or how often a roadmap changes, as long as the current version makes sense and points towards valuable goals!
Progress Report
The next "Agile Antipattern" is the Progress Report. "We have Reviews, and thus, progress reports are a waste". The mere suggestion of a progress report obviously means that the individual doesn't understand agility and the organization wants to preserve status quo.
While we can simply assert that it would be best for the team to operate in a vacuum - they don't. They operate within a context, and that context won't magically go away just because we wish it were so.
An agile progress report generates transparency where teams face systemic impediments and where they are calling for help. An agile progress report allows senior managers to pull levers that teams currently can't pull.
Senior managers are third-row stakeholders for your team who are hardly involved. Their skin isn't within the game, but they can initiate change, and when they're responsible for dozens of teams, they can't give half an hour to each, every week - because as unthinkable as it sounds, they also do things that have nothing to do with the team's problems.
Can you respect the responsibilities senior managers have and that they are trying to use their own time as effectively as possible?
Returning to Reason
You may still disagree with the explanations I have given, but hopefully you have realized, "Yes, there's some reason behind this, and the person isn't actually so insane that they need to be lobotomized on the spot."
Speaking about our perspective opens the door to a conversation. Reasonable people are willing and able to listen to reasonable arguments. Blame and accusation aren't reasonable. Attacking the individual who speaks their mind and tries to learn closes your own door towards learning and growth and betrays the idea behind agility.
A wise person once said, "We are all where we are.
A 3-year-old lives the life of a 3-year-old, an 18-year-old that of an 18-year old, and an 80-year-old that of an 80-year old.
We can not expect the 3-year-old to live the life of an 18-year-old with the wisdom of an 80-year-old.
When we look at a 3-year-old, we should enjoy that they can live the life of a 3-year-old. They will be 18 in fifteen years, so give them time.
A 3-year-old lives the life of a 3-year-old, an 18-year-old that of an 18-year old, and an 80-year-old that of an 80-year old.
We can not expect the 3-year-old to live the life of an 18-year-old with the wisdom of an 80-year-old.
When we look at a 3-year-old, we should enjoy that they can live the life of a 3-year-old. They will be 18 in fifteen years, so give them time.
Can we have this kind of respect towards people who are not where we deem ourselves to be?
There is a lot of anger in this post, directed at an anonymous group of agilists. I don't share the portrayed experience of battling against a loose herd of unreasonable religious people who scream waterfall whenever you suggest making a plan. I do think there is a certain religion to scrum which overestimates the power of its practices and rituals and tends to neglect the true spirit of agile. I do think the industries in which we operate are often more conservative than agile software development would allow (or vice versa). But overall I find most people to act in the true spirit of inspecting and adapting to circumstances and experiences.
ReplyDeleteSo what's the real problem here? Can you share actual experiences?
Thanks for commenting, Dieter.
DeleteIf you see any anger in this post, that is a subjective interpretation which I do not share.
This article is a rebuttal to fairly standard statements which often echo throughout the "Agile" Community, mostly proclaimed by trainers who are not actively doing development work.
I offer the responses as a reflection opportunity for anyone who makes such claims.
If you're not one such person, that's great. Unfortunately, they are numerous.
Lots of truth here, Michael. When someone says to me, "That isn't agile!" I pull out a sheet showing 4 values and 12 principles and ask if it violates all of them. They say no. Then we try to identify which if any values and principles are violated. Usually, there is one principle they feel is an issue. So I say, "Great. Let's focus on doing the other 15 things and we'll say we are 94% agile."
ReplyDelete