How to make your teams deliver fast in Agile

 

What do you think of, when I say the word Impediment. I know most of the agile/scrum teams are familiar with this term.

Agile teams normally fails to deliver fast due to a lot of impediments. Some of these impediments are visible, while most of them are not. Let's try to find out how we can deal with these impediments in our team. 

I want you to think about 5 things that popped into your mind when you here this word - 'Impediment'. Just think about those 5 great impediments you have in your product/project before proceeding to read further. 

You know right when I say this I cannot read your mind and know what you guys are thinking about right now. But my sixth sense says most people when we talk about impediments think about things like a slow or broken machine or a code repository that's gone down or just a lack of resources or skill gaps in your team. Well I am not sure about my sixth sense, if it's functioning well now-a-days but one thing I know is that we tend to forget about all the little things that takes time. Things like waiting for the product owner or waiting for stakeholders to make a decision. We can define impediment as:

"Anything that prevents your team from going as fast as possible is an impediment"

So let's talk about noticing and listing down the impediments. When we talk about agile, Scrum is a great framework to deal with it. 

This third questions is what we are talking about here. Do you think we are answering this 3rd question efficiently and effectively ? I have noticed that normally people tend to mention the big impediments like broken machines, but those small ones we had talked about earlier, those don't get mentioned in that question in a proper way right ? Do you think it's not an impediment to you or not just worth mentioning it ?

I agree standup's are still a good place to notice impediments though if you listen to the language that people use you will get even more attention to the actual impediments of your team. Let me just go through a small standup example. I am trying to mimic a standup conversation happening in one of my team:

---

Dev 1: I'm busy with the portfolio page on our Web site and I'm still waiting for Vinu to finish the images. I assume he will give it to me before end of the day.

Scrum Master: I really wish we could find a way to do the images faster and I guess we just have to wait till he's done.

Dev 1: Well I'm hoping it's going to be finished soon. It was almost finished.

Dev 2: Ok, I am gonna try to work on the Event page there with Zen. We've got to get that widget working, it's actually not working.

Scrum Master: I think Zen is not available today, He is still working with Fred's team for some quick fix.

Dev 2: Oh, I forgot about that! I guess he's still busy with that. Mmm Ok, Well actually I will find some time to do it by myself then and not take a bit longer.

Scrum Master: Ok

---

In the above conversation, did you notice some of the words that they used? Some of these words we call them are impediment words. 

Let me explain. See the words given below which is actually there in the conversation above.

These words mean that there are some kind of uncertainty. All of them assuming and waiting for something. And the truth is that if there's uncertainty, chances are high that it's going to slow down the pace of the team.

Next time when you hear these words, what I suggest you do is take notes and write these words down for yourself & take it to your next meeting. Let it be a stand-up or a planning meeting and start to notice if people are using these words. If they do, try to figure out what the impediment behind that is.

Now let's talk about some other places you can look for impediments. We've looked at the stand up and listening to the language of the team using. Now I want to talk about policies and assumptions. If you think about policies, one of the policies the teams usually have in place is the definition of done and they are put in place for really good reasons. But sometimes, they can also be your impediments. 

I know a team who had something on the definition of done that, the architect had to do the code reviews. It was a good intention at that time but that can become a bottleneck if that architect is busy. And at the time of UAT one person has to do the cards reviews as per the Contractual UAT testing and the story can't be done. That might slow the team down and they could look at other ways to solve that instead. 

Assumptions are a little bit more difficult because they're not written down like policies but they can still be impediments and they can still slow the team down. One team I worked with had an unspoken assumption that they were striving for a 100 percent test coverage when they were working with a vendor, but only at the time of UAT it was known to all that 100% test coverage was mentioned only for the acceptance criterias mentioned, not for the wjole test cases. And it really messed up both the teams in delivering the product on time. I am sure almost 99% of the team might have some assumptions as well, that are slowing them down.

So what I want you to do now as an exercise is to get out and walk around. Take a look at your team's area. Their task boards, maybe their definition of done if it's written out or printed up and see if you can spot at least three impediments

So we've already discussed about what are impediments and the places to look for impediments. Here is the 2F technique which you can use to discover some more impediments in your standup. 2F stands for Fourth and Fifth. Add the below 2 as the 4th and 5th questions of your standup. 

How confident are you that we will make our sprint commitment? 

This is a great question to ask during stand up and ask it to each individual person. If they answer anything less than 100 percent, that's an indication that there's an impediment there. Dig it deeper and figure out what it is so that the whole team is confident that they're going to meet this sprint commitment.

How can we go faster?

You might think that this will backfire and the team will just come up with a list of reasons of why they can't go faster. That list, that's your impediment list. If you're lucky your team will give you a bunch of things of what to change so that they can go faster. Again, impediments for you to solve.
So as an exercise I'd like you to think which of these questions is more appropriate for your team right now and ask them, either how confident are you or how can we go faster and note down a few more impediments for you to solve. 

Now you should have a really long list of impediments that you've started to spot but that doesn't do you any good until you start to solve them. Hopefully some of them will be quite easy to solve. But there's always some that are a little bit tricky.

And for that, wait for my next post where I will share some of my thoughts on how we can solve those tricky issues. If you have anything in mind, feel free to write it as comment so that others might find it useful. 

All the best with your agile impediments guys!