• A shared competence – The feeling that the team has or has the ability to learn all the skills they need to build a good quality product without accumulating technical debt, gives the team the confidence and courage required to innovate.
• Freedom – Unconstrained by others,  a self organising, cross functional team has the ability to do whatever it takes to deliver solutions at pace, brings excitement. Where there are impediments a team needs the freedom to remove them before they cause frustration.
• Collaboration – The ability to create things as a team that you couldn’t do alone and the fellowship that this brings is exciting. The sharing of discoveries and achievements accelerates learning way beyond anything achievable alone.
• A good customer – nothing beats the instant feedback that a customer on the team brings. Sharing ideas, seeing the excitement as their expectations are surpassed is a fantastic motivator. A good customer is as committed as the developers and spend their day experimenting with whats being built, discussing options and sharing ideas with the team. The only thing better than a good customer on the team is 2 good customers on the team.
• Great technology – Working with great technology is standing on the shoulders of giants, working with elegant, fluid api’s that allow you to create with ease gives the whole team a boost.
• Surprises – Trawling through a long backlog tying to follow a plan is a very different experience to letting stories emerge from the collaboration of developers and customers. Working with only a loose plan but a strong purpose  means every day brings new and unexpected challenges.

The combination of a these factors allows a team to deliver any solution they can imagine rapidly. The consequence of this is they dare to imagine things that most teams won’t. This creativity is incredibly valuable and therefore precious. Just because its precious doesn’t mean we can’t attain this state more.

These moments are precious because, in most organisations, it’s not easy for all these factors to exist together and when it does happen it’s fragile. We must try though. None of these factors are impossible to achieve and even if you can’t achieve all, any of them will make work better. Perhaps if we can become more aware of them and track how well we are doing at achieving them we can do better . Should these factors be something we should try to measure?

1. Is it the fear of feedback that stops us showing work in progress
2. Is it the fear of admitting that we need to abandon the plan when we discover something new
3. Is it the fear of throwing away work done when people tell us it’s not what they need
4. Is it the fear of what others will say when we admit our assumptions were wrong
5. Is it the fear of embarrassment when we discover what was really needed was much simpler
6. Is it the fear of punishment when our boss discovers the work we did will not be useful to the customer (even though it created insight into what was needed)
7. Is it the fear of people questioning our competence
8. Is it the fear of what people say if we don’t look busy, when we are thinking about a different approach
9. Is it the fear of what people say if we don’t look busy when discussing ideas with others
10. Or are we just conditioned (by fear) not to think differently and to take the safest path

Finding the best solution to the problem takes courage, courage needs support – support through collaboration which needs openness. We are fearful because we are not open and openness takes courage.

Fear creates fear.

If we want to build the right thing we must start with a workplace without fear.

Building the right thing requires listening, patience, empathy and imagination

(resources that are scarce in the prevalent business mindset)

Whilst being close to your customer and having conversations helps, nothing beats getting the software out there and having people scream about what is missing. Having a process that allows you to quickly respond to those screams, and we are talking hours not weeks or months, is by far the most effective way to build the right thing.

Now this isn’t rocket science, I think it’s widely accepted in the Agile community but perhaps not so much in the business community. The business needs numbers to be convinced, so lately I’ve been thinking about what is the real cost of not using a continuous deployment process.

Building a product with and without continuous delivery requires a strikingly different mindset:

1. Build the simplest thing possible that satisfies the story, deliver it to the customer and discover what’s missing. We make as few assumptions as possible and test them as early as possible
2. Consider all possible permutations of what the customer might need to deliver the story and ensure that they are all covered, because once it’s out there it will take too long to react to problems. Talking to the customer about what they need helps, but they won’t really know till it’s built.

In my experience of working the second way I think you usually end up building at least twice as much as is used. I think many will argue the figure is much higher. But the cost of delivering twice as much is more than  twice the cost. As software becomes more complex and each area of functionality needs to work with other areas the cost of adding new features grows. You also need to spend more time maintaining the features. Good design and engineering practices can help with this but it’s unavoidable that the cost of adding each new story will grow exponentially. If the growth is exponential, and the product lasts long enough, I assume that at some point in its lifecycle the cost of adding a new feature will be 5 times as much as if you were using continuous delivery.

Now that’s the kind of figure that I think could convince organisations to reconsider the way they are working, and treat continuous delivery as essential rather than something just the cool kids do. But is my assumption correct?

The Oxford Dictionary defines an assumption as: “a thing that is accepted as true or as certain to happen, without proof”. We constantly make assumptions. Sometimes we are aware of them, often we’re not.

When we attribute blame we make an assumption about the other persons behaviour, often without really knowing the reasoning behind the action they took. We make this type of assumption as a defensive behaviour rather than through any rational thought. As we have already discussed these types of assumptions damage relationships and our ability to learn from problems. Testing these assumptions is easy, we can talk to the people we are blaming, listen, and ask them about another assumptions we make when hearing their explanation. The deeper we go into our questioning the more we can scrape away the assumptions and get to the root of the problem.

