Lean Thinking

Written by Published in Agile

First up, this post has come about through a discussion I had with a group of other coaches, so thanks to The People's Popular Feed crowd - Steve, Pradeep, Bob, Carl, Gaya, James, Elvira and Tony for the spark.

We all know the Spotify model - squads, tribes, chapters and guilds. It's a great model and many of us have tried to implement it in other organisations. In my experience though, most of those implementations fail, particularly around chapters and guilds. One of the first things we tend to do as coaches is set up guilds. We need a way of getting people to share information across organisational silos and guilds are a great way to do that. Trouble is, it's almost impossible to keep a guild running in many organisations without someone pretty much full time cajoling and pleading with people to attend. Without someone who is willing to make the guild their life's work, they quickly fizzle out. 

It shouldn't be that way. A guild should be self sustaining. The members should be there because they are interested and see it adding value, not because George, the guild master badgered them into attending this week's meeting. So why, when they are so good in theory, are they so hard to keep running in practice? I have been giving this some thought recently (while sifting through the wreckage of another dead guild) and came to the conclusion that it's because we are doing things backwards.

Written by Published in Agile

Probaly the most iconic feature of the SAFe model is the Program Increment (or PI). The PI (for those who have never seen SAFe before) is a larger, release level timebox, usually 4-6 sprints long starting with a 2 day, all hands planning event. The PI is also the feature of SAFe that I like the least. Proponents of SAFe will, quite rightly, point out that the PI planning event is a highly effective way to plan a release and is great for getting a large team of teams aligned and motivated around a goal. And indeed it is. I still don't like them though. As effective as they are, the PI planning session, and the PI in general, have some unintended consequences that far outweigh the benefits.

The goal of agile is to enable organisations to respond to changing conditions quickly and at the team level, for teams to get stuff out to customers as fast as possible. The PI breaks this in a number of ways. It breaks flow into batches, encourages queueing and reduces the ability of teams and the organisation to respond.

Written by Published in Agile

Ok. So I have a team and I'm looking at their board. On that board, if they are like 90% of the teams out there, they will have a burn down chart somewhere. Let's take a closer look at the burn down shall we? Does it, as so many do, show a flat line until the day they all update the tool at the end of the sprint? Does it show a nice progression of tasks done over the sprint but at the end of the sprint are there no stories completed because they worked on everything at once? 

The burn down is one of the classic tools for an agile team. Everyone does burn down charts. Mostly they do them badly. Over the years I have come to dislike the burn down chart for a number of reasons. Chief amongst those reasons is that it really doesn't do what it is supposed to - give an indication of whether the team is going to achieve its sprint goal. On the surface it looks like it should - there is a list of stuff to be done and a rate at which it needs to be completed to meet the date but in reality, the burn down doesn't give a very good indication of where things really are. The other big problem is that while they are supposed to be easy, most teams find keeping a burn down chart up to date a massive headache. So let's take a look at the burn down and some of the things that cause teams pain. We'll also look at a really good way to replace it completely.

16 February 2016

Measuring Agile Success

Written by Published in Agile

As soon as you talk to anyone senior in an organisation about agility, one of the first questions that comes up is "How do we measure the benefit?" It's a perfectly valid question to ask. We are (usually) asking them for a bunch of money to implement change and quite often the benefits we describe are fairly poorly defined - better staff engagement, the ability to respond faster, faster time to market. That sort of thing. They all sound great but what really matters to an executive sponsor is the bottom line impact. Will spending this money generate additional profit? 

Unfortunately, the question of measuring agile benefit is a hard one. Other than time to market (which is actually a hard one to pull off for a bunch of reasons), all the traditional agile benefits are pretty soft. It's hard to come up with a set of hard, bottom line benefits we can easily measure and show the difference agile is making. This tends to make a lot of agile sales pitches a bit like the underpants gnomes in South Park - Step 1: Implement agile. Step 2:Ummmm. Step 3: Profit! While the ultimate metric is the profit, for the reasons I mentioned above, that's actually quite a hard metric to impact on the short term. What we need are a set of good metrics that can show progress towards increased profitability that we can measure and track in the short term. Don Reinerstein is an advocate of using an economic model to show benefits and while this is undoubtedly the right way to go, most organisations simply don't have the maturity to even consider things like cost of delay accounting until they are quite a long way into their agile/lean journey. What we need are things that any company can measure right from day one that we can use as leading indicators for increased profitability. Over the years I have come up with a set of metrics that seem to do the trick.

Calendar

« October 2017 »
Mon Tue Wed Thu Fri Sat Sun
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31