I was wrong about Culture – “Pasted Values”

I’d rather be wrong than right. For some time it appears that my thinking about culture has been wrong. It probably explains why I have had little success trying to change it. I still think that seeing culture is an important first step. However, the model about the underlying principles that drive culture is obviously wrong. (The model is presented here and here).

The model is based on the work of Edgar Schein (My mentor Marc Burgauer introduced me to his work). Edgar Schein’s model talks about espoused values and assumptions. I had interpreted this to mean that behaviour in an organisation (in a Karl Weick sense) is driven by the underlying value function of the organisation. To represent the value function, I use the financial definition as it is the most useful and general model that I’m aware of and can be used to model learning. The hypothesis was that if we can change an organisation’s values, the behaviour would change.

FeatureInjectionValueFunction

Today whilst listening to Charles Duhig’s “The Power of Habit” I realised that my hypothesis was wrong and I had been ignoring the obvious. Culture is not just an expression of an organisation’s values, it is also based on a set of organisational habits.

Imagine an excel spreadsheet where we write some function:

=if(X = Y,”do A”, “do B”).

If X = 10 and Y = 10, we would get the result “do A”. If X = 10 and Y = 11, we would get the result “do B”. Currently X = 10 and Y = 10 which means the function returns “do A”.

Now if we change the excel function to be:

=if(X = 2Y,”do A”, “do B”).

If X = 9 and Y = 9, we would now get the result “do B”.

That was my naive interpretation of culture. All I needed to do was help people see a new way of looking at the world (the phenomenology), a new value function and the behaviour would change.

What I had failed to understand was that most people do not re-evaluate their value function every time they do something. Instead, its as if they copy the Excel Cell and “Paste Value” so that the sell always contains the value “do A”. Either that, or they have turned off automatic calculations and need to press <F9> to update the value in the cell to “do B”.

In “Thinking Fast & Slow”, Daniel Kahneman talks about System One and System Two. System One is automatic whereas System Two is the one that does critical thinking and evaluation. We need system one which is fast and unthinking because system two is slow and takes more effort. In effect, when we encounter a culture, most of it operates in System One and my solution was to engage System Two.

So I’ve broken my model of understanding for culture. I was wrong. My prize is that to understand culture change, I need to know about “habit change”, addiction, CBT, and a bunch of other stuff . If you know of any good resources or other things I need to know, please leave them in a comment.

Today I realised I was wrong. Now I have better chance of a better tomorrow.


BDD Done Easy – The three types of data

There are three types of data that can appear on the output of a system. The three types of data are determined by the mechanism that is used to provide the data item.

The three types of data are:

  1. Data entered into the system from outside the system
  2. Data calculated in the system with data in the system
  3. Data created by processes in the system

machine-3039352_1920

To describe the three different data types, consider the following example report. Students are allowed to withdraw money from an account. A limit is applied to how much a student can withdraw each month. A student can choose to override the limit but any override needs to be approved by a responsible adult. This report shows those transactions that override the limit.

  • In order to identify whether appropriate limit breaches are being approved
  • As a Parent
  • I want to see transactions that breach the limit, along with the reason and the approver.

Screen Shot 2018-03-25 at 18.39.27

Data entered into the system from outside the system

Screen Shot 2018-03-25 at 18.39.51

In this example, the Student Name, Monthly Limit, Withdrawal Amount and reason to override the limit. All of these data items need to be enter either via a user interface or a system interface.

Values are either entered free format, or selected from a list of permitted values (The items in the list of permitted values are originally entered free format.

Data calculated in the system with data in the system

Screen Shot 2018-03-25 at 18.40.06

These are the values that are calculated within the system. In this example the balance and the % above limit. To indicate that these are calculated value, I prefix the name with “get”. Account.getBalance and Transaction.get%AboveLimit.

Account.getBalance(QueryDate) = Sum(Transaction.Amount) where transaction.date before QueryDate and after 1st Day of monthMonth

Transaction.Transaction.get%AboveLimit = ( Account.getBalance(Transaction.Date) – Account.Limit ) / Account.Limit )

Data created by processes in the system

Screen Shot 2018-03-25 at 18.40.23