When something happens we make assumptions about its cause. We can’t resist attributing simple causes to mistakes and successes when the reality is far more complex. Even when there is little evidence we prefer to make an assumption then be left with no cause. Even if our cause may be valid there may be many other factors involved that we fail to consider. We have a strong bias towards finding simple causes to complex problems and certainty because these means we don’t have to think so hard. Unfortunately simple causes can be misleading.

We make assumptions about the best way to do something. We follow others when we see them having success with a tool or method even though our context may be very different. When someone we look up to declares something to be wonderful we stick a halo on that thing and follow religiously without really testing if it will work for us. When we discover that something does work for us we like to assume that it will work equally well for others too.

We use assumptions to simplify things when the reality is too complex for us to understand. We create models with these assumptions that allow us to predict system behaviours and these work well until we forget they are only models. Our simplified models of reality must be tested continually and improved. Reality continually changes, yet we tend to stick to the same old assumptions.

We make assumptions about other people’s needs. Rather than ask or try to understand the people we are building the software for, we make guesses about their needs. This helps us develop software faster, but are we building the right thing? This question becomes even harder when we realise that our customer is also making assumptions about what they need. To discover what is really needed we must test our assumptions by allowing customers to use the software while we are building it.

We make assumptions about what other people mean when they say something. Our language is limited as is our ability to use it effectively, this results in us guessing at what the other person means. We are reluctant to clarify exactly what was meant for fear of embarrassment if we have got it wrong. In a conversation both people are making assumptions. In a meeting a large number of people are making assumptions many of which will be wrong. Much of the conflict we see in work comes from misunderstanding rather than genuine differences of opinion.

We need assumptions, but we forget that’s what they are. The problems above aren’t because we make assumptions they are caused by our unwillingness to test them. The more pressure put on us, the more assumptions we will make and the less likely we are to test them, resulting in a higher chance that the assumption is wrong. Well that’s my assumption.

What do you think? Is this inline with the way you think about assumptions? What other assumptions do we make? Should we take more time to test our assumptions?

Yesterday as the 7th dev I tried picking up a 4th story myself. Turned out it needed some discussion, turned out it threatened the very purpose of our product. 2 days of spikes and discussions with the whole team who all cared passionately about the implications of this story and all the other stories ground to a halt. Slack could have saved us a lot of cycle time.

In situations like this, we don’t need complex ways of calculating WIP or strict policies, we just have to keep our eyes on whats happening and listen for the screams of frustration when we’re not progressing.

We just need to stay at the Gemba with our eyes and ears open.

Silos are destroying our ability to work effectively together. Silos allow people inside to hide their activities from the outside, whilst this protects us from judgment when something goes wrong it also protects us from vital feedback resulting in us spending much of our time doing the wrong thing.  Silos allow us to carry on working with dysfunctional relationships. Silos hide corruption and abuse. Silos are everywhere and we take them for granted, they are killing our organisations large and small.

Agile Development and the extended learning organisations requires openness. At first glance a Scrum team may look like a Silo, we protect the team from outside interference. But Scrum teams are different because they are (or should be) open. The reality of our work at any time is exposed on a large board that anyone can see. Our daily standup should be able to be viewed by anyone. Openness means if we are doing the wrong thing someone can tell us about it, if they care.

But have you noticed how most people don’t care? It’s because other departmental silos are protecting themselves from the reality around them, preferring to live with a more idealised view of how others should be working, and blaming when the ideal fails to materialise. A common example is Sales teams rarely pay attention to how product development is actually progressing preferring to rely on a fictitious plan. Managers often prefer to see a whitewashed report rather than gritty reality. When reality does finally unravel we respond with blame, punishment and sackings giving us good reason to reinforce our silos

So what can we do to get the openness and collaboration with the rest of the company that product development desperately needs?

Silos protect people from hostility so if we want to remove them we must stop treating each other in a hostile way. The way people treat us depends largely on the way we behave towards them. You cannot expect somebody who you judge and blame to be open with you about their needs. The sales team will not openly share with me what their customer’s need if I accuse them of selling the wrong thing. Their life is difficult and full of failures, if we want them to be open we must first empathise and once we understand the problems they face we can start to develop the trust that is required for effective collaboration.

Is there anything else we can do that will help others be more open with us? How about being welcoming? Showing appreciation? Is there anything we can stop doing that will help others be more open with us? We need to stop blaming. When we are asked an unreasonable request we need to stop putting up with it and becoming frustrated and resentful, we need to take the time to explain and together, discover better ways of working.

This is the kind of behaviour that could spread but it needs to start with us.

