Goodbye Martin

It was with great sadness that I heard Martin passed away last night. My thoughts are with Lucy and his family.


Martin and I were part of the LASCOT set. A group of Agile types that were drawn to each other once a year in Edinburgh. We did not agree on everything but we did have fun together. At every conference Martin and I would steal a quarter hour to exchange notes and plot the Agilification of some company or other. Our plans were fanciful, hare brained and never came to fruition. The thing I loved most about Martin were his earnestness and his subtle sense of humour. Either are great but Martin combined them with a subtlety that I think quite a few missed.

In May 2015, Martin and Lucy organised the inaugural SAFE Leadership Retreat in Crieff. An event that would become an annual “must attend” for the SAFE community. Martin invited me as the ‘invited trouble maker’. Also present at the retreat was the spirit of another trouble maker. Lucy, Chris (McDermott) and I would snigger in the corner that the SAFE people were unaware of the significance of different colour shirts, especially those “responsible for imposing cult discipline” who were wearing black.

I will not miss Martin because of his endless enthuiasm for SAFE. I will not miss Martin for his subtle humour. I will miss him because he was my friend.

Goodbye Martin, you will be missed.

Photo: Martin at the SAFE leadership retreat. Note the lack of shoes.

Whence road kill?

One of the largest companies in the world has a saying “Its nothing personal, you are just road kill.” The message. Your career and reputation is destroyed. You are sacked. But, it was nothing personal.. In other words, your identity within the company is killed but not because of anything you have done. Organisations where your identity can be destroyed like this are not safe.


So why are some places unsafe and others safe?

One of the reasons is alignment, or rather, a lack of alignment. Road kill often happens where two or more powerful forces in the organisation are not aligned. Nothing induces a chill in your guts more than a senior executive asking “Why are you doing that?”. The answer is normally “Because that other executive asked me to”. Its not an answer that protects you from that roadkill feeling.

Many of the Agile processes can be used to reduce the chance of roadkill, and reduce that roadkill feeling. Here are two:

  1. Capacity planning is a technique that brings together the most senior business investors to agree the backlog of initiatives based upon the capacity of the delivery teams.
  2. Reduce lead time as a strategy provides a means for delivery teams to justify the removal of technical debt.

Capacity planning allows delivery teams to focus on one item at a time rather than start multiple deliveries to keep powerful investors happy. Alternate approaches that ring fence a partial set of resources and “manage” dependencies do not create alignment and result in road kill situations.

Reduce lead time aligns technology and business goals on reducing the risk of investing in technology. Alternate approaches like a separate technology backlog lead to a focus on delivering business value at the expense of paying down technical debt.

Agents of the Agile Industrial Complex claim to focus on improving organisations effectiveness, often by increasing the road kill index. I have experienced weaponise versions of agile practices, and received personal threats from the agents of the AIC.

Agile Practioners help organisations become more effective at delivering value, they also make organisations better places to work.

I would like to thank Simon Powers for sharing the goal “Making organisations better places to work for our children”. The great thing about this goal is that it is fully aligned with the goal of “Improving the delivery of value”.

I would also like to thank Marc Burgauer and Gitte Klitgaard for having the patience whilst I came to this realisation.

Shared vision as enabling constraint.

Transformations are hard. Transformations are even harder when only the executives know where the destination is meant to be, if they even know that.

A shared vision

One of the most important responsibilities for executives in an organisation under transformation is to ensure that there is a shared vision to guide the organisation. A shared vision means that everyone in the organisation buys into the vision. Everyone understands where the organisation is going so that they can make the most appropriate decisions in their context. For some people, this may mean learning new skills as their current skills are unnecessary in the new organisation. An example of this may be manual testers who need to develop test automation skills. The impact of the shared vision can be illustrated as follows:


Once they understand the value to themselves, everyone in the organisation can align themselves to achieve the vision. The shared vision creates alignment. Alignment to the vision allows management to free up control and let the people in the organisation have autonomy about how they achieve the vision. This alignment causes resonance within the organisation which creates a higher order system, an organisation that works together to achieve a single purpose. A shared vision is an enabling constraint.

It is important for the executive leadership to ensure that there is a shared vision. It does not mean that they are solely responsible for creating and refining the vision. Ideally, the executive leadership team should facilitate the co-creation of the vision with the entire organisation. The vision should be a living, evolving thing. The executive team might paint a broad brush vision but individual teams will need to provide detail to the vision and feedback when context requires the vision to evolve.

