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!

Challenges and Benefits of Adapting to Agile Methodology

It's always a nightmare when we usually think about getting and setting a team to work together. A team comprises of resources with different attitudes, personalities and roles, working in a similar environment and that is the reason you are in need of some guidelines  and processes in place to keep thing always good and move forward. But trust me, in the long run still you will come across so many challenges. 

Agile Is Fast, Flexible and Iterative.

Today, “agile” is a common usage /practice in many of the software companies. As we all know it's main purpose is to solve many of the problems software teams encounter using the traditional waterfall methodology. In contrast to waterfall, agile is an iterative, responsive approach to building software. It is meant to provide more freedom for the designers and developers as they work on individual modules.

In agile, usually the teams work in sprints (may be short or long), instead of implementing the whole software applications from scratch to finish. The duration of a sprint varies from 1-2 weeks based on the requirements. The main advantage is that, by using an approach like this, both the software testing and customer feedback happen simultaneously rather than waiting for the completion of entire software for attaining these things. 

Waterfall to Agile - What made the transition ?

As we all know, every project or products is entirely different in the world of software development. There is a traditional approach of sequential process  followed by the software teams which was called “Waterfall”.

But in the past several years most of the companies have moved away from the waterfall model. There are a number of reasons for this shift. Mainly this approach was not flexible enough for the fast paces ever changing world of software.

With this approach you will define all the requirements up front and chances are there you stuck with them for the duration of the project. That means, literally you could be building something that was conceived several months before and it may not even be relevant anymore in the current context.

This linear approach has always restricted the software teams and the products they were building. But still, waterfall remained the norm for many decades.

Challenges in adopting agile methodology and how to overcome them. 

 I would say Agile is always a new way of thinking, managing and working. But it's a fact that just like any shift or change in process, many teams have struggled to adopt agile.

However, like any change or shift in process, many teams have struggled to adopt agile. It requires a new way of thinking, managing, and working. Here are some of the common challenges in adopting agile methodology and how to overcome them.

Challenge #1: Getting your client on-board with agile.

For many of the clients, Agile is quite an unfamiliar way of working together which could eventually be really uncomfortable. As in the case of software teams, Clients/Customers are also resistant to change. But there are ways you can overcome this fear of adopting agile though.

Solution: Build trust.

It’s really important to build trust from the beginning, and continue building it after each sprint. By engaging the customer the right way, you’ll build that trust and they will become more comfortable and excited about working with you in this capacity. Worst case scenario is they don’t get comfirtable with agile and you continue to practice agile internally, while bringing in the traditional project or account manager to take on the role of product owner.

Challenge #2: Agile is a cultural shift.

Agile methodology requires your organization to encompass certain values and beliefs. It always require a lot of trust from management side that your team can not only do the work required, but also do it in the best way possible. Your team needs to believe in providing value to both the customer and the product, and you need to empower your team to be creative, make decisions, and work together. Conversely, your team needs to be independent and there by should be able to do these things – make decisions, work well together, and think outside the box.

Solution: Hire an agile coach.

If you’re new to agile or finding that your team is struggling with the shift, it might be worth bringing in an experienced agile coach to avoid some of the issues. If that’s not an option for whatever reason, empower your team to get out in the community and learn from other agile experts.

Challenge #3: Many people think agile should be done exactly a certain way.

It’s often thought that in order to be agile, you need to follow every rule and guideline as instructed. Sure there are a lot of ideas, techniques and practices that go into “agile”, but the perception that there is only one way to be agile is not correct. In fact, it’s far from the truth.

As Anjuan Simmons says,

“Agile is not a one-sized-fits-all methodology that works for every situation. It is a framework that is meant to be flexible.”

Solution: Try different approaches.

In agile itself there are many approaches. Select the one that suits you and go for it. Scrum is by the most popular. But others are also fairly popular today. Search and find these approaches and see which one suits your team the most. Once you settle on one, feel free to change it so that it works with you and your team. It’s ok to only implement some of the techniques.

For example, Maybe one week sprints are too short…try two weeks, or four weeks…whatever works for you team. Likewise, if work break down structure or planning poker isn’t working for estimation, try a different estimation technique.  If daily stand-ups are getting stale and lacking value, move to every other day. Try new things until you find what works for you.

In Conclusion

In short agile enables us to move quickly and easily. Lots of advantages are there to working this way, but it can be a big undertaking and a significant shift in the way teams think and work together. Always know that while adopting agile, the more you prepare and the more you experiment with different ideas and techniques, the better off you’ll be. Never ever try to force it on your team – find what works for you, your team, your customers, and I would say for sure, With this new way of thinking, managing and working, you’ll be on your way to a fast, flexible way of working.



I hope, you might have found these tips to avoid challenges in adopting agile methodology useful. Please lemme know your views and comments .