Key takeaways
|
One of the main complaints I hear about books or blog posts on the subject of Agile is that they are fluffy and that people don’t know where to start, basically:
That all sounds great, but how does it work in the real world?
This is a complaint I am always working to help with by providing people with specific tools that they can try to get them started. Of course Agile is more a way of thinking than it is a particular tool or practice, but sometimes you simply have a problem you need to solve and getting a starting point will make a big difference.
So, let me show you some tools that might help to remedy some very common issues that I see. These tools are very simple and can be implemented in less time than it takes to read about them, but can still make a real difference.
Morning Meeting Protocol
Do your morning meetings meander? Are the unengaging and dull? Do people stand around waiting for the Scrum Master to point at them so they start talking? Does everyone recite off what they did yesterday like they’re reading from a script?
If this seems familiar to you then you might want to consider implementing a Morning Meeting Protocol.
A Morning Meeting Protocol is simply a collection of the the items that are important to cover in your team's daily meeting, but it has a lot of power on moving away from simply having a ceremony to solving real issues that your team faces.
Here’s an example to get your started:
Using it is very simple, you start your morning meeting and systematically go through each item on your protocol. You can have it simply written or printed in the team area, or you can have it as a slideshow, I personally prefer this approach because it brings focus and prevents people from running ahead to other topics. The slideshow can also be handy because if you have web pages (build system, monitoring, inboxes, etc.) you need to look at as part of your morning meeting you can include them in there directly.
What your teams puts in there’s is entirely up to you, but try to move away from simply having the standard reporting that usually exists in a morning meeting. Think about things you need to stay on top of day to day, things that are often forgotten, focuses you want to have at this point in time, and if you find things are often slipping through the cracks this is the ideal place to put them.
The Morning Meeting Protocol brings a structure and rhythm to the meeting that makes it feel a lot more productive. Finally, the structure is a great first step in building the muscle memory we want to make it so eventually we don’t need to protocol at all!
WIP Protocol
One of the biggest issues I see with teams starting out with Kanban revolves around actually sticking the WIP limits that they set. Kanban has very few rules, and choosing not to follow one of the few it doesn’t have is bound to not result in the outcome we’re hoping to achieve.
But people naturally wonder:
Are we supposed to sit around and do nothing when we reach a made up number on a whiteboard? That sounds a little crazy...
That does sound a bit crazy, and isn’t at all what Kanban is advocating at all. The way I see it Kanban isn’t trying to make us act blindly and without thought, quite the opposite, it’s trying to make sure we stop and think before we simply start pulling more things into an already overcrowded work queue.
Kanban’s mantra is:
Stop starting and start finishing!
So, what do we do instead of sitting on our hands? This is where the WIP Protocol comes into place. It’s a simple set of things we try and consider before we even consider starting new work. Here’s an example:
You can put anything you like on your list, just keep in mind that starting new work and is always the last resort. Finishing something you already started or preventing the blockage from happening in the future is a much more preferable option.
Sick Days
Do you have too much competence ownership in your team? Do you often hear things like “That is a typical (insert person's name here) job” or “only (insert person's name here) knows about (insert subsystem or component name here)”?
This is an all too common issue in IT companies, and is a seriously dangerous situation to be in. Especially in the modern age where people do not stay at companies for long durations of time anymore. All companies know this and all talk about how they need to start doing something about it. But very few ever actually do until that person finally announces that they are leaving, then they need to make do with a brief handover period and muddle through without them until the next person becomes an expert in that area and we repeat this process all over again.
This reveals two things:
1) You won’t take care of it as long as the other person is available
The temptation to get through it quickly is simply too high. Pressures are always high, and when faced with the choice of having someone who can do it quickly and someone who needs to first learn and then can do the work, we are always going to choose the faster option.
2) You can actually pull it off when you need to
When it comes down to it, when the person is actually gone, the people you have ARE capable of stepping up and taking over this system. There is no chance that all of the information that person has in their head is being handed over during a 2 week period after they have resigned. What is happening is people are being show the basics they need to get started and figuring it out from there.
You can keep using this strategy if you want to, but it’s not the most effective way of going about it…
Enter Sick Days!
Sick days are a low risk low cost model for starting to address this issue.
The setup is quite simple, you create a rotation amongst team members that are “sick” on different days. When someone is sick they go and sit somewhere else away from their normal work and team members are instructed to do everything in their power to avoid bothering the sick person unless they absolutely have to.
If someone cannot possibly make progress without the help of the sick person then the first step is to “call them at home” and get a consultation, they do not go and speak to the person, they do it over the phone.
If a consultation is not enough then you “can go to their home” for an in person consultation.
If the situation is really dire, then we “force the person to come in” to fix the problem when they are sick.
Finally, we keep track of what course of action we needed to take, for whom, and in relation to what. Below is a simple example of how you can do that:
How does this differ from just telling the people to start sharing their knowledge you ask?
Firstly, there is an important mental shift for everyone when the person is not physically located where they usually are, it makes the barrier to asking and getting involved higher and means we will force ourselves to try harder to solve it without their intervention.
The rotation lowers the amount we are slowed down by spreading the effort out over time, we only get slowed on one thing for one day at a time, so the upfront cost is not so much.
We actually know what we should be focusing on. When doing handovers or knowledge sharing we naturally focus on the things we think are important to do, but with this approach we get the actual issues we are going to get if the situation arises.
We start to track the problem! This makes it a lot easier to motivate investing in addressing this issue. It’s a lot easier to convince people of the need if instead of saying “this is high risk” we can say “in a single day we needed to ask Patrik to save us 4 times, if he leaves the company we are totally screwed”.
And it does all this without putting us at the risk of not having the actual knowledge when we need it, and allowing us flexibility when we decide that something urgent today is in fact more important than the future.
Conclusion
So there you have it! Some very practical tips to help with some very common problems. None of these tools are going to solve all your problems overnight, but hopefully they have provided some value and provided you a solid starting point.
All the tools I work with are constantly evolving, this is not their final form, and I encourage you to experiment with different versions yourself in the hopes of finding something that fits well in your context.
If you're looking for more inspiration I have a lot more available in my book.
About the author
Jeff Campbell is an Agile Coach who considers the discovery of Agile and Lean to be one of the most defining moments of his life, and considers helping others to improve their working life not to simply be a job, but a social responsibility. As an Agile Coach, he has worked with driving Agile transformations in organisations both small and large. Jeff is also involved in the Agile community outside of the work place being one of the founding members of Gothenburg Sweden’s largest agile community at 700+ members, a community run agile discussion group which he has helped to spread to 3 countries. He also organizes the yearly conference Brewing Agile.