Shared visions create options for the people in the organisation as to how they achieve the vision.

The shared vision anti-patterns

A common anti-pattern for organisations undergoing a transformation is to not have a shared vision. Either there is no vision, or there is a vision but the executive leadership have not made sure that everyone in the organisation shares the vision.

A lack of vision means that people in the organisation do not know where they are headed. As a result, management will need to intervene and make every decision for the organisation. This leads to a lack of autonomy with the team dependent on management for decision making and providing “context”. Normally this leads to an ever increasingly more complicated rules. The rules end up constraining the organisation so that it is unable to achieve anything. These governing constraints remove all of the organisations options and it becomes inward focused rather than focusing on its customers and competitors.

The impact of a lack of shared vision can be illustrated as follows:


Sometimes an executive leadership team have a vision but they do not share it because they are concern about how the people in the organisation will react. People are smart, they will work out what the “leadership” intend and will work to oppose it. In such a situation, it is impossible for people in the organisation to act with autonomy. This lack of autonomy will result in all management energy being directed inward rather than focusing on leading the organisation to a new place.

Absent or unshared visions lead to rules and commitments on the people in the organisation that reduce their options to achieve their goals.

A shared vision?

The technology department of an organisation might adopt a vision of  “Be more responsive to customer and their needs.” which it makes actionable by saying “Reduce lead time for investments.”.

People in the organisation can then choose the appropriate action in their context to achieve that measurable goal. They can do small things that enable them to do bigger things. The act of making small changes alters the dispositionality of the system. Making small changes gives a team confidence, skills and experience to make bigger changes. The team can make any change that aims to reduce lead time. They can measure the impact of the change, and adjust accordingly.

To reduce lead time, they might do one or more of the following:

  • Increase test automation
  • Implement continuous integration/deployment or devOps
  • Make smaller investments
  • Adopt Scrum or Kanban
  • Reduce work in progress
  • Get teams to work more closely together
  • Apply theory of Constraints
  • Adopt Given-When-Then
  • Reduce technical debt
  • Adopt extreme programming
  • Hire experienced developers or coaches
  • Co-locate teams
  • Re-organise the organisation based on the Spotify model.
  • Cancel the SAFE or LESS implementation initiative.
  • Increase training and Learning
  • Many, many more things.

The team can adopt one of the above practices according to their context and dispositionality with the goal of “Reducing lead time”.

Alternatively, in the absence of a shared vision, the “leadership” might impose a number to initiatives on the team to do one or more of the following.

  • Increase test automation
  • Implement continuous integration/deployment or devOps
  • Make smaller investments
  • Adopt Scrum or Kanban
  • Reduce work in progress
  • Get teams to work more closely together
  • Apply theory of Constraints
  • Adopt Given-When-Then
  • Reduce technical debt
  • Adopt extreme programming
  • Hire experienced developers or coaches
  • Co-locate teams
  • Re-organise the organisation based on the Spotify model.
  • Cancel the SAFE or LESS implementation initiative.
  • Increase training and Learning
  • Many, many more things.

The team will pick those items that are easiest to achieve in order to get management off their back so that they can focus on their immediate business goals. Teams may have no investment in the outcome and adopt a “tick box” attitude to simply getting the “transformation” done.

What is a transformation?

You often hear about organisation transformations. But what is an organisational transformation? The transformation is when the people in the organisation value and commit to the shared vision of the organisation. The transformation occurs one person at a time until some tipping point is reached and the remaining people either buy in to the vision or leave the organisation.

So the organisational transformation is the point at which the enabling constraint comes into being. The point at which everyone values and commits to the shared vision. Leaders will discover that the can focus on the future of the organisation as the teams achieve autonomy. Without a shared vision, transformation is not possible.

Perhaps a good way to measure transformation is to consider how far into the future leadership are focused. If leadership are still focused on the day to day operations, the transformation still has a way to go.

Screen Shot 2019-03-10 at 06.31.37


In summary, autonomy will occur when all the people in an organisation are aligned around a shared vision. A shared vision is one that all the people in an organisation value and buy into. A vision that is not shared is the same as having no vision, or possibly worse as the people in the organisation might be in conflict with the leadership. The impact of a lack of a shared vision is confusion over the direction of the transformation and an inward focus of leadership.

A shared vision is an enabling constraint as it constrains the actions of people in the organisation so that they are aligned.

