A nice short post this time to ease myself gently back into the business of blog writing in the new year. I hope everyone had a fantastic holiday season filled with as much of your chosen way of celebrating as you could handle without doing yourself lasting damage.

How many times have we seen this situation - it's standup time and the team are gathered around the board sipping their morning coffees. "I need to raise a blocker" says one of the team. "I need some help with the design and I've been stuck since lunchtime yesterday so can anyone help out this morning? I probably only need 10 minutes". The team discusses the problem, tasks are rearranged and the team works out how to get the job done. Sounds great doesn't it? But there's a problem here. Can anyone see it?

Ever been in a standup and heard something like this - "I could complete this task but I'd like to re-factor the code one more time"? What about this one - "All the acceptance criteria are met so I could move this story to done, but I won't because there are a couple of additional cases I think it should handle as well... So I'll add a couple of extra tasks and work on them today"? What about this - "The feature is complete but we can't put it in production yet... It really needs to be bundled with that other feature to make an impact in the market" ? Or this - "The MVP is done but we have decided to hold off on releasing it to market because it's not the complete, fully featured solution our customers would expect"? Or this - "We have decided to delay the release by another couple of sprints to add in some additional features that will enhance the customer experience some more"?

One description of agile is "the art of getting things done". Done is a great thing to aim for. Done means delivering value, making a difference, achievement. Unfortunately, a lot of the time we are pretty bad at it. Done has a mortal enemy that tries to prevent us from ever reaching Done. It continually moves Done further and further away from us. We take one step towards Done and its mortal enemy moves Done two steps further away. The name of this mortal enemy? Perfection.

I have written about agile architecture before, but since I have been working with a group of architects recently (the kind that build software, not the kind that build buildings), I figured it's time to revisit the topic. The question that kept on coming up was "how do you do proper architecture in agile?". It's a good question. Agile is all about just in time rather than up front planning and traditional architecture looks a heck of a lot like a type of upfront planning. We even have a special term for what we want in agile environments - emergent architecture. Architecture that emerges just in time from the team. The problem is that while emergent architecture works fine in some problem domains, there are others where emergent architecture just isn't enough. If you're designing banking systems, or safety critical healthcare systems, or even just regular old big complex systems, relying on emergent architecture simply doesn't cut it. You need some level of upfront thinking (or at least longer term than a sprint or two ahead) to make sure your product doesn't fall in a heap.

Some of the scaled frameworks recognise this and introduce the concept of "intentional architecture" for the upfront stuff. The amount of intentional vs emergent architecture you do is a function of the type of system you are building. That's great but it still doesn't tell us much about how to do architecture (emergent, intentional or otherwise) in an agile environment. Before we look at how to do architecture, we should start by understanding what architecture is, and more specifically, what it isn't. Let me start by saying something really important. Remember this, there will be a test later - architecture is not the same as design. Many organisations, actually all organisations that I have worked for so far, have been getting architecture wrong. In these organisations, the architects didn't actually do any architecture. They produced detailed design documents. That's design. Not architecture. Detailed design absolutely should not be done up front.

We have now covered six principles -
They are built around small, self-organising teams

• The team has a clear vision of what they are doing and where they fit into the bigger picture

• The team has a well defined backlog of work

• There is a content authority responsible for making sure decisions are made quickly

• There is a clear bidirectional service agreement between the team and the rest of the organisation

• There is a fast feedback loop that allows the team and organisation to optimise both the process and the product.

At this point we have everything we need to enable a team to operate in a really agile way. The team doesn't need anything else. So why are there seven principles?

So, where are we now? Over the last few weeks we have looked at the first 5 of my agile principles -

• They are built around small, self organising teams

• The team has a clear vision of what they are doing and where they fit into the bigger picture

• The team has a well defined backlog of work

• There is a content authority responsible for making sure decisions are made quickly

• There is a clear bidirectional service agreement between the team and the rest of the organisation

We have a pretty good setup going now - we have an efficient delivery engine (the team), a destination (the vision), a route (the backlog), a navigator (the content authority) and last time we added a clear service agreement, so the team and organisation know what's expected of each other. With this sort of structure they can really start to get things done. But there is still one more thing to add to make the team really high performing - the ability to improve.

When we left our hypothetical team last post, they had the first 4 of my principles applied -

• They are built around small, self-organising teams