These values are created by processes in the system. In this example, Date, Approved by and Approval Date. These values are all populated in a THEN in a GIVEN-WHEN-THEN statement. We start at the last step in the process which in this case is the approval.

  • THEN Approved by is set to the logged in user.
  • AND the Approval Date is set to the current Date & Time.
  • WHEN the withdrawal is approved
  • GIVEN the approval screen is displayed
  • AND a withdrawal above the limit is on the screen
  • AND the user is logged on
  • AND the user is an approver for the Account

Similarly (and ignoring the approval e:mail steps in between)

  • THEN the Date is set to the current Date & Time
  • AND an approval is sent to list of users who are approvers for the account.
  • WHEN the student overrides the limit
  • GIVEN the student is on the limit override screen

Understanding the three types of data means you ensure the correct approach for populating them is adopted.

This blog post was inpired by a conversation with Rekha Kusumanchi about the Cotswold Way. My thanks to Rekha.


BDD done easy – The Cotswold Way

The Cotswold Way is an Agile approach to business analysis, developed by Kent McDonald and myself.

IMG_2048

Before you start, you need to identify whether you should be doing Business Analysis, Product Management or JFDI. Cynefin is a particularly useful tool to determine which approach.

The problem with BAs and Story writing in general is that most people think of it as an art form or a brainstorming activity. In fact there is a very simple directed process that Jenny Martin elegantly summarise as OOPSI (Outcome, Output, Process, Scenario, Input), and if you do it backwards, it ISPOO…

The process that I now refer to as the Cotswold Way is a further elaboration of the approach that Kent and I created called Feature Injection.

There are seven simple steps in the Cotswold Way:

  1. Hunt the value. Start where ever people describe the problem/solution. Then work to the output and get them to sketch the reports that they need. They should be able to explain how and why they need the  output (report). This is the customer value which is not the same as the business value.
  2. Once you have the output, work backwards using the information smells process to identify the data and calculations you need to produce the report. This makes creating examples super easy. (For those who prefer videos to articles).
  3. Now build the output in a spreadsheet using the model developed in step 2.
  4. You can then work backwards to describe the behaviour of the system using the Given-When-Then format to define the process that populates the required data. (See here and then here )
  5. Depending on the size and complexity of your organisation, you need to meet with either some lead developers/QAs or Architects/Lead Devs/Lead QAs to agree the architecture for the solution. Once you have done that, you can break down the solution into Epics and assign stories to the various components etc.
  6. To break the solution into Epics, you now work backwards for each system to define the Given-When-Then. (Obviously if you are doing everything in a single component, you can ignore steps 5 & 6.)
  7. Once you have your examples and Given-When-Then at the system levels, its a simple matter to slice them up into stories. David Evan’s article, and book are great for those who want to improve the stories they write.

This process takes HOURS rather than days.

Want to get started? Its simple, ask your user or business stakeholder to sketch the output they want rather than describe what they want to you.

Blog posts providing detailed examples of the steps above to follow.


BDD done easy – The level interactions

There are three levels of scenarios in BDD. In this post I will describe the interactions between the levels to show how the scenarios can be more easily created.

firefighter-1851945_1920

In the last post, we created a scenario at the User Level…

  • GIVEN I have an account
  • AND I’ve set up automatic payments
  • AND I have selected a product
  • WHEN I place an order
  • THEN the item is delivered to my doorstep
  • AND the payment amount is debited from my credit card

…and identified the internal systems that will form the value stream.

Screen Shot 2018-01-27 at 15.08.20

We will now use this example to illustrate the relationship between GIVEN-WHEN-THEN scenarios. These are easy to identify when you work backwards. The relationships we will discuss are:

  1. The “THEN” at the user level is the same “THEN” at the system level and is the starting point for creating the scenarios at the system level.
  2. For every GIVEN, there is a THEN in another preceding scenario in that system. In fact, the GIVEN in one Scenario, IS the THEN in the preceding scenario.
  3. For every WHEN as a result of a message from another system, there is a THEN in the other system.
  4. System Level interactions with the user need to be reflected in the User Level Scenario.
  5. Each “GIVEN”, “WHEN” and  “THEN” at the user view level has to exist in a system at the system level.
  6. The start scenario has no context (i.e. No Given).

These rules give clear direction for tooling, especially when combined with the “Business Model” and examples already created prior to the GIVEN-WHEN-THEN scenarios.