So start the path to transformation, co-create and build a shared vision.

The tragedy of Given-When-Then.

When all you have is a hammer, everything in the world starts to look like a nail.


Twenty five years of doing analysis and helping others do analysis has shown me that there are at least three different types of things to specify about a system:

  1. What the system looks like.
  2. The calculations in a system, and the data needed.
  3. The behaviour of the system based on its internal state, and the system interactions within and without the system.

The traditional tools

Before the internet, user experience was considered of little value because most users of systems were internal employees of companies. These employees had no choice whether to use the systems if they wanted to perform their roles. Any consideration of usability tended to focus on ergonomics and prevention of damaging mistakes due to confusing interfaces.

This meant that low fidelity prototypes dominated the way people described what systems look like. Some people used visio or powerpoint to create these prototypes. My preference was Excel due to the speed of creating the prototype, and familiarity of my colleagues with Excel:

Screen Shot 2019-04-06 at 07.56.44

Describing data and calculations was done using a business domain model. An abstract description of the data and the calculations was specified using a tool like Rational Rose.

The interaction of the system with outside actors (humans and other systems) was described using use cases. There was no standard format but everyone was influenced by Alistair Cockburn’s “Writing Effective Use Cases”:

Screen Shot 2019-04-06 at 08.10.47

The traditional world of analysis was where these abstract descriptions of the system’s data, calculation and behaviour were used to drive the development of a system.

Real Customers and Specification by Example

The internet exposed real customers to organisation’s systems. Real customers had choice about which service they used. As a result, user experience (research and design) have become a vital part of product development and system design. Low fidelity prototypes have been replaced with high fidelity prototypes that are tested with real customers before software development starts. High fidelity prototypes are now part of the specification of a system, sometimes with pixel level precision.

Internet time meant fast, with short lead times. Short lead times demand automated testing, and lead to test driven development. Automated testing meant “specification by example” was needed to feed into test driven development.

Instead of abstract domain models in Rational Rose, data and calculation are specified using examples in spreadsheets with associated formal definition of calculations. In 2003, Sanela Hozic and I used a spreadsheet using examples to show the calculation of credit risk on oil transactions. This was implemented by Andy Pols and Joe Walnes in a prototype. In 2007, we used a spreadsheet containing examples to specify the calculation of cash flows for complex credit derivatives. These examples were co-created with the tester and verified and added to by the trading assistant who normally calculated the cash flows. These examples were implemented using JUnit. In 2010, Nat Pryce and team created a spredsheet based eco-system where traders entered the examples. Once again Given-When-Then was not used.

Abstract use cases and state transition diagrams have been replaced by examples in the Given-When-Then format. One of the drawbacks of Use Cases was that the approach discouraged business analysts from exploring alternative paths, which lead to a “Happy Path” mentality. The focus of the Given-When-Then format allowed the business analyst to create a “Happy Path” scenario and then hold a “Three Amigoes” session to explore “Quality Paths” (Given the volatility market data is missing) and “Technical Paths” (Given the server is unavailable). These alternatives are typically written as acceptance criteria in user stories.

The tragedy of Given-When-Then: Act I

If Shakespeare had written a play about Given-When-Then, he would possibly have started it with the line “The world appears to be made of nails when all you have is a hammer.”

Although Given-When-Then is a fantastic way to describe interactions, state and behaviour, it is a lousy way to describe data and calculations. A common anti-pattern is that Given-When-Then is used to describe data and calculations:

  • Given <a set of market data and trades in a table>
  • When <arbitrary event such as calculation is performed>
  • Then <results based on inputs are calculated as described in a table>

The Given-When-Then detracts from understanding and readability but provides the much prized automation through tools like Cucumber and sister products like SpecFlow.

The tragedy of Given-When-Then: Act II

A common anti-pattern with Given-When-Then has the Three Amigoes collaborating on scenarios that are stored as acceptance criteria in user stories. The tester then translates these Given-When-Then scenarios into Cucumber format feature files. This occurs in parallel to development rather than ahead of it. The reduction of the tester to an expert translator/typist is a tragedy. It means that the business analyst does not necessarily see the actual Given-When-Then statements and a disconnect occurs between the them and the testers and developers. Cucumber comes to be seen as a test automation tool rather than a repository of the system specification.

The tragedy of Given-When-Then: Act III

