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".
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.
Agile is about:
- Allowing workers decide how they work
- Delivering value
- 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.
All of the ceremony around agile actually has a purpose let's try and break them down:
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.
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.
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.