Lean Thinking

Written by Published in Agile

Teams hold a special status in agile. Teams are at the heart of all agile frameworks and much of the focus of the agile community is on growing and supporting teams. Not just any teams, agile teams stress things like self organisation and cross functionality. There is no denying that a really good agile team is an awesome sight to behold. The amount of stuff they can get done is nothing short of remarkable. But there are also an awful lot of agile teams that have the same properties but their performance isn't anywhere near as good. So what is wrong with those teams? Is it the people? Is it the environment? Is it the nature of the work? What stops some teams from performing where others with the same characteristics flourish?

In an effort to understand why, I have been thinking deeply about the concept of the team; why they are so effective and why we insist on certain characteristics for our agile teams. The conclusion I have come to is that it's all about the ability to make decisions.

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.

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?

Written by Published in Agile

We have been looking at executive coaching and what sorts of conversations we can have with them as coaches. So far we have looked at resource management and financial control.  Continuing on our theme,  I'll be looking at the next burning question execs tend to have -  "How do I ensure good ROI in an agile environment?"

ROI is a term that frightens non financial folks but what it boils down to is "am I getting good value for my money?" Is the money I am spending giving me enough benefit to justify spending it? In a traditional organisation, ROI is managed through the business case and estimation processes. The business case will set out a number of benefits and the estimation process will work out how much it  will cost to deliver those benefits. In an agile environment, we don't go through those processes.  We don't do detailed up front estimates.  So how does the person in charge -  the person whose money we are spending - make sure they are getting good value?

Written by Published in Agile

Last time we looked at the most common question you get when talking to senior leaders - how to control spend. This time, we'll look at probably the next most common one - how to control resources. By control resources, I don't mean how to tell people what to do. What I mean is how to keep control of resource numbers. In non-business speak, that means "how can I manage the number of people in my team and still deliver?" This is, of course another side to the "how do I control costs" discussion, and is a particular problem for IT departments.

The answer seems obvious - just stop hiring people. Set a staff limit and stick to it. The reality for IT departments is a little more complex though and it's related to the way big organisations control the flow of work. Or to be more precise, how they don't control the flow of work.

Calendar

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