The disconnect between the business analyst and the testers/developers is reflected in the Given-When-Then community. Business Analysts often do not see the feature files and do not fully understand the process. They see no value in cucumber, seeing it as a test automation tool.

The result is a void.

To fill this void developers create processes that appeal to developers because they tell the business analyst how the developers think the business analysts should do their jobs. Event Storming and Example Mapping are popular for training courses and conferences. They are fun, active facilitation processes. They are easy to learn and obvious, creating complex outcomes. They also fail to meet the needs of business analysts who by their very nature operate in the complicated space of documenting and defining complicated systems. Business Analysis requires the application of structured learning techniques that require study and practice to master.

The tragedy is that Given-When-Then has created a bigger void.

Agile was created by studying those who “do it and help others do it”, except in the case of business analysis where developers make stuff up for business analysts to do… Where the observers, not the doers, define the process.

The tragedy of Given-When-Then: Finale

Ideally we will realise that Given-When-Then is a tool for describing the interactions, state and behaviour of systems. We will realise that describing data and calculations using the Given-When-Then format leads to tragedy, and will create and popularise tools and approaches using Excel to document examples.

The Given-When-Then community will reach out to the business analysis community and listen, listen to their issues, listen to their needs. They will discard their pre-conceived solutions and collaborate to create tools that bridge the communication gap between business analysts and development teams.

When we have more than a hammer, we will see that the world is made up of more than just nails.

Acknowledgement: This post was inspired by an e:mail discussion about cucumber. The discussion helped me realise that Given-When-Then is as much of a hindrance in some contexts as it is a help in other contexts.

Managing Serendipity.

Yesterday I was chatting to Marc Burgauer when one of us said “Leaders need to be facilitators, not decision makers.” Marc tweeted this and a small conversation ensued. Although a small thing, it is an example of many of the innovations that I have been involved in. Two or more people come together, have a conversation and as the result of the conversation, a new idea pops up. Whilst the romantic image of the lone inventor locked in their laboratory (USA) or garden shed (England) might make for good stories, my experience is that the water cooler is a much more fertile environment for innovation.


Many executives leave serendipitous conversations to chance, hoping that they will happen naturally. Other executives manage for serendipity, creating environments that increase the chances of it happening (or altering the dispositionality of the fitness landscape for those of a Cynefin persuasion).

At Agile2008 in Toronto I spent the first two or three days catching up with people to find out what they were up to and what they were interested in. On the last day I introduced people to each based on the things I’d discovered in the first few days. It was a selfish experiment to see if I could spark some innovation and I had the hope that someone would contact me with some cool new idea that one of the conversations had produced. Like many poor scientists, my follow up was, well, poor and so I do not know what came of the experiment. I still like to introduce people, it saves me the hassle of learning from both parties and then distilling their separate ideas into something new.

When Skype moved its London office from our tired old building to a new one of glass and polished stone, Mark Gillett has chance encounters in mind. The Skype office in London was spread over three floors linked with a flourish by an elegant spiral staircase at its heart. It was not possible for two people to pass without engaging with each other. Furthermore, coffee and tea were in two different kitchen spaces on the opposite sides of the social spaces, forcing people to cross the central line. All of this was deliberately designed by Mark to increase collisions,  ad-hoc conversations and ‘nudge’ more and better (quality) interaction and team cohesion. As for Mark, his status in the organisation dictated he have a corner office on the top floor but he chose an office on the middle floor, close to its heart (staircase). This afforded him the opportunity to engage in ad-hoc conversations and de-mystyfy the ‘layers’ as the organisation scaled.

Friday over lunch, Mark Thias introduced me to Proxfinity, one the startups he works with. Proxfinity offers a badge to be worn at conferences that informs you when people with similar interests are nearby. Imagine walking through your office at work and the badge beeps to tell you that a fellow BDD enthusiast is nearby. A tool to build communities of practice and help automate serendipity in your organisation.

I have worked in offices where you can get from your desk to the outside without bumping into another person. Offices where social spaces are off the beaten track and hard to find. Pretty offices where the workers are forced to bend their way of working to the building. Offices where interaction only occurs deliberately.

As an executive,it is your responsibility to understand how the work gets done so that the space it occurs in helps rather than hinders. As an executive, it is your responsibility to create an environment where innovation can flourish. As an executive, it is your responsibility to create chance encounters.

“Go to the Gemba” and the Power Distance Index

