The culture of an organisation is vital to its ability to change and acquire new capabilities so that it can adapt to new contexts. Whilst academics and thought leaders will tell you that culture cannot be changed and is different for each organisation, careful observation will reveal that there a couple of key cultural archetypes when it comes to change in organisations. Like blind men scrambling over an elephant, there are many ways to describe these polarities. Currently I name them a “risk managed culture” and a “failure culture”. Associated with each culture is a set of behaviours. In a “risk managed” culture, we have a set of behaviours that lead to change, a set of behaviours we call leadership. In a “failure culture”, we have a set of behaviours that prevent change and perpetuate the status quo, a set of behaviours we shall call failureship.

“All that change needs to fail is that good leaders do nothing”

Failureship is the set of behaviours that prevent change and perpetuate the status quo. It is a mixture of conscious AND unconscious behaviours that undermine and block change. Failureship behaviours are not the fault of an individual “managers” but a complex interaction with the culture itself. They are a behaviour-plex where one behaviour leads to another which leads to another which feeds back and stabilises the original behaviour. Sometimes they are held in place by an enabling constraint rather than a governing constraint.

An understanding of behaviours in a “risk managed” and “failure culture” and the associated “leadership” and “failureship” behaviour sets can help us better predict the success and failure of a change within an organisation. As most people consider leadership synonymous with leaders, I will refer to “leadership” as “changeship”, the act of leading change rather than leadership which most consider to be the rulers of an organisation.

It is worth noting that failureship often leads to huge success for the individuals but ultimately leads to long term damage of the organisation they work for. The “failure culture” rewards individuals engaged in failureship and although it does not punish those engaged in leadership, they are likely to be undervalued and will seek organisations where they are valued. The result of failureship is the squeezing out of leadership and the eventual dominance of a failure culture and the establishment of a ruler group who are experts in failureship… the failureship. As the goal of the failureship is value extraction, the failureship will ensure that the organisation will appear to be in rude health even though it is unable to change to meet changing contexts. The Failureship will trade long term health for short term gains.

An understanding of failureship will help the following groups of individuals:

1. Leaders of organisations that are genuinely interested in change. An understanding of failureship enable them to identify colleagues that are consciously or sub-consciously preventing change. It will also help them to understand the behaviour-plexs that need to be disrupted in order for change to occur. Most importantly it will help them to understand how their own behaviour contributes to change and prevents it.
2. Change agents can use it to identify whether the leadership in their organisation is commited to change or is consciously or unconsciously opposed to it. They can identify whether their efforts to help an organisation improve will result in success, or frustration and failure.

It is worth noting that any organisation consists of many sub organisations. It is possible for different sub organisations to have a different culture, especially if the leadership of the sub-organisation is strong enough to resist the culture of the wider organisation.

About a year after implementing Capacity Planning ( aka Delivery Mapping ) at Skype, the product leadership team asked for reporting to support the process. Tony Grout, Lisa Long and myself implemented the “Strawberry-jam-o-meter” and the “Wrong-order-o-meter” with the product leadership team ( report names inspired by Dr Seuss books which were a favourite of one of the product executives ). The product organisation consisted of about two hundred product owners working with about three hundred scrum teams. Capacity Planning meant that for a year the product organisation had come together once a quarter to prioritise an organisation wide product backlog based on the available capacity of teams.

Skype consisted of several front end products (Windows, Windows Tablet, XBox, iOS, Android and Windows Phone) that implemented back-end products (Audio/Video Codecs, Transport, Login). The architecture was constructed using Reverse Conway principles with the aim of allowing each scrum team in a release vehicle (a set of scrum teams) to be able to deliver independently.

The organisation wide backlog (known as the meta backlog) was a set of business goals whose success was measured using metrics. For example, reduce the day one churn (number of users that only use the product once and never return), conform to regulatory rules to prevent significant fine or enable asynchronous chat by moving it chat from peer to peer to server based.