I am going to write TODO next to those paths that I am not going to expand in this blog. These paths won’t add any clarity to the point being made and make a handy piece of homework for anyone who would care to follow them through.

We start with rule 1…

The “THEN” at the user level is the same “THEN” at the system level and is the starting point for creating the scenarios at the system level.

The value stream ends with the fulfillment system:

  • THEN the item is delivered to my doorstep
  • WHEN the driver hands me the package
  • GIVEN the driver has the package
  • AND the driver has my address (TODO)

For every GIVEN, there is a THEN in another preceding scenario in that system.

Working backwards, each GIVEN becomes a THEN, namely THEN the driver has the package & THEN the driver has my address

  • THEN the driver has the package
  • WHEN the warehouse worker gives the driver the package
  • GIVEN the account system has marked the items as “Paid For”
  • AND the item has been packed. (TODO)

Working backwards again, GIVEN the account system has marked the items as “Paid For” and AND the item has been packed.

  • THEN the account system has marked the items as “Paid For”
  • WHEN the account system notifies the fulfillment system that the item is “Paid For”
  • GIVEN the fulfillment system has the order (TODO)

For every WHEN as a result of a message from another system, there is a THEN in the other system.

The WHEN from the accounts system results in a THEN in the accounts system.

  • THEN the account system notifies the fulfillment system that the item is “Paid For”
  • WHEN the account system receives a confirmation from the external payment service
  • GIVEN the account system requested a confirmation from the Bank’s external payment system.

Obviously, we choose not to describe the Bank’s payment system. However we know that this step maps to the AND the payment amount is debited from my credit card in the User Level Scenario.

  • THEN the account system requested a confirmation from the Bank’s external payment system.
  • WHEN the account system receives an item purchase request from the order system
  • GIVEN the user has valid credit card details stored (TODO)

The WHEN from the order system system results in a THEN in the order system.

  • THEN the order system publishes an item purchase request
  • AND provides an acknowledgement to the mobile app
  • AND e:mails a confirmation to the user
  • WHEN the mobile app creates an order in the order system

System Level interactions with the user need to be reflected in the User Level Scenario.

The red output indicates something that iteracts with the user that is not on the user level scenario which means that the user level scenario needs updating.

  • GIVEN I have an account
  • AND I’ve set up automatic payments
  • AND I have selected a product
  • WHEN I place an order
  • THEN I receive an e:mail confirmation
  • AND the item is delivered to my doorstep
  • AND the payment amount is debited from my credit card

The WHEN from the mobile app system results in a THEN in the mobile app.

  • THEN the mobile app creates an order in the order system
  • WHEN I place an order
  • GIVEN I am logged in
  • AND I’ve set up automatic payments (TODO)
  • AND I have selected a product (TODO)

Each “GIVEN”, “WHEN” and  “THEN” at the user view level has to exist in a system at the system level.

So far every “GIVEN”, “WHEN” and “THEN” has been accounted for except for “GIVEN I have an account”. We know we are not finished.

GIVEN I am logged in results in a THEN

  • THEN I am logged in
  • WHEN I supply the correct username and password
  • GIVEN I have an account

A finally we have accounted for all of the “GIVEN”, “WHEN” and “THEN”s.

We may decide to replace GIVEN I have an account with GIVEN I am logged in in the User Level Scenarios for clarity.

The start scenario has no context (i.e. No Given).

Eventually we get to scenario that requires no context in the system.

GIVEN I have an account results in a THEN

  • THEN I have an account
  • WHEN I create an account

No context is necessary. The account could be created through an API or a Screen or….

We have now reached the Start scenarios. Time to go back and handle all the TODOs, especially the quality paths that I did not even mention.

Although I said there are three levels, I was lying. There are more. However the rules to describe the relationship between scenario in different levels and different systems/components are universal. ( I think ).

In the next post I will discuss some theoretical implications of this on tooling and managing test suites.

If I did not have the flu I would have created more images to illustrate the points. 🙂

My thanks to Mihai Tudor for co-creating this clarity of understanding.


BDD Done easy – The three levels of BDD

The easy way to do BDD is “Working Backwards“(1). Sadly “Working Backwards” is a principle that few people are aware of and even fewer practice.

hammock-2239788_1280