The two cultural dimensions that differentiate innovate and traditional cultures are “uncertainty avoidance”and the “power distance index”. Innovative organisations have a low power distance index, whereas traditional organisations have a high power distance index. “Go to the Gemba” is a technique that executives can use to reduce the power distance index.


Something happens to an organisation when it grows beyond about one hundred and fifty people, the top Dunbar number. There is no one in the organisation that knows everyone in the organisation. This means that organisations split into tribes and speaking to someone for the first time who is not in your tribe can be perceived as risky. It is common for people to sit within feet of each other for extended periods of time without speaking until some social catalyst (event or person) introduces them. The social and emotional barrier to introducing yourself to an executive is even greater. Think how easy it would be to knock on the door of your CEO and introduce yourself, or stop your CEO in the corridor and say hello. The brave among us might nod at the CEO in the lift, hoping that they nod back to acknowledge our existence.

Executives on the other hand perceive no barrier introducing themselves. When they don’t, it tells us a great deal about our culture and the power distance index.

“Go to the Gemba” is an attitude, it is not a single practice. When an executive looks at a metric and senses the invitation to visit a “team”, they are going to that area with the explicit message “I am deliberating destroying the power distance index in your area, if you need me I am one of you. There is no barrier to anyone speaking to me as we make things better.”

This is where I ask for your help. As we coach executives, it is good to have stories to share. Stories of behaviours where executives have reduced, or increased, the power distance index. Please share your stories as comments. Here are some of mine.

“Going to the Gemba” – Practices that reduce the power distance index

Dresdner Kleinwort Benson had the hardest recruitment processes I ever encountered. The last stage was an interview with Al-Noor Ramji, the CIO of a department containing one and a half thousand people. It was a  constraint in the process that caused significant delays in the recruitment process, it was a constraint that Al-Noor refused to relax. Al-Noor tried to talk me out of the job. One of my candidates called me after the interview to say they did not want the job because they did not like Al-Noor. I asked the name of their current CIO, they did not know it. Just like their current CIO, I explained that they would not be working with Al-Noor on a daily basis. However if they had a problem, they could speak to Al-Noor any time they needed to.

JP Rangaswami replaced Al-Noor as CIO. Every afternoon at 5pm he would leave his office and go to the pub opposite our office where he held a surgery. Anyone could go and discuss an issue they had, or just hang out with him. Many people did which meant that most people in the organisation were close to someone who could take them to see JP whenever they wanted or needed.

I met Mark Gillett in the kitchen area outside of his office when he went to get his own coffee. We chatted whilst we waited for the kettle to boil. Jamie O’Shaunessey, a good friend and mentor in the ways of Skype, told me that if Mark’s door was open, Jamie would pop his head round the door to see Mark was available for a chat. Word gets around.

David Turner held a town hall where he acted as the compere to introduce a number of people who had done interesting work. He facilitated the discussion rather than tell everyone about his plans and what “he” had done. He made it easier for people to find the experts that they needed to speak to. He also elevated the other speakers to his level.

Jim Bannister had an office. He turned it into a meeting room that could be booked through his assistant. He would sit out with the team, joining in jokes and discussions. Jim would use his office for a private conversations or like any other meeting room.

“Hiding in my cave” – Practices that increase the power distance index

Power Breakfasts allow a carefully selected group of junior employees with “potential” to meet with an executive. They get to hear important things from the executive’s mouth and have the opportunity to ask questions. Power Breakfasts re-inforce the importance of the executive, and reinforce the idea that only special people can speak to them, and only in carefully orchestrated circumstances. Meeting the executive is a “prize” for good performance and behaviour.

Traditional Town Halls are an opportunity for executives to reaffirm their “rock star” status and share their vision for the organisation. Its a chance for executives to talk to the masses, however its not a comfortable place for the masses to speak to the executive.

Cerberus was the three headed dog that quarded the gates of Hades. Many executives use their personal assistants to guard access to themselves, making it impossible for anyone to access them in an unstructured way without warning. This makes it hard for someone to raise a difficult matter as their manager might find out about the meeting and challenge them about it.

A closed door says “do not disturb”. Executives who keep their doors closed when they do not need to are sending a strong message, you do not have anything important for them to hear that cannot be filtered through the hierarchy. Executives should manage by walking around. get out of their office and just move around the organisation.

