Lean Thinking

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.

Written by Published in Agile

In the last post, we looked at estimating by essentially not estimating. To do that we broke down stories into two categories - small and the rest. Small stories were ready to be accepted into the team's backlog, the rest were too large and need to be broken down further. By doing this, velocity becomes just a count of stories completed and all the hassles involved with story point estimation just go away.

To me, this is a real no-brainer. Why wouldn't you estimate this way? But whenever I mention this in polite company, I tend to get some uncomfortable silences, strange looks and the inevitable - "but....". These buts, tend to come in three types -

Written by Published in Agile

 

Last time we looked at T-shirt sizing and some of the benefits and problems that method has. We found that its greatest benefit was also its biggest disadvantage. The use of something completely abstract (T-shirt sizes) removes all our cognitive biases around numbers but by not using numbers we can’t really compare estimates against each other and make predictions except by converting back to numbers which of course brings our biases back.

We can use T-shirt sizes usefully if we make an adjustment to the scale we use. Rather than have Small, Medium, Large and Extra Large, let's just have Small and Extra Large. Now, this would obviously never work for clothing because people come in a range of sizes. Stories come in a range of sizes as well, so what gives? What makes this useful? The trick here is that unlike people where we can’t dictate what size someone should be (outside the modelling industry and certain trendy nightclubs), we can, and should, be pretty strict about what size a story can be before we accept it onto a sprint.

Calendar

« May 2019 »
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