The other poorly understood aspect of BDD is that there are three different levels of scenarios(2). The three levels are:

  1. The user based view where we ignore which systems perform the function.
  2. The system level view where we describe the behaviour of a system as it interacts with its users, and with other systems.
  3. The user interaction level where we zoom into a specific micro-interaction between a user and the system.

The User Based View

We work backwards from customer based value to create the user based view:

  1. Identify the value. To do this, we find the value to the customer by creating a mock up of the output and asking them how they will use it.
  2. We design the output and validate it with the user.
  3. We use “Information Smells” (i.e. Work Backwards) to identify the data (examples) and calculations needed to create the output. I normally document the examples in an excel spreadsheet as there tend to be a lot of them.
  4. We then work backwards to describe the behaviour of the system using BDD.

At this stage, we should be describing the system from the users perspectives regardless of the different IT systems and organisations. This is the first level of BDD. Describing the system from the users perspective and these BDD scenarios become the User Acceptance Tests. The examples are likely to be more complicated in their description.

For example:

  • GIVEN I have an account
  • AND I’ve set up automatic payments
  • AND I have selected a product
  • WHEN I place an order
  • THEN the item is delivered to my doorstep
  • AND the payment amount is debited from my credit card

We can express this visually…

Screen Shot 2018-01-27 at 14.59.36

  • The WHEN describes the user input.
  • The GIVEN describes the necessary internal state of the system.
  • The THEN describes the outputs from the users perspective.

The System Level View

A number of systems may be involved in the scenario described above. At the system level, the BDD scenarios describe the behaviour of each system as experienced by the users and other systems.

Consider a company that has a number of systems that form its value stream:

  1. Mobile App
  2. Order System
  3. Fulfillment System
  4. Account System

We start our description of the behaviour of the systems by mapping them to the user view. Every interaction at the user level needs to be replicated at the system level. The “Givens” will be mapped to the systems when we work backwards. Each “Given” will need to replicated at the system level.

Screen Shot 2018-01-27 at 15.08.20

The creation of the GIVEN-WHEN-THEN at the system level will be described in the next post that examines the interaction between the levels.

The User Interaction Level

The User Interaction Level scenarios describe the detail of how the user interacts with the system. This is best illustrated with a couple of examples.

  • GIVEN the user has selected a product
  • AND the user is logged in
  • WHEN the user hits the “Buy” product
  • THEN the system generates a “Buy” order
  • AND it displays the “Buy Order” confirmation screen.

which describes the behaviour when logged in, compared to the behaviour when the user is not logged in:

  • GIVEN the user has selected a product
  • AND the user is not logged in
  • WHEN the user hits the “Buy” product
  • THEN the system displays the “login” screen

Unlike the User and System Level Scenarios, the User Interaction Scenarios are often stand alone rather than part of an overall system description. Organisations try unsuccessfully to assemble a coherent comprehensive test suite out of these fragments of testing.

The next blog will describe the interaction between the levels by describing how to create the Given-When-Then scenarios at the system level.

(1) Working Backwards is a key principle of BDD. Originally known as feature injection, Jenny Martin came up with the excellent OOPSI acronym, and Kamil Nicieja mentions it in his book “Writing Great Specifications”.

(2) Actually there are more than three levels (Thank you to Joe Schmetzer for pointing this out). However from the perspective of BDD, the describing the behaviour of a system and a component are fundamentally the same.


Three Levels of Metric Maturity : Decision Making

For any Executive thinking of introducing Metrics, they need to understand that there are three level of Maturity:

  • Step 1: Map Investment to Metrics.
  • Step 2: Use Metrics to demonstrate Success.
  • Step 3: Use Metrics to assist Decision Making.

The final stage of maturity is to use metrics to assist in making investment decisions.

JohnSnowSnowCholeraMap

(c) Map image copyright Wikipedia.

John Snow plotted cases of Cholera Outbreak on a map in Victorian Soho. From the map he was able to deduce that the cholera was centered on the Broad Street water pump. The map gave context to the data that allowed him to achieve an insight that changed the medical world’s understanding of Cholera.

The third level of metric maturity requires you to create a “map” by combining two or more metrics that gives insight into how moving one metric will move another. My mentor in the field of metrics is Jamie O’Shaughnessy. He measured the relationship between the conversion rate of customers and the page load time for the web site. The plot of these two variables is shown in the graph below.