The Royal Visit is announced in advance allowing people the chance to prepare a carefully orchestrated presentation. This reinforces the importance of executives and increases the power distance index. There is a joke that the queen thinks the world smells of paint because everywhere she goes, one hundred yards in front of her someone is painting a wall. It means they are never confronted with the real issues people face. Instead, executives should turn up unannounced, sit at an empty desk without fanfare and just stay there for a few days conducting their business and seeing what goes on around them. After a few days people let their guard down and act as they normally do rather than be “on special behaviour”.

I was once insulted by an executive in a meeting. I refused to agree with them because they had an opinion and I had experience that their opinion was wrong. They never apologised, we never spoke again.

Your turn

What are the practices you have seen? Please share a story or two in the comments.

“Go to the Gemba” for practitioners

At the first ever Kanban conference (UK Lean Conference 2009), Kenji Hiranabe showed a documentary in Japanese. He translated for us real time. To this day, it is one of the most inspiring and important sessions I’ve seen at a conference. The documentary(1) followed one of Taiichi Ohno’s pupils, now a master in his own right, as he introduced the Toyota Production System into a factory making widgets (phones?). Taiichi Ohno’s pupil explained to the senior management team that a key piece of expensive equipment needed to go. He then told them that they personally needed to move the equipment, otherwise he would leave as they were not ready. The senior management team went to the factory floor, removed their jackets and deconstructed the machine in front of the watching work force.


More important than the work itself was the message that this symbolic act sent to the work force. “We are now working in a different way. The management team are fully committed to the new way of working.”

This is what I refer to as “Go to the Gemba”. Leadership showing the organisation the way forward. Supporting the workers, creating a strong message about change, and removing obstacles whether they are physical or cultural.

Don Reintertsen has written(2) this excellent piece on “Going to the Gemba” that points out that the actual practice is not appropriate for knowledge work. I agree with Don. The way that I use the term is different to the way Don describes it. Although the Agile Community does not have a precise definition for “Going to the Gemba”, I have never heard anyone mention chalk. Don’s article hints at the fact that leaders should be technically competent in order to command the respect of “ruthless and impolite” engineers. The idea that managers should somehow better understand the engineering than the engineers. We live in a post “Turn the ship around” world. We no longer expect our leaders to have a better understanding of the work than the worker. The Leader-Follower ( Parent-Child in Eric Berne’s Transaction Analysis ) model where the manager retains responsibility for the work has been replaced by the Leader-Leader ( Berne’s Adult-Adult ) where the worker is responsible for their work and the leader has their own responsibilities. The leader is responsible for the system, and that is why their presence at the Gemba is needed to signal change. Not only do they need to be present, they need to be seen actively changing the system.

Last year a few of us met to hear Jabe Bloom talk about levels of responsibility. Scaling Agile is less about making Agile work with larger and larger groups of people. Scaling Agile is about making Agile work further into the future. Its about understanding the time frame of responsibility which is correlated by not directly related to the number of people who report to you. To illustrate this, consider the time frame of responsibility for the following:

  • A scrum team/pod/squad typically focuses on the current sprint. i.e. up to two weeks into the future.
  • A product owner focuses on the next sprint or two.
  • A project manager may be focused on the deliveries in the current quarter.
  • The portfolio owners may be looking at the outcomes in the next quarter.
  • The engineering leads may be looking at the capabilities required for the year.
  • The CTO may be looking at the capabilities required from the end of the current year to five years out.
  • The CEO may be focused on the strategic direction of the company from six month out to the company’s horizon.

Obviously the size of organisation impacts the time scales. For a startup, the horizon might be three months. For a multi-national energy company, the horizon might be fifty years as they try to anticipate technology (oil/solar/battery), influence politics and laws (pipelines/drilling), secure scarce resources (mineral rights) and invent new technologies (batteries/solar tiles).

The time frame is correlated to the number of people impacted. The CEO makes decisions that impacts everyone in the organisation, and as a result everyone reports to the CEO. The CTO however has a time frame that impacts many people but the people impacted report to managers who are aligned with business divisions.

In order to manage a further out time frame, the shorter dated time frames need to work effectively and provide the appropriate transparency.

At one of my client’s we provided transparency on about twenty teams to the delivery lead. All of the teams had unstable delivery over time with red representing story points and blue representing the number of stories delivered.

Screen Shot 2019-02-17 at 08.38.10

Rather than blame the teams for their lack of stability, the leader spoke to the teams about it. The leader asked me, the coach, to work with the teams to see what could be done to improve the stability. This was a systemic issue rather than idiosyncratic to an individual team or subset of teams. This meant the teams were unlikely to be able to solve the problem on their own.