Anyone who has worked in a large organisation knows that it is pretty much impossible to set up your organisation such that every business goal can be delivered by a single scrum team. Several teams are often required to achieve a business goal. Large organisations need to create a single ordered backlog to provide focus and create alignment between the teams.

Once the leadership team had established the process to create an ordered backlog, they were able to get better insight into what was actually happening in the delivery. To that end, they reduced work in progress by over 50%. They also created two reports:

The Strawberry-Jam-O-Meter was used to identify teams that had the most backlog items in progress. Inspired by Jerry Weinberg’s “Law of Strawberry Jam”.

The Wrong-Order-O-Meter was used to identify teams that were working on items in the wrong order according to the organisation wide backlog that the product owner organisation had specified.

The reports were to help the leadership understand which teams needed their help and support. The reports provided bad smells that helped them identify issues to resolve. To quote Jabe Bloom, the reports Were an “invitation for the leadership to go to the gemba”. There was an understanding in the product leadership team that the “behaviours” were often a result of constraints in the system. For example, the team is blocked waiting for another team and moved onto the next item. In some cases the product owner was not aware of the impact of too much work in progress which was a “learning opportunity”. In one case, the product owner on the 16th priority was very aggressive at getting their own delivery done such that they put the 1st item at risk.

The two reports provided leadership with a system wide view so that they could identify constraints. The leadership were more interesting in solving system wide issues rather than issues with an individual team.

Layout and Calculations

The Wrong-Order-O-Meter was very simple. It showed the team name and the effective position in the backlog that they were working. It was possible to drill down on each team to show the items they were working on.

Drilling down into Slytherin’s backlog:

Fifty percent of the effort in the organisation will be for “Items not on the Organisation Backlog” because the teams will not be able to work on the backlog item as there will not be enough capacity in the teams acting as the constraint in the system. For this reason, the leadership needed the strawberry-jam-o-meter as well to identify teams that are spread too thin both for items on the backlog and for items not on the backlog.

Corona virus has raised the importance of Skills Liquidity or “key person dependency”. As well as managing the normal skill liquidity risk, organisations now need to consider the “summer holiday” effect. During the summer holidays the productivity of many teams plummets for an extended period because of skills liquidity. The absence of one or more team members means that the team experiences a significant reduction in throughput and a massive increase in lead time. To address this, organisations need to move quickly address risks that are normally annoying but are now significant.

To address skills liquidity it may be necessary to redeploy people from non-core applications to core applications. So the first step is for organisations to classify applications as core and non-core (possibly with more refined classifications).

Then create a skills matrix for each application ( I like the way Cat Swetel describes it here ). We end up with a skills matrix like this one:

Then we create a scenario where team members are unavailable for any number of reasons such as:

• Being ill for a few weeks
• Looking after sick friends or relatives
• Unable to login due to lost internet capability
• Called up by the government to assist in army or medical capability

We assess the scenario impact on the ability of the team to fix problems or make critical emergency changes:

Where we do not have enough skills liquidity (options), we need to create them. Bring new people onto the team, possibly former team members if they are not supporting other core applications. Creating new features is probably higher risk and can reduce the stability of the application. The new team members can refactor the application, create automated tests and pay down technical debt. They can automate the build chain and generally make the application more resilient.

Core versus Non-Core

A follow up on core / non-core and the risk profile of each skill / component to follow.

A month ago a colleague of mine asked me about stakeholders in Agile. After a moment of thought I told them that there are NO STAKEHOLDERS in Agile.

What is a stakeholder?

In traditional development, someone puts together a business case, some business value that will be delivered, often with a high level description of the solution. A sponsor then secures funding for the business case and it is handed over to a project manager to deliver it. Funding is corporate gold, quite literally, and it attracts attention from anyone who has an idea that might have a claim to it. Some of those claims are more legitimate than others. Those people who have a claim on the budget are referred to as “stakeholders”.

