We have all heard about organisations that have successfully made the transition to an agile way of working. Some of us may even know someone who knows someone who says they worked at one once. But much like sightings of the Loch Ness Monster, Bigfoot or the Tasmanian Tiger, most of these claims evaporate under even basic scrutiny. Now, I know there are agile organisations out there. Organisations that have been born in the agile age and have been built from the ground up with agile principles in mind. I'm not talking about those organisations.

I'm talking about the old, legacy organisations. The ones with decades of process and culture to remake. The ones we are always being told (mostly in press releases or flashy conference presentations) are transforming themselves into new, agile organisations. Shedding the baggage of the past and embracing the bright, agile future. But scratch the surface and how many have actually managed to transform themselves? "But transformation is hard", I hear you say. "It takes time and many organisations just haven't had time to complete the job. What you ask isn't fair". And indeed, transformation is hard so let's relax the criteria a bit - how many organisations have actually managed to establish even the start of a real agile culture?

"Come and have a look at my team" says my new stakeholder. "We have been doing agile for a few years now and while we started well, I think we have slipped back to old habits". How often have you heard this when starting a new engagement? Quite often? What do you see when you take a look? It's usually lack of planning, absence of meaningful retrospectives, ineffective standups, lax WIP limits, poor metrics, mini waterfalls. Yep. They have slipped all right.

When you ask the team why they think they have slipped, you will usually get answers like "we scaled up and things went wrong" or "the rest of the organisation is pulling us back" or "some key people left" or something like that. In my experience these are never the real reason. They may have contributed, but the underlying problem is something else entirely. That underlying problem is almost always the same - they never had the basics right in the first place.

Last time we looked at the trend towards massive scale in the agile community and some of the problems scale leads to. We looked at an alternative approach. A scaled down approach -

"Imagine, instead of a huge program, we have small groups of teams, say 2-5 teams in a group. Each group manages its own stakeholders, environments, dependencies and the like. Each group is directly aligned to a set of business stakeholders with a common set of outcomes, is funded through an investment pool aligned to business outcomes, not specific project deliverables, and delivers value end to end for the stakeholder group."

This approach would allow the organisation to deliver value efficiently without the need for massive scaled structures and the complexity and inefficiencies that go along with them. The only problem of course is that such a structure is impossible in most organisations because they are built around large programs and large platforms and simply don't have the ability, architecture or processes to handle a scaled down operation.

There has been a trend recently within the agile community to embrace massive scale. Not just a few teams working together but really large groups. Every day we see examples of bigger programs, larger release trains, all successfully being managed through agile techniques. Just recently, a colleague ran a PI planning event for close to 1000 people spread across three countries. I have seen other organisations proudly boasting that they have "the largest release train in the southern hemisphere", with some figures on the incredible budgets that the train is managing. The SAFe framework now has 4 levels rather than 3 to enable it to manage bigger and bigger structures. Less has Less-huge to do the same.

While I celebrate the achievements of the coaches successfully helping organisations achieve this, and the incredible feat of facilitation that a 1000 person, 3 country PI event must be, I can't help worrying that this drive towards massive scale is not altogether a good thing. Large companies want scale because that's the way they are used to working. They are used to thinking in terms of large programs of work involving hundreds of people. In order to help them, we have developed techniques that allow us to handle this sort of scale. But just because we can do something, it does not automatically follow that we should do something. There are significant downsides to scale.

There has been a lot of talk at work recently about agile maturity checklists. There are dozens of them out there in the wild - the Nokia test, the unofficial scrum checklist, spotify checklists. Every organisation, at some point in their agile journey, seems to become consumed by a burning desire to measure just how agile they are, and sets about creating some sort of ultimate agility checklist mashed together from ones found online plus whatever else they can think to throw in.

There are a lot of reasons organisations want to measure agility. Some of them are good reasons, like looking for capability gaps so coaches and leaders know where more guidance is needed. There are also a whole lot of really bad reasons for measuring it, like comparing teams against each other at bonus time, or looking for conformance to a corporate agility standard. The biggest problem though with most agility checklists is that they measure the wrong things. They tend to focus on specific practices rather than focusing on desired outcomes. They are doing agile checklists not being agile checklists.

It's always good to go back to first principles occasionally so let's take a look at the agile manifesto. How does it go again? Processes and tools over individuals and interactions... No wait, that's not right. It's the other way around. But anyone observing the agile community over the last few years would be excused for thinking otherwise. For a group that follows a manifesto that explicitly prioritises individuals and interactions above processes and tools, we certainly get very hung up on processes and tools.

Be warned...this is a bit of a rant so you might want to stand back to avoid getting any on you.

Take a thin steel rod. I'm sure you have one handy. Clamp one end in a vice (which you also have handy...I know I do) so that it's sticking straight up in the air. Now move the free end of the rod to the side a little and let it go. What happened? Did it spring right back? OK, now move it a little further. Still springing back? If you keep going, moving it a little further each time, you will find a point where the rod no longer springs back but bends permanently. Materials scientists call this the elastic limit. Below this limit, materials experience elastic deformation - they spring back to the way they were before once the force is removed. Above this limit, they experience what is called plastic deformation - they no longer spring back but permanently change shape.

So why am I giving you this lecture in materials science? Because organisations behave the same way. When you apply a force to them - when you change something - the organisation is very good at snapping straight back to the way it was before.  As soon as you stop pushing the change, the change disappears. We've all seen it happen. As soon as you relax, the change evaporates and within a short time the organisation is happily doing what it has always done.

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. 

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.

It's a couple of days before the end of the sprint, we're in the standup, there is still a bunch of stuff "in progress". "We can't finish it" says the team. "We're blocked. The code is frozen for the sprint demo so we can't check in 'til next sprint, and besides, we need to spend today getting the demo prepared for tomorrow so we can't do anything else anyway". I've seen more than a few teams lose days out of their sprint making sure their end of sprint demo is perfect. They end up essentially running an 8 day sprint rather than a full 10 days. The demo becomes the primary focus of the sprint. It's not supposed to be that way.

The scrum guide says that the teams should spend no more than an hour or so getting ready. Why do so many teams end up spending days? It's because they have lost focus on what the ceremony is about. The purpose of the demo is to show the team's progress towards working software. It's not a sales pitch. No one is selling anything. It doesn't have to be perfect. I think teams fall into the perfect demo trap because they call the thing a demo. The recent trend is to call it a showcase which is just as bad.

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 –