The teams all complained of “drive by” analysis. The business analysts worked on projects that needed teams from several systems to deliver. They would write the stories that the multiple teams need in order to deliver their project. As a result, the business analysts would work with different teams for each project. Furthermore, the teams would work with several business analysts. Each business analyst had their own style. This meant that the stories the teams were working on were inconsistent in terms of size, format and content. Scrum works because the development team and product owner (business analyst) refine the story format to optimise the communication. The solution was for each business analyst to have two responsibilities. They retained the  existing responsibility to deliver projects. The new responsibility was to work with a single team to ensure that the stories the team worked on were a consistent size, format and content for that team. This enabled each teams to work with a product owner (business analyst) to improve their individual process, something that had not been possible when they worked with many business analysts. This change required all the business analysts to change the way they worked and take on new responsibilities. It was facilitated by the BA Chapter Lead and the Delivery lead. It was not a change that the teams could have made on their own.

The delivery leads and project managers need the teams to deliver a stable number of stories from sprint to sprint so that they could ensure they had enough capacity to deliver all of the organisation’s commitments in the future. i.e. They needed to be able to produce an agile gantt chart.

Leaders need to have transparency into aspects of the teams behaviour so that they can go to the Gemba. They “go to the Gemba”, not to be the expert but rather to help the team understand the importance of the transparency they need (give the team context) but also to facilitate improvement if the team is not able to do it for themselves.

(1) This is my memory of the session. Sadly it was not recorded for Infoq.

(2) Thank you to Daniel Dorian for pointing it out to me.

Transparency is dancing, not fighting.

Dancing is where two or more people collaborate to create something of beauty. Each member of the dance signals intent to each other so that the others have time to react. Fighting is where two or more people try to hurt each other by hiding intent so that the other person does not have time to react. Tai Chi and Cypora can both be considered a dance or a martial art, the difference is whether the participants signal intent to each other.


Transparency is a dance where two or more individual communicate with each other in a way that the others understand. It is a collaborative dance. When one party communicates to their dance partner, the dance partner should understand what is being communicated to them. This means that context and understanding are an important part of transparency. I am a huge fan of Jabe Bloom’s perspective on transparency, transparency is an invitation to the leader to “Go to the Gemba” or “Got to where the work is done”.

In the transparency dance, the reflex reaction for a leaders should be:

  1. Celebrate / reward the transparency.
  2. Go to the Gemba.
  3. Help the team by spreading their goodness, or if they need it, support them with resources to improve the situation.
  4. Give the team time to respond.
  5. Retrospect on what they could do better.

Transparency is not about making information available to your dancing partner. Transparency is about presenting information to your dancing partner with context so that they can easily and quickly make the best decision about their next move. To illustrate this, lets look at “progress” and how it is communicated to dancing partners.

From my experience, it is common for traditional consultancies to communicate progress as they provide a factually accurate but utterly useless “progress” update. For example:

The “Purple Widget” is 50% complete.

This is not transparency because important aspects of context are missing. First, lets add time.

Screen Shot 2019-02-16 at 08.47.12

