Lean Thinking

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.

Written by Published in Agile

For the last few weeks (interrupted briefly by the holiday break) we have been looking at executive coaching. We have taken a look at some of the big problems executives face and at some of the ways we can use agile tools to help resolve them. We have looked at resource planning, controlling financial spend and estimating ROI. All these things, though, are manifestations of a more fundamental problem - the problem of control. Control is a real issue for executives. They are responsible for a P&L. They have business goals to meet. They have people under them to meet those goals. They are expected to be in control.

In a traditional environment they maintain control through their position as central decision maker. Any significant decision will be funnelled up through them. In an agile environment we recognise that centralised decision making is slow and inefficient, so we decentralise the decision making for efficiency. The problem is that, to the exec, we have taken away their decision making (and therefore their control) and not given them any other control mechanism to replace it. Without some alternative control mechanism, execs in an agile environment will continue to rely on their old control mechanism - centralised decision making - to the detriment of the agility of the group. All the unnecessary steering committees, status reports, executive briefings, financial controls, and so on are all manifestations of this fundamental problem - how does an executive maintain control when they are no longer the one making all the key decisions?

Calendar

« August 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