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.

Hi Folks. Something a bit different today. It's a video post. Specifically, the video of my talk at the Agile@Scale Meetup in Sydney a couple of weeks ago.

One of the main technical practices that we recommend for teams is pair programming. Under pair programming, two people work on the same piece of code, with each checking the other's work in real time. It's a great way to boost the quality of the code delivered. It's not just code either. It works for testers (one of the most effective pairs is a developer and a tester pairing on something), UX designers, business process folks and so on. Any sort of work can benefit from a second pair of eyes.

Why then do agile coaches tend to work alone? It's very rare to see two coaches working together on anything. While we teach pairing, we coaches tend to work solo. I think this is unfortunate. On the few occasions where I have had the opportunity to work closely with another coach, it has always been a really good experience. So why then don't we do it more often?

Agile coaches help teams. Right? Having a coach to help guide a team means they are more likely to become a successful, high performing agile team. Right? That's why organisations are prepared to pay for agile coaches. But is there a down side to coaching? Can coaching hinder a team, rather than help it?

Imagine, if you will, a team. They are on about sprint 20, you are their new agile coach, taking over after the last one left. You are observing a retrospective and they are doing what they should be doing - working out what went well, and what didn't. "Why", you are thinking, "do they need a coach after 20 sprints? They seem to be doing fine". Then they get to the "what should we change for next time" bit, and all eyes in the room turn to you. "This is where you, as our coach, tell us what to do so we can get better" they say. "Work it out", you say, "Self-organise around the problem and solve it". "No", they say, "you have to tell us what to do". Then you notice that there is no sprint planning scheduled for the next sprint. "That's your job" the team says. "You tell us what to do and we do it". Welcome to the dark world of coach addiction.

First up, a huge thanks to Mike Pollard for the inspiration on this one. This all started with a meeting invite from Mike to set up some experiments in organisational change. We all know that organisational change is hard. Organisations tend to resist change so doing any sort of substantial change is a lot of work, and also prone to failure as organisations slip quietly back into their old way of doing things. Since real agile success relies somewhat on changing some pretty fundamental things in the organisation, this has always been a pretty major limiting factor in agile adoptions - success relies on change and is limited by how much change we can introduce. Change is hard which limits the amount of success we can have.

Mike's idea was quite simple - rather than try to change the whole organisation, why not set up some small experiments instead? That gives the organisation a low risk way to see what works and what doesn't. Once we have some successful experiments we should have some good, hard data to back us up when we push for a wider rollout.

We have all heard about the Release Train as a concept for managing agile at scale. It's a pretty good metaphor. A train leaves the station according to a set timetable. The passengers fill up the train when they are ready to depart and if you arrive late, you miss the train and catch the next one. Software releases under a release train work the same way - the train leaves the station (releases to production) according to a set timetable. While waiting, the train gets filled with completed features and if a feature arrives late, it waits for the next train.

Not a bad metaphor, and, for some businesses, not a bad way to organise a release cadence either. However, for other businesses, a release cadence like that is not appropriate. It may be too fast. Or too slow. Maybe what you need isn't a train, but a metro. On a metro, smaller trains arrive and leave so frequently that no timetables are needed. Just turn up and hop on the next train. Or is your release more like an ocean liner? Their arrival and departure is large, infrequent and marked by a lot of fanfare (and more than a little cursing by those doing the hard work of steering the thing in).

In the agile community we love fast. Fast feedback, fast delivery. Fast is good. Slow is bad. Why then is the most common complaint I get about agile - "All this team stuff distracts me from writing code. We can't deliver fast if I can't write code". That's a good point. We are taking our devs away from coding to some extent. In an agile team they can’t just sit down in a corner with their headphones on and just cut code solidly for a week. There's a lot of team interaction that has to go on to make the team run smoothly.

So are we, by doing agile, slowing down delivery of code? Quite possibly yes. But what about fast delivery? How can we say we are about delivering fast but slow down the people who are actually delivering the code? The thing is, we don't actually deliver code. If we just delivered code we would go out of business. What we deliver is working, tested, fit for purpose code. More fundamentally than that, what we deliver is business value, not code. Agile is all about speeding the delivery of value, not the delivery of code.

Faster, Better, Cheaper. That's the way agile is usually sold. Faster delivery, with better quality and lower cost. That's the pitch I hear over and over from people trying to get organisations on board with agile. It's an attractive pitch too. Who wouldn't want something faster, better and cheaper? The only problem with the pitch is that it's not really true. Not initially anyway. Agility will eventually get an organisation delivering faster, better and cheaper but, at least initially, it will be slower and more expensive (it will usually be better quality though). It may well stay slower and more expensive for a long time if the organisation has to overcome a lot of legacy (not just code but culture and processes as well).