All of these teams have completed exactly 50% of the purple widget. Which would you rather have. In fact, the team that appeared to be doing the best initially (red) is actually performing the worst now (probably because they did not waste time on those automated tests, CI/CD, and the devOps pipeline that the green team put in place. As a leader, the first thing you should ask for is the temporal view, something that most agile practices provide.

Next lets consider how much work needs to be done over time.

Screen Shot 2019-02-16 at 16.16.04

Clearly the purple widget where the work required is known currently appears to be better than where the work required is evolving.

So transparency is about giving our dance partner the information they require and the context so they can understand it. This allows our dance partner to make the next move.

Everything? Everyone?

Transparency is not about giving all information to a dance partner.

Transparency is not about making information visible to everyone.

Transparency is about giving our dance partner the information they need to make the decision about what they need to do next.

To illustrate this, a development team may have one team member who coaches the rest of the team so that they improve. That team member might not commit any code as the other team members do the code commits. This is how the team choose to work and how the team works is its business and not the business of its dance partner. The team should not share who does its code commits with its dance partner and neither should the dance partner care.

Transparency is a dance. Create something beautiful in your organisation.

Transparency is ‘Better’, not ‘Best’

“Best” is one of the barriers to achieving transparency. The desire to be ‘best’ means that people feel, or are made to feel, a failure until they achieve a certain level. ‘Best is big up-front designed improvement and as such is anti-agile. ‘Better’ by comparison allows people to feel good about themselves and their improvement journey.


Transparency is a key sign-post in the learning journey of individuals and organisations. For an organisation, achieving transparency is the equivalent of reaching “conscious incompetence”. It is the point where the organisation realises that it has a situation that it wants to improve. How leadership react is critical to the success of any improvement initiative.

Leadership should celebrate transparency, regardless of what the transparency reveals. Those who provide transparency should be celebrated and/or rewarded lest they retreat behind the curtain.

Transparency is ‘better’ than not having transparency. It allows organisations to better manage risk. It allows organisations to see the situations it needs to improve.

The worst thing that leaders can possibly do is punish the people who created the situation that the transparency revealed. Punishing people for revealing situations that need to be improved discourages other people from being transparent, and teaches those who were transparent that it was a mistake.

Let’s consider the risk averse leader who punishes people for revealing situations that need improving. Normally the situation is caused by factors outside of the control of those responsible for the situation. Those factors may be forces like business partners who place too pressure on the team, or the teams lack of knowledge about something. In both these cases, the failure sits on the shoulders of the leader who should already know these things. In other words, if anyone should be punished for the situation revealed by transparency, it is the leader for failing to know about the situation because of their risk aversion. Their risk aversion meant that they did not encourage transparency.

So what happens when a leader punishes people for a situation that needs to be improved. Their leader should punish them, right? Wrong! Their leader should help them celebrate the transparency and the discovery of situations that need improvement. And so it goes, recursively up the organisations structure, all the way to the top. And if the CEO acts in a risk averse manner, then sack them or sell your shares. If your CEO does not value transparency, then the organisation is standing at the cliff edge, unsure whether to step forward or back.



Where do you store your Given-When-Then statements?

Given When Then was created as a template to improve communication between developers (using TDD) and subject matter experts (Business People, Product Owners, Business Analysts and Testers etc.). It supported the example driven development approach (Break the Model) that Sanela Hodzic and I refined at BP in 2003.


As an agile coach, I have come to appreciate the word “better”, and have disdain for the word “best”. “Best” results in teams who stop their journey of continuous improvement when they achieve “Best” practice. “Better” helps teams continually reach further and further. “Better” allows teams to celebrate improvement, even if they have not reach “best” practice. “Best” is a stick to beat those who are on a learning journey, who have yet to arrive.

A common pattern with Given-When-Then statements is that business analysts/product owners write them as acceptance criteria for stories, often in Jira. A test developer then uses these to create feature files for cucumber, specflow etc. This is “better” than the business analyst writing abstract requirements, or writing their requirements in prose.

There are potential drawbacks with this approach:

  1. The test developer may interpret the Given-When-Then statements in order to get them to work with cucumber/specFlow. The automated tests may be subtly different to that intended by the business analyst as there is often nothing in the process to ensure that they are reviewed.
  2. The business analyst/product owner versions of the Given-When-Then is not managed under source control.
  3. Subsequent changes to the Given-When-Then by the BA/PO are independent of the feature files used by the development team. The changes may be disconnected from the behaviour specified in the feature files.
  4. The test developer may prepare the feature files and cucumber integration in parallel to the development of the functionality. This brings the tests and functionality together in a big batch of testing at the end of the two parallel processes.

I am fortunate to be working with an extremely smart and competent business analyst called Ilona whose flexible and collaborative attitude has resulted in a new process.

  • For each epic, the Cotswold Way is followed. First the value to the customer is understood. The outputs are designed that will deliver the value. Eventually the behaviour is described.
  • Ilona writes the features files and manages them in a version control system (Git). The feature files are created on a branch for the epic.
  • Then Ilona holds a three amigoes session with the development team to establish the stories needed to automate the tests and implement the code. The stories link to the feature files.
  • If subsequent changes are needed to the feature file, Ilona edits it on a branch. When the automated tests are run on the branch, they fail (red) until a developer fixes them (green) at which point the branch can be merged back into master.

Is this a “better” process? Is it already documented somewhere else (I think it might)?

The approach would appear to address a number of the issues with the process I originally described. The major drawback is finding business analysts/product owners who are prepared to learn to use git and write Given-When-Then in a style constrained by the way cucumber works.

What “better” ways do you know? Please provide links or descriptions in the comments.