Screen Shot 2017-11-04 at 18.05.11

Further more he plotted the overall average page load time across the World (Green Line) and in the average page load time in Remote-astan (Red Line). Jamie was able to reduce the page load time by installing an additional server near to Remote-astan. He knew that reducing the page load time to three seconds in Remote-astan would lead to an doubling of the conversion rate, and it did. He was able to take a complex non-deterministic metric (conversion rate) and map it to a complicated metric (page load time) that could be adjusted in a deterministic way. In addition, he knew that reducing the page load time below three seconds was unlikely to improve the conversion rate.

In summary, the third level of maturity means that you can create a map showing the relationship between complex (non-deterministic) metrics and complicated (deterministic) metrics. This map provides contexts that allows you to make better investment decisions with a higher chance of success.

 


Three Levels of Metric Maturity : Demonstrate Success

For any Executive thinking of introducing Metrics, they need to understand that there are three level of Maturity:

  • Step 1: Map Investment to Metrics.
  • Step 2: Use Metrics to demonstrate Success.
  • Step 3: Use Metrics to assist Decision Making.

Demonstrating success is the next step after the organisation achieves alignment using Metrics.

air-1869955_1920

Consider the hot air balloon captain who got lost in the fog.

  • “Where am I?” they shout.
  • “You are in a hot air balloon!” comes the reply from the ground.
  • “Are you an Executive without Metrics?” asks the Air Balloon Captain.
  • “How did you know?”
  • “Because your answer was one hundred percent accurate and utterly useless.”

If you do not have metrics, your decision as to whether your investment yielded a success is based on opinion and not facts.

To quote Jim Barksdale, former CEO of Netscape:

“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.”

In other words, if you do not have data to demonstrate the success of an investment, the CEO, an executive or steering committee decides whether it was or not. So why is that such a terrible situation?

When an organisation makes an investment, it is either a success or it is a failure. If it is a failure, the organisation learns (normally about its customers) so that its subsequent investments have a greater chance of success. If an executive decides that the investment is a success when it is a failure, then the organisation is denied the opportunity to learn and it may continue to make poor investments. Executives who declare success based their opinion rather than data are cheating the organisations that they are morally obliged to serve and protect. They are cheating the organisation out of an opportunity to learn.

This leads us to the second level of metric maturity…

Level 2: Demonstrate Success

No one would question that in general Start Ups are much more successful than traditional organisations at innovating and learning about their customers. The reason is simple, they use data extensively to determine whether their hypotheses about their customers are right or not.

The first step to demonstrating success is to establish a baseline. The baseline is the “value” of the metric before the investment.

The baseline…

  1. …should be for a metric that is either a sub-set of the business value metric, or another metric where the executive believes that they have a hypothesis that moving the metric will move the business value metric.
  2. …only has to be accurate enough to prove whether the investment was a success or not.
  3. …needs to be calculated using the same method as the result of the investment.

All three of these points will be covered in more detail in subsequent posts.

As an aside, it is easy to spot a culture where the executive’s opinion decides success because Product Owners do not care about establishing a useful baseline.

Once you have a useful baseline, the rest of the process is simple:

  1. Articulate your hypothesis.
  2. Construct an experiment to test the hypothesis.
  3. Run the experiment.
  4. Measure the metric and compare the results with the baseline.

Note: The baseline may be determined at any point prior to running the experiment.

There are three possible outcomes:

  1. The investment is a success. Our hypothesis is correct, we understand something about the customer and we have successfully created business value.
  2. The investment is a failure. Our hypothesis is incorrect. However we understand something about the customer and we have a better chance of creating business value in the future.
  3. The results are inconclusive. It was a bad experiment and we need to construct a better one to test the hypothesis. We may or may not have learned something about the customer.

Whether success is demonstrated using a metric or the opinion of an executive is a cultural matter. It is purely the responsibility of the executives as it is their decision whether to allow investments to take place that do not demonstrate success using metrics. If an executive wants to help their organisation succeed and insist on learning about the customer, they should simply fail any investment that does not use data to demonstrate success.

At Skype we had a metric to measure this… “The percentage of the investment portfolio that could be demonstrated using metrics”. More on that later.

The next blog post will look at how to “Use Metrics to assist Decision Making”.

Photo credit: https://pixabay.com/en/users/Pexels-2286921/