Rings is an experiment in expressing ideas in a more interactive way. It requires the reader to experiment with the ideas and if you are brave enough to look at the code to improve them. My initial experiment  models how, I believe,  behaviours effect our ability to learn as an organisation. Ultimately its some very imprecise ideas expressed in the precise medium of code, but if you want to help improve those ideas you can fork the code on Github (It has an Apache 2.0 licence).

You can download the html page from Github and run locally in your browser or run it directly on Github here. When it initially loads you will see various behaviours effecting the organisations learning ability. You can improve these causes by clicking on them. To make them worse shift-click on them and observe the effects.

All experiments need feedback, please let me know what you think

[Update] Now supports touch interfaces using 1 or 2 finger touches

Failing early and openness are at the foundation of agility. Our practices make problems visible as early as possible so that we can fix them whilst the cost of doing so is relatively small. We test our code to reveal its problems before it’s written. We pair program so that we are more likely to spot problems as soon as they appear. We integrate our code as soon as it is committed. We deliver our code to customers early before we waste time doing the wrong thing. Most importantly we stick our problems on a big board visible to everyone often marked with a fat red post-it that nobody can ignore. We try to work as close to reality as we can.

Traditional Management is not so accepting of failure whether it’s early or late. Culture dictates that failure is the bedfellow of blame and embarrassment, and defensive reactions to embarrassment are typically violent . Problems are best swept under the carpet if internal, or attributed to somebody else if external. Failure that cannot be attributed is just plain bad luck. It’s safest and most advantageous for a managers career progression to keep his head firmly buried in the underfloor network conduits.

But here’s the rub, it’s not enough for managers just to hide their own problems. Hierarchy dictates that, as a manager, you are also responsible for all your team’s failures. It’s fine if they keep it to themselves, but if they start sharing their problems with other departments it’s going to make you look incompetent. The safest course of action is to ensure that there are no channels of communication to other departments (except via you) by creating a Silo and sticking a fat stop sign in front of any inter-departmental collaboration. It also pays to keep teams so busy that they don’t have time to explore how others can help with their problems or how they can help others.

To an Agile team a silo is an impediment that restricts cross-functional collaboration. To a traditional manager a Silo is a necessity for survival and the tighter it is the safer he feels. If this type of culture exists in an organisation the change seems unlikely to happen without a credible top-down effort to change the mindset that creates this culture. The cause of the fear of failure is blame. Blame comes from fear of punishment. We must replace blame with empathy. What would happen if the CEO of your organisation abolished blame and started encouraging failure to be treated in a more healthy way? What would happen if you asked her to?

We can’t go on living this way

For us to see things differently, beyond what is obvious from the visualisation, we need to help stimulate moments of insight that start to change the mindset from one of stability to a more enquiring one. Using questions that challenge those existing assumptions is a powerful way to trigger that insight.

I’m firm believer in the people doing the work being in the best position to discover the changes needed. Since most waste comes from the interactions and relationships between people, we need to bring all people working as part of the value stream together to discover what each of them can provide for each other that will make the system more effective. For this collaboration to be worthwhile it must focus on becoming more effective at fulfilling the common purpose. If we are to achieve this we must provide a conducive environment and opportunity for the dialogue that generates these insights.

So as a facilitator of these conversations what questions can we ask? These are some of my ideas, I’d really love to hear yours in the comments.

What is the purpose of the system? This should already be clear but it’s always important to ensure that all share a common purpose.

What limits your ability to effectively contribute to the common purpose? What can you do to remove those limitations? What are you assuming that is stopping you remove those limitations?

What causes delays in the system? What effects do the delays have on your common purpose? How can you remove those delays? What are you assuming that is stopping you remove those delays?

What are the sources of variability in the system? What effect does the variability have on the system? Should we reduce variability, if so how?

What restricts our creativity in the system? How important is creativity to achieving our common purpose? What are you assuming that is stopping you removing these restrictions?

What happens when we limit WIP? What effect does limiting WIP have on the system? What would be the effect of reducing WIP more?

What are the needs of the people who are constraining the system? How can we help meet the needs of those people?

What are the boundaries of your system? What effect do these boundaries have on the common purpose? Is it possible to change those boundaries in a way that would make your organisation more effective? What are you assuming that is stopping you changing the boundaries of your system or collaborating more with those outside the boundaries?

What questions do you ask to help inspire change?

Note: I learnt about the “What are you assuming that” question from More Time to Think by Nancy Kline whose ideas inspired this post.

Jim has 15 years experience Jo has 2, they are pair programming and are loving it. Jo is asking Jim interesting question which are helping him revaluate the way he looks at the code. As Jim explains his thinking he sees the flaws in his logic. When Jo is driving Jim asks questions that help them both discover better ways. They are both thinking and learning from each other, the code is continually improving. They treat each other with respect and listen to each other carefully. They are treating each other as equals.