The project manager takes direction from the stakeholder (often indirectly). The waterfall practice of “Stakeholder management” or “management of stakeholder expectations” involves minimising the impact of the stakeholder claims on the Sponsor’s deliverables. Where the stakeholder has a legitimate claim, it should be minimised. Where the claim is not legitimate, it should be ignored… politely in a way that does not offend the stakeholder.

In finance, examples of legimate stakeholders might be:

• Someone from finance who needs a feed to general ledger (so that the CEO does not go to prison for a Sarbanes Oxley violation).
• Someone from the regulatory department who needs a feed to the regulatory reporting system (so that the CEO does not go to prison for a MIFID violation)

Examples of stakeholders that are not legitimate might be:

• Someone from marketing who requests a feed to the customer targeting system.

The project manager will ensure that the finance and regulatory requirements are met with the least possible effort.

Stakeholders in Agile

There are no stakeholders in Agile.

Stakeholders are a phenomena that only occurs in larger organisations. Stakeholders do not occur in small organisations.

In Agile, Stakeholders are either customer segments with a need, or more normally, they are product owners who represent customer segments with a need.

In Scaled Agile, there are no stakeholders because the customer and their needs are represented by the product owner. In the simple case, the product owner order the customer segment’s needs relative to the needs of the other customer segments and the associated value to the business. In complex situations, a group of product owners comes together to create a shared organisational backlog. To facilitate that process, the organisation can use “Capacity Planning”. In really big organisations, the “Capacity Planning” session would involve Product Executives who own parts of the business organisation.

Stakeholder management and big up-front business cases are an hangover from waterfall development. The organisation decides up-front what “Value” is going to delivered, and scope is managed (reduced and increase avoided if possible) to ensure the value is delivered. In Scaled Agile for Practitioners, executives decide which capabilities (teams etc.) they want to invest in, and then the product organisation optimises the business value delivered given the constraints inherent in the organisation. “Capacity Planning” provides feedback to the executives to indicate where investment in capacity needs to be increased and reduced.

If we consider the stakeholders above, it is possible that the product owners may consider that the need identified by marketing delivers the most business value to the organisation if it is satisfied.

In Agile, there are no stakeholders, only customer segments with needs, and the product owners who identify and prioritise those needs.

Gitte recently recommended this fantastic must-read article on Cameratas by Jessica Kerr. My only criticism is this statement:

One camerata emerged inside ThoughtWorks (consultancy) in London around 2003–2006. This group gave us Continuous Integration, Continuous Delivery, DevOps. They weren’t all on the same project, but they talked to each other, and they solved the problem of: Does deployment have to be so hard?

Jez and Dan and Chris Read produced The Deployment Production Line. Later, Dan went to invent BDD, Sam Newman became a prophet of microservices, and more. I keep meeting conference speakers who were part of this group.

The Camerata in London was not centred on ThoughtWorks, it was centered on The Extreme Tuesday Club. In fact, ThoughtWorks was one of several companies that played host to a chunk of the Extreme Tuesday Club, others being Connextra, BNP Paribas, Google, UBS, Sky, Springer and Zuhlke.

The Old Bank of England was the second or third regular meeting place for XTC. It was the first place where I attended.

Why Extreme Tuesday Club?

The Extreme Tuesday Club was one of many Local Agile Communities that existed in the early naughties. Other notable communities were The Salt Lake City Round Table (Todd Little, Alistair Cockburn, Jeff Patton), The Silicon Valley Patterns Group (Rus Rufer, Tracey Bailik, Joshua Kerievsky, Mike Hill), The Portland Patterns group (Ward Cunningham, Diana Larsen) and many others. Members of these local communities were networked thanks to the OOPSLA conference.

In 2003, the Salt Lake City Round Table organised the first Agile Development Conference which went on to merge with XP/Agile Universe and become the Agile20xx conference. In 2004, the second Agile Development Conference was organised by members of the Extreme Tuesday Club, namely Rachel Davies, Andy Pols, John Daniels and Steve Freeman, of whom only Steve ever worked for ThoughtWorks.

