Lean Thinking

Written by Published in Agile

We have been looking at organisational alignment patterns over the last few posts. We have covered the two common ones - bottom up and top down. Today I'll look at a far less common one - Middle Out. As the name implies, this pattern occurs when change is being pushed by the middle of the organisation - middle management.

Actually uncommon is an understatement, middle out is so rare that I have never seen it in the wild. It's still worth looking at though, as winning over middle management is key to the success of the top down and bottom up patterns we looked at previously. By looking at why middle out is so uncommon, it can help us to understand what prevents change from occurring at this level in large organisations, and to see what we can do to change that. What we are talking about here is the phenomenon of the frozen middle.

Written by Published in Agile

Last time we looked at the bottom up pattern. Today we'll look at its inverse - the top down pattern. In this case, the top levels of the organisation want agile but the levels below them are resisting (again, if they aren't... great, but that's a different pattern). This can be a tricky pattern as senior execs may want agile but often don't know much about what it is and what it means for their organisation. With most agile adoptions, you need to spend a lot of time educating your detractors, with this pattern you may need to spend as much time educating your supporters as well.

They probably see agile as a delivery methodology and expect it to be implemented that way. They don't see it as a major cultural change at all levels (including theirs). Tread carefully. Don't lose them. It's very easy to go in too hard, making it seem like too big a change too quickly. Senior managers got where they are by successfully managing risk. They tend to be quite risk averse. They will want to see a strategy that manages organisational risk during the transition.

Written by Published in Agile

Today I'll start looking at organisational alignment patterns. The first thing I should do is explain what the heck I mean by that. In this context, organisational alignment is which parts of the organisation are supporting an agile adoption. This is a really key thing to know because where the support for agile is coming from will seriously affect how agile can be introduced, how far it can go before it meets resistance, the type of resistance it can meet and so on. Having worked as a coach in a number of companies, I have found that organisations tend to align around agile in a number of fairly standard ways. I call these standard ways alignment patterns. There are two dimensions to an alignment pattern - vertical (which layers of the business are aligned) and horizontal (which parts of the business are aligned).

If you can pick which alignment pattern you are dealing with, that gives you some insight into the sorts of issues you will experience when managing an agile transition. Knowing your alignment pattern lets you pick the right adoption pattern to get the best success. Essentially, different alignment patterns work well with certain adoption patterns while blocking others. Pick the adoption pattern that matches your alignment pattern and things will go smoother than picking one that is incompatible. Or if you want to use a particular adoption pattern but it's incompatible with the current alignment pattern, then you may need to change the organisational alignment before proceeding. Anyway. I'll talk more about this mixing of patterns later. First I'll start by describing the basic alignment patterns, starting with the most common - the bottom up pattern.

16 September 2014

Agile Patterns

Written by Published in Agile

Last post I briefly mentioned a patterns based approach to agile adoption within enterprises. I should probably spend a little time explaining what I mean by that. The first question, of course, is what do I mean by a pattern?

Back a few years, when things were still made by hand, a craftsman who wanted to make a set of things that were the same each time would make one reference piece, measured and constructed very accurately, and use it to create more pieces that looked the same. That reference piece would be carefully labelled with instructions on which way to align wood grains (or whatever was appropriate) and which techniques to use to construct it. This reference piece was called a pattern. There was even a specialised skill within workshops called patternmaker, with its own set of specialised (and very accurate) tools. So a pattern is a template or a guide to doing something. It's a way to reliably and consistently make copies of something.

02 September 2014

SAFe SPC Course

Written by Published in Agile

A few weeks ago, I went on the SAFe SPC course, and passed the exam which means I'm a fully qualified, newly minted SAFe Program Consultant. I thought I'd give you a quick rundown of the course and my impressions of SAFe now that I'm apparently some kind of SAFe Jedi master.

For those who have been living under a rock for the last few years, SAFe (Scaled Agile Framework For Enterprises) is, as the name suggests, a scaling methodology for enterprise agile adoption. It is, to put it mildly, somewhat controversial, with many deeply in love with the methodology and some very strongly against it for many reasons. In the interests of full disclosure, I should say at the outset that I went into the course as someone pretty much on the anti-SAFe side. There were many things about the methodology that I didn't like, but I'm a big believer in giving things a fair go, so when the chance came up to go on the course, I figured I'd give it a go and let the other side have its say. So... what was it like?

Written by Published in Agile

Last time we looked at the most common question we get from management -

What metrics will I get?

And saw that our usual answer - velocity - really isn't very good at answering that question. It's really only designed to be an internal measure for a single team. You can't use it to compare teams. I mentioned that Cycle Time is a much better metric to use for this sort of question, so let's take a look at Cycle Time. We will also look at its cousin - Lead Time.

Cycle time is essentially, the time a team spends completing a story - the clock starts when they start work on it, and it stops when it's done. So if a team starts a story on Monday and it's done Friday, the cycle time is 5 days. Individual cycle times are fairly meaningless (like individual velocity measurements) but over time the team will establish an average cycle time. Lead time, on the other hand, counts from when the story enters the team's backlog to the time its done. Lead time - cycle time = the time the story spent sitting around in a queue waiting to be started. Together these two metrics can answer management’s burning questions and even better, we can use them to drive some helpful behaviours.

Written by Published in Agile

When implementing agile in an organisation, one of the first questions management will ask is “what metrics will I get”. This is not an unreasonable question. They are financially responsible for their part of the business and are used to dealing with a particular set of metrics that let them assess the performance of their teams and take action if action is needed. RAG (Red Amber Green) status on projects, schedule variance, earned value, actuals vs estimates, risk profile, and so on.

When agile comes on the scene, those measures go away and management feels like they have lost control. So a question about agile metrics is perfectly reasonable. How do I, as a manager, see that my process is working well? How do I tell when things will be delivered? How do I tell how much stuff will cost? When answering this sort of question, the answer we most frequently turn to is velocity. Most agile systems have some concept of velocity – how much a team can produce in a given time. The problem is that velocity is a very poor way to measure those things at any scale beyond a single team. Velocity just wasn’t designed to answer this sort of thing. Why? Well to see why velocity isn’t a good measure for these questions, we need to look at what velocity is designed to measure.

Written by Published in Agile

Over the last 6 posts, I have been looking at estimation. First, we looked at why we estimate, then we looked at some of the pitfalls in traditional estimation methods - the way we mistake accuracy for precision. Then we looked at some of the Agile estimation techniques - story points and T-Shirt sizes and the way they are designed to overcome the accuracy vs precision problem. We saw that while they generally do a good job, they also have some fairly serious pitfalls of their own. In the last two posts, we looked at taking T-Shirt sizing one step further and allowing only two sizes - small and extra-large (too big). By doing this we saw how the main pitfalls in the agile estimation techniques were overcome. We also looked at some of the main objections to story counting and my arguments on how these objections can be overcome.

I'm not the only person to come up with this technique. It's doing the rounds at the moment under the name "No Estimation Movement". Apparently I'm part of a movement. Cool.

Calendar

« September 2018 »
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