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.

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.

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.

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?

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.

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.

Most agile teams these days organise their backlog into user stories. The user story isn't mandatory in any agile methodology but they have become the defacto standard for agile projects. There are many good reasons for this, not least of which is that a well written user story keeps the focus squarely on delivering something of value to the user. Many user stories though are not well written. It takes more than using "story normal form" - As a I want so that I can - to generate a good story.

Many of the backlogs I see are filled with stories that, frankly, stink. Bad stories don't keep the focus on what is important. They distract, confuse and mislead. There are some criteria like INVEST that we use to assess user stories and properly applied they make a big difference to the quality of the stories. They do take some time to learn and apply though so I'll give you a few quick tips to get started. Over the years I have come across a number of common mistakes that teams make when writing stories that cause their backlogs to stink –

I have noticed a trend recently in the Scrum community of de-emphasising, or getting rid of entirely, the concept of Tasks. Teams are encouraged to just run with stories and no finer grained level of detail. I’m not sure this is a good idea. I do have to say here that when I say "tasks", I am not necessarily talking about technical tasks. A task (to me) is something of less than a days duration that needs to be done in order to get the story done. It could be a sub-story, a technical task or a single acceptance criteria, or whatever the team uses to break down the stories into smaller chunks.

I do a lot of coaching at large companies. Big, monolithic, and often very conservative organisations. Organisations like that are very difficult to change. They have become big and successful by being conservative and risk averse. There is a lot of resistance and inertia. They may recognise the need to change. They may recognise the benefits of change. Actually making that change though, means taking risks and they just can’t quite take that step. They will fiddle around at the edges and do some cosmetic stuff, but actually changing into an organisation that embraces innovation and risk is just a step too far.

At work I do a lot of stuff. I help teams produce software that is used by millions of people. When I am home on the weekend I do more work, but it's different work. I work with my hands producing things. Physical things. Although what I do at work is valuable (far more valuable in dollar terms than my attempts at DIY) I almost feel more of a sense of satisfaction at seeing a finished thing worth $50 roll out of my workshop than a million dollar project roll out of one of my teams. Because it's real. Because I can touch it and pick it up ( well, maybe pick it up... some of them are quite heavy). Because it is a physical thing.

In the Agile world, we (and I am certainly no exception) talk a lot about Self Organisation, but what does that mean? What is this thing called Self Organisation?

Let’s look again at our team from the last post and take a closer look at the Team Lead. It’s easy to see how Fred got into the situation he was in. The job of Team Lead is very unclear in an Agile world. One of the agile principles is that all team members are equal so what does a team lead do? I usually recommend that teams don’t have a team lead. That forces them to look after themselves rather than relying on a team lead to do it for them.  Most large organisations though insist on having a Team Lead for every team. That’s OK. We can live with it. We just need to work out what an agile team lead does.

I recently coached a team that had a problem. Actually, they thought they had a lot of problems. Their builds were a mess. Their environment was unstable. Their tests were broken. They were finding it very difficult to get any work done. Their once excellent planning was starting to drift away from reality. When we started to look into these problems though, it became clear that all these problems had one single cause – their team lead.

Hi Folks

We probably all know the old story about the tortoise and the hare. Speedy hare raced off, got tired and had to have a rest while slow tortoise kept plodding on at a steady pace and eventually won the race. Even hare's mad dash towards the finish wasn't enough to catch up. Everyone knows the moral of the story - slow and steady wins the race. When it comes to running projects though, we behave more like hare than tortoise.

Hi Folks

If you ever visit a lean manufacturing plant you will see, at every workstation, a cord or button or lever attached to a big, red, flashing light. It's also attached to the production line machinery. Press that button, pull that cord or move that lever and two things happen - first, the big, red, flashing light starts flashing and the production line stops. In Lean Manufacturing, this system is called Andon (Japanese for Indicator).

Hi Folks

In my last post, I mentioned in passing the phenomenon of sub-optimization - where optimizing one part of a process negatively affects the throughput of the whole. This is covered by the seventh (and probably least understood) principle of Lean - See The Whole.

Hi Folks

In many companies, resource utilization is considered an important measurement. The idea is that resources, whether they be machines or people should be occupied as close to 100% of the time as possible doing chargeable work. On the surface this looks pretty sensible. No point having people spending time doing things that the company doesn't make money from is there? The more time people spend working on chargeable tasks, the more money the company makes. Right?

Hi Folks

I had a discussion recently with a group of software architects about whether Architecture had a place in Agile development. This is an important (and at times hotly debated) topic so I'm going to expand on the discussion here.