You know I want to get something off of my chest - and that is the word "agile" I hate it! Every company, left, right, and center seems to spout the same nonsense - "oh yeah, we're agile".
Let's break it down
What does "agile" mean in actuality, agile is not a process, it's not a methodology, it's a state of being. I know this sounds a little spiritual but how else would you describe it? Agile is not something you can turn on or off, it's not something you "do" it's something that you are, or something that you are not.
I hate interviewing for companies in insert current year here because every company has this weird thought that if they are "doing sprints" and "planning" and "retros" that those three things means that they are "doing agile".
I am simply here to say you are wrong.
Which I know is a silly thing to say, I am not an authority on the subject, I have indeed read some books on the subject and think I have a good grasp on what is meant when someone says that they want to be agile.
Now I am not saying that every company doing these things are not agile, I haven't seen one yet but I bet there are some companies out there that are doing these things and are very agile and are very good about it. What I'm saying here is that doing these things doesn't make you inherently agile.
So what is Agile?
Agile is about:
- Allowing workers decide how they work
- Delivering value
- Communication
- Having all of the decision makers close - if not in the team - so that decisions can be made easily and quickly with the right information
- Allowing workers decide what to work on next (what makes most sense)
I think I have ranked these in the order I see as most important to least important - but that is not to say that the least important thing on the list should not be addressed, it certainly should I'm just saying that this is probably something you should think about once you have all of the other pieces in place.
So why all this nonsense
All of the ceremony around agile actually has a purpose let's try and break them down:
Stand ups
This is a quick communication session (trying not to use the word meeting here) that is trying to establish the state of play, I have not specified a time space here because it is actually unimportant you can do these sessions hourly, daily, weekly, monthly as long as people are informed on the most important thing to be working on right now and the state of the work, these are the three things that should be focused on:
- Quick status update on where the story is - how it's progressing and if applicable how long is left to move the story to completion.
- Is what I'm doing the most important thing I should be doing at this moment in time
- Is there anything that is blocking me from doing what I need to be doing - if there is is there anyone in this standup who can help alleviate this issue.
I have seen two main ways of achieving this, workers communicate about their current task what they are focusing on today and what - if anything is stopping them from doing said task. The second is "walking the board" going through each story in play and communicating the state the is in and how we can progress that particular story as quickly as possible.
Planning
This is a strategic look forward onto our next iteration, what value we believe we can deliver in the next iteration. Here we are responsible to estimate upcoming stories and to communicate how much we think we can achieve in our next iteration, again time span in not the important part here, if your sprints are a month long then so be it, you don't have to wait until the end of the sprint to deploy things.
Retrospective
Strategic review of the last iteration, this can consist of:
- A review of the value that we have delivered (the good)
- A review of what we failed to deliver (the bad)
- What got in our way (the ugly)
AND THE MOST IMPORTANT PART
How can we do differently to make the next iteration better
I feel this is missed a lot of the time, but making small changes over time is the most important thing! What can we try differently in the next iteration that may make us faster/deliver more value. Set achievable goals like we want to deploy X product Y amount of times without any bugs. Will you hit that goal, well there is only one way to find out! that's to try new things ! Feel the pain of trying something new, if it doesn't work try something else until you have a well oiled machine that can handle anything.
--
All of these ceremonies help in the larger "agile" discussion, each has it's purpose and each should help any company/person become more and more agile, but only when applied properly. If you just see them as "things we need to do to be agile" then you are completely missing the point, you are missing the value of the ceremony, and hey that is fine! Maybe these things are not for you - that is fine!! You can be agile without these, these things are merely a good way to start to move into the agile way of living, it boils my blood to hear companies describe themselves as agile and then rattle off this template of things they "do" to be agile, it's like they have literally googled the word and just settled on the first thing they saw.
But it annoys me more because they miss the point, the real value of agile, remember that thing I said about workers being able to decide how they work? That is pretty important because every team works differently, you can't just apply something that worked "over here" to another team "over there", it's simply not possible, their way of working will be completely different.
Top comments (11)
Agile is the opposite of waterfall. Waterfall is based on the "failure is not an option" dictum. Agile is based on "failure is the only option" dictum.
Any team who is not working following the "failure is the only option" dictum is not doing agile. It's as simple as that. No need to make it "Buddhist" or any other similarly silly complication.
Why is it silly to compare secular Buddhism and Agile? Both are non-religious philosophies that
In fact, I deep dive right into why “retrospective meetings” are not dumb and in fact are one of the healthiest things you can do:
Fixing Bad Habits By Learning To Love Them: Agile Retrospectives
Cubicle Buddha ・ May 15 ・ 5 min read
Not silly to compare it. But I'm a big fan of Occam's Razor, so I prefer not adding complexity.
+1 great point
I'd say Agile is a state of mind -- I'd rather avoid any religious implications because that's a big part of the problem with how some companies practice Agile: they adhere to a set of rituals without really understanding the rituals' intent, and they think they have to religiously stick with those rituals because the rituals themselves are the key to success.
The Agile manifesto is very short/simple. The great irony has been that one of the manifesto principles -- "people over process/tools" -- has been completely flipped. Now, some companies think that the process (which usually includes at least one tool like Rally/Jira/Aha/etc.) is the thing, and you better follow that process or else. They think the process is a (magical) formula which will help you beat the competition.
Sadly, they don't see that teams should be constantly challenging the process/formula to ensure that it serves its intended purpose: deliver value as quickly as possible.
Agile has been the object of a lot of hate in the last few years, but that's really because of misguided people who think imposing some set of practices is the way to achieve the intended results of Agile. Frankly, those people are often managers who are insecure about having a truly empowered, self-organized team. Those managers wonder, "Why am I here? Am I deemed necessary? Do I have job security if I'm not... ya know... managing?" They aren't comfortable with truly extending trust. Yet, without trust, there's really no point in even pretending to believe in Agile principles.
This is all so true. Especially about the ceremonies. It seems like companies just do them because everyone else is doing them. You say: "Why do we have a board?", "What is the purpose of stand up?", "Why do we do what we do?" And it's all blank looks or "Well, we do it because we're doing agile, not waterfall!". There's no understanding of the purpose behind anything so all the value gets lost.
I have worked on a team that did everything by the books, had all the ceremonies, followed all the rules (i mean, being 100% inflexible and intolerant of mistakes and delays) but in the end, the results were not being delivered, customers were pissed off.
They attributed that bad result to the "costumer is not used to being agile
You rang? But seriously, there are a lot of parallels between Agile and Buddhism. So I think it’s okay to think about it in a spiritual/philosophical sense if it helps embody the values and not the process of Agile:
Samsara: 5 Agile Techniques to End Suffering And Increase Learning
Cubicle Buddha ・ Apr 7 ・ 6 min read
see also
No, you are not wrong, the modern version of "agile" doesn't really look anything like functioning agile principles.
Agile isn't worker focused or about allowing coders to decide what to work on. If anything it's a strategy of risk management, communication and pragmatism