• The team has a clear vision of what they are doing and where they fit into the bigger picture

• The team has a well defined backlog of work

• There is a content authority responsible for making sure decisions are made quickly

They have their powerful delivery engine (the team), they have their destination in mind (the vision), they have their route planned (the backlog) and they have someone looking head and changing the route (and even the destination) if things change (the content authority). Is that all they need?

Last post we looked at the first three of my agile principles -

• They are built around small, self-organising teams

• The team has a clear vision of what they are doing and where they fit into the bigger picture

• The team delivers a regular flow of value via a well-defined backlog of work

This gives us an effective delivery engine (the team) with a clear destination in mind (the vision) and a clear route to get there (the backlog). All good? Not quite. If nothing was ever going to change, this would be all we need, but we know this isn't the case. When doing development work, and no matter what it is we are developing, we generally aren't travelling on well marked highways. Most development is, at best, navigating though a confusing maze of back streets and at worst, blazing our own trail through virgin country of varying degrees of ruggedness.

Last post I put forward 7 principles that I think every agile methodology should have. In this post, I'll be explaining (hopefully) what each of those principles means and why I think it is important. To recap, the six principles for a successful methodology are -

• They are built around small, self-organising teams

• The team has a clear vision of what they are doing and where they fit into the bigger picture

• The team delivers a regular flow of value via a well defined backlog of work

• There is a content authority responsible for making sure decisions are made quickly

• There is a clear bidirectional service agreement between the team and the rest of the organisation

• There is a fast feedback loop that allows the team and organisation to optimise both the process and the product.

• The methodology is self-similar at scale.

So, let's start looking at these in more detail.

Recently I put out a post calling for the agile community to stop focusing so much on executing methodologies and return to a principles based approach. To stop doing scrum, or SAFe or Less or whatever and start being agile. That has generated a small amount of comment, mostly people asking me what I mean by a principles based approach and what I think those principles are. Here is my attempt to explain both.

To illustrate what I mean by a principles based approach, I will continue with the analogy of cooking because it's my other favourite activity and because it seemed to strike a chord with those that read my last post on this. There are, as I said before (and to massively generalise), two types of cook, those that follow recipes and those that don't. Recipe following cooks can be great cooks but if they want their chocolate cake to be a little more chocolatey, they need to look for a new recipe. They can't adjust it themselves. Cooks that don't use recipes tend to work from a set of fundamental principles - this flavour goes well with that flavour, adding extra dry ingredients means you need to add extra wet ingredients, bacon makes everything taste better, and so on. So when they want a more chocolatey chocolate cake, they can adjust (add more cocoa and some extra milk to balance). When the cake collapses coming out of the oven, they can diagnose why and adjust so it works next time. When they have a recipe for chocolate cake but don't have any chocolate they can improvise a vanilla cake from the same recipe.

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.

We talk a lot about T shaped skills in agile teams. For those who aren't familiar with the terminology, think about a capital "T". The vertical line is the team's core skill, they have deep expertise in that. The horizontal line is all the other things the team is capable of outside its core skill. A good team should have skills that are T shaped (broad as well as deep), rather than "I" shaped - deep in one area with no ability to work outside that (like traditional silo teams). We don't want a team that can only work on the back end of the website, we want teams that can deliver end to end. We don't want teams that can only deliver on the shopping cart, we want teams that can deliver in other areas as well.

The more T shaped our teams are, the more flexible we can be in organising work. If we have a lot of shopping cart enhancements, we don't have to wait for the shopping cart team to become free and deliver them all, we have a bunch of teams who can pick up the work and deliver it. This is a very good thing. There are however, a few key misconceptions about T shaped teams that I have observed over the years, that are worth pointing out and correcting.

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.

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.

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.

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 among 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.

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.

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.

There seem to be two camps of agile coaches, those that advocate deeply embedding into a team and essentially becoming part of the team, deeply involved in the day to day stuff that the team does, and those that prefer to take on more of a mentoring role rather than being an active part of the team's day to day activities. For a long while, I was very firmly in the coach as mentor camp, and to a large extent, I still feel that that's the most effective coaching style long term. However, I have changed my opinion somewhat on the value of deeply embedded coaching for new teams.

I am now of the opinion that a coach needs both styles available to them and to be able to choose which is best in the situation they find themselves in. As both approaches have their strengths and weaknesses it is worth taking a look at both to see where they can be applied best.