BT

Actionable Agile Tools

| Posted by Jeff Campbell Follow 0 Followers on Oct 27, 2016. Estimated reading time: 8 minutes |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

Key takeaways

  • Make your morning meetings not boring and more effective.
  • Help your team keep on top of what really matters to them.
  • Help your team get started right with Kanban.
  • Stop putting off knowledge sharing until tomorrow.
  • Motivate to your organisation why knowledge sharing needs to be invested in.

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

"Sick Days" seems very pomising. by Piotr Laskowski

"Sick Days" seems very pomising.

What does the sick person do? by Noah Hartl

I may have missed it, but what does the "sick" person do when they are away? I get that you hand-off their work to another person to carry forward, but what is the sick person doing? Thank you

Re: What does the sick person do? by Jeff Campbell

Hey, sorry, didn't see this for a while.

What that person does is up to the team to decide. Generally, we have them work on technical improvements, paying off technical debt, infrastructural changes, tooling or something like that.

But the most important part is that they are not working on "what they are best at", because we need to see when we can't handle that ourselves.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT