What do you think of, when I say the word Impediment to make an agile team. I know most of the agile/scrum teams are familiar with this term.
Ekipa.co – Agile teams normally fail 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 to make an agile team with these impediments.
I want you to think about 5 things that popped into your mind when you hear 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 nowadays but one thing I know is that we tend to forget about all the little things that take time. Things like waiting for the product owner or waiting for stakeholders to make a decision. We can define impediments as:
So let’s talk about noticing and listing down the impediments. When we talk about how to make an agile team, Scrum is a great framework to deal with it.
This third question 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, 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?
Read More: 6 Steps to Begin Your Agile Transformation
I agree standups 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 with 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 to make an agile team, 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 is 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 listened to the language 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.
Read More: Does Agile Work for Non-Software Projects?
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 can’t tell it. 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 criteria mentioned, not for the whole 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 taskboard, they will end their definition if they write or print and see if you can find at least three obstacles.
So we’ve already discussed 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 why they can’t go faster. That list, that’s your impediment lists make an agile team. If you’re lucky, your team will tell you a lot about what to change to go faster. Again, impediments for you to solve.
So as an exercise I’d like you to think about which of these questions is more appropriate for your team right now. Try to ask them, either how confident are you. Then, 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 are always some that are a little bit tricky.
And for that, wait for my next post. I’m going to share some of my thoughts on how we can solve that tricky problem. If you have any questions, feel free to leave a comment so that others may find it useful.
Hope you can make an agile team fastly. All the best with your agile impediments guys!