I was the only employee of ThoughWorks London to attend in 2003. Partly as a result of the write up of my experience, in 2004, about seventeen employees of ThoughtWorks London attended, and we had a ThoughtWorks stand. This launched ThoughtWorks London on the Global Agile Stage as the group made a major impact on the conference.

Like the other communities, the combined impact on Agile of members of the Extreme Tuesday Club has been quite significant. I will list a few below. Many of those members worked for ThoughtWorks for a period of time. However, it is the Extreme Tuesday Club that provided the community that generated the ideas.

The Extreme Tuesday Club had weekly feedback loops. People would suggest an idea one Tuesday, a week later they would get feedback. XTC was a hub. Visitors from outside London would head to XTC and the global network was strengthened. Famous visitors would also attract new members. XTC organised XP Day which was the only place in London to learn about XP/Agile for many years. Mainly, XTC was a friendly face and a empathetic ear for those trying to make XP/Agile work in their work lives.

Why ThoughtWorks?

ThoughtWorks was hiring people with experience of eXtreme Programming at a time that no one else was. Paul Hammant actively recruited people from the Extreme Tuesday Club into ThoughtWorks. Hence there was a very large overlap between the Extreme Tuesday Club and ThoughtWorks. I am eternally grateful to Paul for being one of the people he recruited from XTC.

ThoughtWorks was great. It was on the bench that Dan North explained BDD to me ( c/Assert/Should ) which made it much easier to coach people to adopt TDD. “Should” provided me a link between Business Analysis and Agile Development. I then introduced “GIVEN” to express mocks. Dan and I then collaborated to come up with the “WHEN” and replace “SHOULD” with “THEN” to complete the trio. This was only possible because of ThoughtWorks positive attitude to supporting innovation in the Agile Space. ThoughtWorks left us to work on things we considered valuable rather than find busy work for us.

I left ThoughtWorks shortly afterwards in 2004, continuing to develop Real Options, Feature Injection (which includes GWT), Kanban, Capacity Planning, Skill Liquidity, Tech Debt in collaboration with members of XTC and the wider network of communities. When people left TW, many remained together as a community as part of XTC. Sometimes, XTC members would help people find jobs when they left TW unexpectedly.

Why ThoughtWorks rather than Extreme Tuesday Club

XTC is only something that you will hear of if you are connected to an existing member or visitor.

Why do so many people think that the London Software Camerata centres around ThoughtWorks rather than Extreme Tuesday Club? The answer is simple… Martin Fowler, Dan North and Jez Humble are more famous than the Extreme Tuesday Club.

Within ThoughtWorks, like all consultancies, they promote their own and play down the role of others. Within ThoughtWorks, you are more likely to hear about the contributions of ThoughtWorkers that the shoulders of giants that they stand upon. Martin Fowler has 250K+ followers on twitter. He is brilliant. His job is to promote ThoughtWorks and he does it well.

So people see Dan and Jez and other famous ThoughtWorkers rather than the XTC.

The London Software Camerata

XTC is an important part of Agile History. It would be great if we tried to document that history, especially showing the collaborations between members.

Years ago I tried to list the contributions of XTC members to Agile. I gave up after about listing fifty people. I just want to give you a taste (Please add a comment with people I have left out):

• Rachel Davies
• Tim MacKinnon*
• Ivan Moore*
• Andy Pols
• John Nolan
• Nat Pryce*
• Ade Oshineye*
• Joe Walnes*
• Liz Keogh*
• Gabrielle Benefield
• Robert Benefield
• Benjamin Mitchell
• Portia Tung
• Keith Braithwaite
• Mike Hill*
• Richard Watts*
• Paul Simmons
• Tom Ayerst
• Antony Marcano
• Andy Palmer*
• Giovanni Gasproni*
• Douglas Squirrel
• Marc Johnson*
• Gojko Adzic
• David Evans

* – Indicates they worked for ThoughtWorks at some point.

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.

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.

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.

Summary

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.

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:

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”:

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.

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.