So when the organisation goes to measure its new agile initiative and finds that it's not getting what it was sold, questions get asked. And well they should. The first is usually "Why?", to which the standard answer is "cultural change is hard....", the next is usually "When?", to which the answer is usually a shrug and some more about how hard cultural change is. This is often the point where the senior leaders that were really keen on agile, suddenly stop being keen on agile and organisational support vanishes. Given the length of time it takes a big organisation to get to faster, better, cheaper with agile, we really do ourselves no favours by using that as our selling point. What we need is something we can have an immediate (or at least relatively quick) impact on, that is also going to have a positive impact on the business. Fortunately it exists - risk. Agility should be sold as a means of reducing risk.

This post is the result of a conversation I had the other day, over a few after-work beers with Andrew Knevitt. He deserves a large part of the credit (and/or blame) for this for starting the ball rolling. Andrew was bemoaning the amount of legacy he had to deal with and I immediately started talking about code and automated testing. This wasn't what Andrew was referring to though. He was working mostly with business process and was referring to the problem of legacy business process. We all know the problems of legacy code - hard to maintain, fragile, lots of manual testing required. Legacy business processes have similar problems - clumsy, fragile, constantly out of date, lots of manual work required, and so on.

We both agreed that legacy process was a problem but neither of us could come up with a good explanation of what made a business process legacy. It's more than age - some old processes work really well but some brand new ones are out of date as soon as the ink is dry. So what makes a business process legacy? During the course of the discussion, I trotted out one of the more common definitions of legacy code - legacy code is any code written without automated tests. That was when the lightbulb went on for both of us. Legacy business process is any business process without a built-in feedback loop. But not just any feedback loop. A 2 yearly process review cycle isn't enough. It has to be fast feedback.

I am working with a team that has a great VMB. It's the first thing people say when they walk past and see a stand-up in progress - "what a fantastic VMB" they say. And it is indeed fantastic. It represents the team's work really well. It's clear and easy to understand. It shows obstacles and what the team is doing to overcome them. It really assists the team in their stand-ups. It facilitates discussions between the team and its stakeholders.

The next question people invariably ask is -"can we set up our board like that?" Of course they can. The VMB design isn't proprietary to the team. Anyone can use it. So they do. Copies of this fantastic board are springing up everywhere, but pretty soon they come back and say "there's something wrong. Our stand-ups don't flow as well as yours and the board just doesn't work. Have we copied something wrong?" Yes they have. They have copied the wrong thing entirely. The thing they haven't realized is that my team's fantastic board, and the fantastic stand-ups and discussions it facilitates, has nothing at all to do with the layout of the board, and everything to do with the performance of the team.

Over the last few weeks we have been looking at the various organisational alignment patterns - top down, bottom up, etc. In each of those, the way to move forward once you have hit the limits of that particular pattern was always to extend alignment vertically and horizontally to other parts of the organisation. I made mention of a wondrous state that could be achieved where the whole organisation shares the same goals and is working together towards a common goal. Welcome to the Fully Aligned pattern.

This is the end goal for any enterprise agile adoption. This is the pattern that will really let you grow agile within the organisation and firmly embed it into the culture. This isn't just a desirable end state though. In my experience this is a necessary end state if agile is to thrive and become part of the organisational culture. Without full alignment, agile tends to wither away to a sort of agile-ish (or fragile) set of practices that are followed without really understanding why and more importantly without really delivering real business benefit. If agile is to deliver real benefits at the enterprise level, you need to achieve alignment.

Last time we looked at one horizontal alignment direction - IT lead; today we'll look at the other - Business lead. This is much less common than IT lead. Agile has its origins in software development and the IT side of an organisation is usually much more aware of agile and agility as a concept than the business side so it is natural that the drive for agile would come from there. Business lead does happen though. The problem is that when it's business driving agility, it's either because the business is really advanced and is actively seeking out ways to transform itself (great but not likely) or they have issues with their IT department and have heard of this thing called Agile which apparently makes IT departments deliver stuff.

Yes, if the push is from business, it's usually because there are delivery issues and someone in business has seen agile and sees it as a way to make the IT guys deliver faster, or better, or cheaper, or some combination of all three. Even when business is asking for agile, it is still (most of the time) seen very much as an IT thing. The brief is usually "go make our IT teams agile". Of course the IT teams just love business folks telling them how to write software don't they? If your business is in the "really advanced and looking for ways to transform itself" category then it's likely your IT department is as well and your life just got a whole lot easier. But that's a different pattern.

So far we have looked at the vertical component of organisational alignment - which level of the business is pushing for change. Today we will look at the other dimension. Most businesses are split vertically into different layers of management and also horizontally into different operational units. Every enterprise does this a bit differently but in most of them the main split is usually between "business" and "IT".

Business groups connect directly with customers and come up with new products and features. IT groups tend to sit in the background and do... geek stuff. Now, those who have been doing agile for a while will know that one of the things agile does is to break down this artificial split and align IT teams directly with the business. For an organisation right at the start of its agile journey though, you are more likely to see this structure than not. When planning the transformation, one of the keys is finding where

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.