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.