Category Archives: Uncategorized

Introducing the Agile Gantt Chart

Before I discovered Agile, I was a Project Manager. One of the most useful tools at my disposal was the Gantt chart. I used the Gantt chart to provide focus around the dependencies that needed to be removed. Many Project Managers coming to Agile discover that there is no Gantt chart and struggle without this powerful tool. This need for the Gantt chart provides a powerful opportunity to engage with experienced project managers. An Agile Gantt Chart provides Project Managers with the tool they need whilst at the same time aligning with Agile approaches.


This first post explains how to create an Agile Gantt Chart. In a later post I will describe the why and how to use it, and some of the practicalities of implementing an Agile Gantt Chart report.

An ordered backlog

The first thing required is a backlog ordered by the business and technology ( oh, and technical debt is a business concern so only one backlog. no technical backlogs allowed). This provides the relative priority of each (meta-) backlog item (MBI).

For example

1. MBI-103 – In order to retain “ABC” customers, we have to satisfy the need to do “DEF” by the “GHI” users. We need to test the hypothesis that “solution JKL” or “solution MNO” will satisfy the need to do ‘DEF”.

2. MBI-127 – In order to retain the revenue from business “XYZ”, we need satisfy the need to demonstrate effective control of the market by the regulator. We have to build “Blah”.

3. MBI-006 – In order to increase engagement with “JKL” customers, the have to satisfy the need to do “Stuff” by the “golden” users. A first scaled version of the “Nimrod” prototype solution is required.

SWAG estimates for epics.

It is likely that each MBI will need more than one team to deliver it*. An epic should be created for each team** to store the team’s estimate of the work involved. The estimate is a SWAG or Sweet Wild Assed Guess which means no one can be held accountable for delivering against it. It is simply an indication of the level of effort involved. The units for the SWAG is number of stories. The product owner, a developer and QA should estimate the number of stories they expect the epic to broken down into. They should spend five to ten minutes discussion to come up with the epic based on previous work done by the team. Using story count instead of team week as the unit of measure means that the estimate does not need to be revisited if the team capability changes dramatically such as doubling or halving in size.

For example, our super teams called the Avengers, X-Men and Defenders have provided SWAG estimates for the MBIs as follows:

Agile Gantt Swag Estimates

The trick with SWAG estimates is to be consistently bad at making estimates rather than try to improve them. The worst thing you can do is put more effort into improving them. We now spend ten times more effort coming up with our sweet wild assed guesses is as crazy as it sounds.

Date estimates for teams

Now that we have the SWAGs, we can estimate how long it will take for each team to do their bit. For that we simply work out how many stories the team deliver on average per week, and calculate the elapsed time for each epic by dividing the SWAG by average stories per week.

For simplicity, we assume all teams deliver five stories per week. The reality is that the number delivered will vary greatly per team but that is OK because each team will adjust its SWAG estimate according to the size of story they work with. An epic with a SWAG of 10 stories will take two weeks.

To calculate the expected due date for the MBI for each team, we simply order the epics according to the order of the backlog. We can see that Avengers complete MBI-103, MBI-127 and MBI-006 at the end of weeks two, five and six respectively, and so on.

Agile Gantt Team Backlogs

Agile Gantt Charts


We now filter so that we can look at each MBI on its own. We now have an Agile Gantt Chart for each MBI.


Agile Gantt MBI103


Agile Gantt MBI127


Agile Gantt MBI006

This is a presentation of Agile data that a traditional project manager can relate to and feel comfortable with.

So looking at the Gantt Charts above, you get a point for every issue you can see with the ‘plans’ above or a point for every improvement you can suggest to the plan. You get a bonus point if you give your suggestion a snappy name, and you can double your bonus if the name contains the word “Mapping”. Please leave your entries as comments below.

* In large organisations it is almost impossible for a single team of seven +/- two people to cover the technology and business domain knowledge required to deliver something of value. Where possible, organisation will often create those teams but more likely it is not possible without getting a developer named Kal, Kara or Kent.

** In Jira, an epic is needed for each team due to the fact that it is not possible to store a SWAG estimate for each team against a single epic. This irksomeness will be discussed in a later post.

Agile Coach – Agile Canary

In Victorian mines, the miners would have a Canary in a cage. If any lethal but odourless gases were present, the Canary would die and fall off its perch. On a transformation, your Agile Coach acts as the Canary.


When your organisation embarks on an Agile Transformation, you effectively create a new organisation with a new set of values within the existing one. Workers at the coal face have value in both organisations, however an Agile Coach only has value in the new organisation with it’s new set of values and associated skills and experience.

The surest sign of a healthy transformation is an Agile Coach who is a valued member of the team. Those embracing the new values will constantly reach out the Agile Coach for advice or more often a bit of encouragement before they try something new. The coach will help them understand how they can try the new thing in a safe to fail way, often pushing people to take on a little extra risk and stretch themselves. The value of the coach is their experience working in the new way that allows them to empathise with people trying new things. A coach with lots of qualifications but little or no experience is useful to no one other than the consultancies that sell them. In fact, good coaches tend to have very few formal Agile qualifications. A good Agile Coach will have an extensive knowledge of many agile practices and a solid network of other coaches that they can call upon when faced with something unfamiliar. This is a reason that home grow Agile Coaches need to be sent to conferences where they can build a network. The question should be “Who did you meet?” rather than “What did you learn?”.

I know a number of coaches that have been involved in “Transformation” projects where the environment has been toxic to Agile Coaches. The coaches are not valued as their experience and knowledge is not valued. Some transformations are outright hostile to Agile Coaches.

  • One coach was “uninvited” to meetings where they could add value, meaning they were invited but when they arrived, their entry to the meeting room was barred.
  • One coach was told to their face “We do not need any Agile Coaches here” when they turned up for a meeting.
  • One coach was replaced by a tame Agile Coach from the software consultancy, someone with lots of qualifications on their LinkedIn profile…
  • One coach was threatened with physical violence by a software vendor because they dared to call into question the capability of the vendor’s people, the ones with all the qualifications.

In all cases like this, the coach felt unvalued, preferring to be in an organsation that might value them rather than one that definitely did not.

As an executive responsible for an Agile Transformation, you should “Go to the Gemba” to see where the work is done. It might be a complete car crash but if the Canary is happily working with the team, then there is probably movement in the right direction. If everything is “perfect” but the Canary is disengaged, chances are you have problems with no movement or movement in the wrong direction.

The ultimate test of the effectiveness of a transformations effectiveness will be the metrics… business metrics, lead time and quality, however if you want an early indication about whether things are heading in the right direction, “Go to the gemba” and check on the Canary.


Executives and Purpose

Normal employees of an organisation have a responsibility to fulfill the purpose of the organisation. Executives have the same responsibility, however in addition, they have the responsibility to ensure that the organisation has a purpose, make that purpose clear, and ensure that the organisation is aligned around that purpose.

Screen Shot 2018-08-05 at 12.56.15

Some executives take an autocratic approach to determining the purpose of the organisation meaning that they decide. Some executives take a facilitation based approach, seeking to use the combined wisdom of the organisation. Regardless of the approach, the responsibility for ensuring that an organisation has the right purpose lies with the executives.

Herzberg’s classic HBR article identified that there are hygiene factors which need to be met otherwise an individual will leave the organisation, and factors that motivate them. Dan Pink’s “Drive” states that individuals in an organisation need Autonomy, Mastery and Purpose to be motivated. Successful organisations compete for high performing, highly motivated individuals as they understand that they give them the edge in the massively competitive marketplace. For high performing motivated individuals, autonomy, mastery and purpose are not motivators, they are hygiene factors. If high performing motivated individuals do not have autonomy, mastery and purpose, they will leave and go to somewhere that they do. Autonomy and mastery are local phenomena within an organisation. It is possible for a leader to create a bubble in which their team have autonomy and can achieve mastery. Purpose however requires the support and commitment of executives.

The worst possible situation for an organisation is where they are meeting the hygiene factors of their employees but their employees are not motivated. No one will leave but they are not motivated to learn or improve their skills. An organisation like this may appear to be healthy but has no long term future.

Purpose and Identity

Part of the Identity of a individual is their position in a network. We have an identity in our family, with our friends, in our community, and in our work. As an individual, we have an identity in many different networks and one of the most important things about our identity is its “value” to the network, or self worth. Self worth is how much we perceive our value in total. We will gravitate towards networks in which we are most valued, or where we can gain knowledge and/or experience that will increase our value in other networks.

The purpose of the organisation determines the value of our activity. If the purpose of our organisation is to create cheap cars that are cheap to run, then it will not value our efforts to build the fastest car possible… unless that effort results in learning and insight about how to make cheap cars that are cheap to run. A person with expertise on creating fast cars is likely to leave a job in a company that makes cheap cars and move to one where their knowledge and experience is valued.

So purpose is another way of describing the values of the company. As Dave Snowden says “101 Anthropology states that as soon as you write your values down, you lose them”. This means that the executives as the guardians of the organisations rules are also the guardians of the stated and unstated (written and unwritten) purpose of the organisation. This means that that they need to give energy and approval to activities that are aligned with the (stated and unstated) purpose of the organisation and remove energy from activities that are counter to the purpose of the organisation. Executives need to increase the value of individuals in the network that are doing the right thing. Executives need to be what Derek Siver’s calls a first followers. They need to understand the constraints that mean individuals that are not aligned with the purpose of the organisation. Once understood, these constraints (often incentives) need to be modified so alignment occurs. This is particularly import for transformation efforts.

The purpose of an organisation determines its identity and the identity (including value) of everyone involved in the organisation.

Identity and Transformations

Every organisation engaged in a (delete as appropriate) [ Digital/DevOps/Agile/Lean/Spotify ] [ Transformation/Improvement/Make Better ] [ Programme/Initiatve ] needs to understand that the transformation involves changing the identity and purpose of the organisation, and the identity and value of everyone within the organisation. It is normal that the desire to change the purpose of the organisation conflicts with the desire of individuals within the organisation to maintain their value and hence identity. It is vital that executives engage in the transformation and create clear statements about purpose (value), reward individuals that are aligned with the purpose, and sideline individuals that are not aligned with the new purpose.

So who are the individuals that are most going to resist a change in identity? Those individuals that have the most the to lose. In other words, individuals that are perceived as high value in the current organisation but will either know they will have lower value in the new organisation, or even worse, are uncertain whether they will have a lower value in the new organisation.

It is important for executives involved in an organisation to help those individuals understand that if they move to the new organisation, they will be more valued than before regardless of how effective they are are in the new organisation. It is important  that the executive helps them understand that if they oppose the move to the new organisation, they will have no value to the organisation.

The worst thing that an executive can do is do nothing. They allow individuals who oppose the change to maintain a high value role in the new organisation. This sends a clear message that the new organisational purpose (values) is not actually valued.

The Role of Executives in a Transformation

The first responsibility of the Executives in a company undergoing a transformation is to create a vision for the new transformed organisation. This is another way of saying they need to ensure the purpose for the new transformed organisation is clearly articulated. An important part of that is to ensure that appropriate metrics (measures) are articulated to indicate a successful transformation.

Second, the executives need to communicate the purpose (and metrics) to the whole organisation. This allows people to opt in to the new organisation at a point that is comfortable to them. In other words when they feel their identity in the new organisation will be more valuable than their identity in the existing organisation. This is a continuous process, and the awkward badly formed communication should gradually improve over time as more and more people join in.

Third, the executives need to engage with those entering the new organisation, ensuring that they are clear on the purpose of the new organisation whether stated or unstated. The purpose of this engagement is to connect with the people in the new organisation so that they can reach out the executives when they need to without having to go through any escalation process. The most effective mechanism I’ve experienced for this engagement is Dan Mezick’s Open Space Agility.

In traditional organisations, executives see a rose tinted view of reality. Everything they see has been filtered through several layers of excel and/or powerpoint. The filtering protects them as much as the people doing the filtering. They have plausible deniability. In the transformed organisation, the executive needs to be able to see an unfiltered representation of the organisation. Rather than use that representation to make decisions, they should use it to identify those place where they should “Go to the Gemba”. The executives should “Go to the Gemba” to support those individuals who’s actions are alligned with the new purpose, and also those who’s actions are not aligned with the new purpose. In addition, they should go to the Gemba to see the reality of any project that is struggling to see how they can assist them.

This is the fourth responsibility of the executive. To “Go to the Gemba”, “To go to the place where the work is done”, to increase the value of those identities that are aligned with the new purpose, and diminish the value of those that are not.

The fifth responsibility is to “Go to the Gemba” to assist. To bypass the escalation process by directly observing the constraints and prioritising resources to resolving the constraint.

Executives are the guardians of the purpose of the organisation. Their responsibility is to actively engage and support the organisation as it moves towards its new purpose. Their responsibility is to “Go to the Gemba” so that they can see reality rather live a life of contentment behind rose tinted spreadsheets and presentations.

A practitioners guide to resilience.

The next Cynefin retreat will be focused on resilience. In preparation for the retreat Dave Snowden has just published a nice article on resilience.


After publishing “Commitment”, Olav Maassen and myself (and Jabe Bloom in the USA) delivered a number of sessions and keynotes on Real Options. Anyone who attended those sessions will know that resilience is a major theme in Real Options and Risk Management. In our presentation, Olav and I present a simplified, practitioner’s view of resilience.

if (timeToRecover > timeYouCanSurvive)


     you DIE!


Which means you need more options!

Don’t waste time, monitor the conditions!

Although our presentation focuses on IT systems, the definition applies to many systems including biological systems. Any definition of resilience needs to consider time as a core measure. The human body is resilient within a certain time scale. Humans can survive massive blood loss or loss of oxygen, but only for a very brief period of time.

Consider some other resilient biological systems. MRSA are bacteria that resist even the strongest of anti-biolitics. MRSA are resilient because some bacteria were either mutants that survived the blast or were at the edge of the assault and survived to give themselves time to exapt, adapt or evolve.

An interesting aspect of resilience is identity. If we consider the financial system during and after the 2008 credit (liquidity) crunch, the financial system survived. However, the identities within the system have changed. Many of the people in the system lost their jobs but subsequently found new jobs with a new identity. A few banks failed, most notably Lehmann Brothers, but in reality very few banks actually failed, or ceased to exist. Rather than fail, many banks lost their identity as they were absorbed into other organisations (Bank of Scotland into Lloyds, Royal Bank of Scotland into the UK Government, Merrill Lynch into Bank of America, Bear Sterns in JP Morgan and many others).

As the Cynefin retreaters gather to discuss resilience, they need to consider the important of time. Reducing the time from a threat emerging to it being detected. Reducing the time from identify a threat to making a commitment (Boyd’s OODA loop). The time from decision to action (Liquidity).

The Cynefin retreaters also need to consider the scale of failure of a system. Whether it is individuals, identities or systems.

As a final thought, the human race currently faces a number of species threatening scenarios of our own cause. Whether its the temperature of the atmosphere, micro-plastics in the oceans, estrogen in the food supply or SAFE and LESS, something could threaten the species. Like our MRSA bacteria, some humans are likely to survive. The ones that do are likely to be the most resilient, the most lucky, and the ones with the most options. The ones with the highest centrality in the network are likely to be the ones to react first, the ones that are most likely to lucky. That assumes that their high centrality means they are not the first to be exposed to the threat, like the MRSA bacteria.

Whenever we think of resilience, we oft hear the phrase… “That which does not kill us, only makes us stronger”. I think that that depends on context.

Exapting Sensemaker to Agile – An Experience Report.

I have been a fan of cognitive-edge technology and techniques for many years. Myself and a small group have been engaged in exapting sensemaker for use on Agile Projects. I did my Sensemaker training with Tony Quinlan. Tony subsequently delivered a fantastic introduction to Sensemaker at QCon which is the material I use when introducing it.

Sensemaker is a fantastic and valuable tool, though its usage in Agile transformations and projects is different to its original context. I will share my experience using the standard report format namely:

  1. What is the context?
  2. What did you try?
  3. What worked?
  4. What did not work?
  5. What have you learned?

Context for using Sensemaker

In all three cases, there was a situation with a lot of uncertainty and the leaders showed great strength by trying something new.

  1. In the first example, a leader heard about sensemaker and very bravely decided to use it to get unstructured 360 feedback from a large group of people.
  2. In the second example, the team had scored “poorly” on one question on a company wide survey and the leaders wanted to understand why.
  3. In the third example, the leader for an Agile transformation (two thousand people) wanted a survey to understand how people in the department felt about the transformation. A pilot with fifty people was run to test the process.

It was only because I had run the first two fairly small sensemaker exercises that I had the confidence to run the much larger (and personally risky) third exercise.

What we did

In all three cases, the leader sent an e:mail out setting the context for the survey and asking for the team to participate. The sensemaker survey they were asked to fill in was a slide in a powerpoint presentation. In the first example, the survey was also printed and handed out in a team town hall. In each case, the leader introduced the sensemaker survey in the townhall or extended leadership meetings.

The responses were all anonymous. In some locations a “post box” was created for the team to post their response. In some locations, team members would send their response to a trusted colleague who would forward them to the person collating the results. Many people felt comfortable enough just to send a response directly.

Unlike the sensemaker method which starts the signifier creation process with a literature search, the triad signifiers were created using terms commonly used in the environment. For the 360 degree feedback, the leader incorporate the six headings in the corporate leadership assessment. For the Agile transformation, phrases common to agile and software development were used (Technical Debt, Architecture, Deadline, Business, Leadership, Culture, Mastery, Autonomy, Purpose, Business Value).

The results were collated manually. Each dot on a completed survey was collated onto a large triad, one per powerpoint page.


The sentiment (positive, negative, neutral) was depicted using colour (red, grey, blue respectively) and strength of sentiment ( normal, very) by shape (dot, circle). Red / Blue was chosen as traditional red/amber/green are difficult to differentiate for those with colour blindness which is common in technology.

The results were summarised. The summary and original survey sheets (or scans of physical paper) were included as an appendix to the summary. The individual stories were ordered by sentiment, and a hyperlink was placed on each summary diagram to the first story of each sentiment to speed up finding the stories.

The results were played back to the leadership team and then to the participants and the wider group. Each was invited to interpret the summary triads for themselves for before discussing them, and to read the stories associated with each cluster.

What worked

Sensemaker works! It provides useful and actionable insights.

One of the key experiences is that sensemaker shows you what people are not telling stories about. The gaps are as telling as the positive or negative clusters. For the first example, the leader was a very accomplished practitioner in the technology, however their other abilities outshone their technical skills. Armed with this knowledge, they were able to “create more stories about their technical abilities”.

One of the most powerful aspects of Sensemaker were the conversations that the exercise prompted each time. It provided a focus for some very difficult conversations that were based on data points (stories) rather than opinion. It enabled the group to make sense out of situations. Many of the things that Sensemaker revealed were already known, however they were difficult to discuss as opinions without “Hippos” closing down the discussion. Getting data to support a hypothesis with a traditional likert scale survey would have been politically unacceptable however the Sensemaker reveals the data without conflict. Once revealed, the stories can be discussed.

When you do a Sensemaker exercise you realise how beautifully it fits with the Cynefin framework. Discussions easily reveal things that are obvious or have multiple hypotheses. Sometimes, the discussions reveal it is necessary to dig deeper or bring in an expert. There were also stories that simply require action without understanding. Sensemaker helped us shape the transformation and resulted in several specific changes.

The three exercises only involved a few dozen stories rather than the massive number of stories that Dave Snowden and Tony Quinlan describe. Even though they numbered a few stories, they still provided valuable insights. Sensemaker works on the small scale as well as the large scale. Within organisations, culture tends to be determined at the tribe level (dunbar number of one hundred and fifty or less) with a dominant individual or group of individuals defining the culture.

Starting small helped me learn about Sensemaker. The first sensemaker exercise was small and fairly low risk. The experience at this level gave me the confidence and case study to refer to for the riskier second exercise. My experience with the first two exercises exercises helped me better understand the issues and provided me with stories that enabled me to convince the leaders for the third exercise. Starting small was safer for the leadership team and let them experience the approach before they tried it on a wider group outside of their area of control. My main practical advice would be start small and grow.

The leadership team said they would like rerun the Sensemaker exercise on a regular basis to track the progress of sentiment in the team.

What did not work.

Although the manual exercise was incredibly useful and valuable, reviewing the results was clunky and required a lot of effort. The manual approach is certainly limited in terms of scale. Above one hundred stories, it is likely that it would start to fail, and it would be necessary to use Cognitive Edge’s sensemaker tool. Ideally I would have preferred to use Cognitive Edge’s sensemaker tool but unfortunately that requires spending money. Spending money is the one thing that managers in large organisations do not like to do. The hope is that sharing the experiences with executives will lead to them to freeing up the funding for larger exercises. This is particularly difficult in an environment where people are used to getting their software for free (open source).

Although the results were insightful and valuable, we got stories from significantly less than half the people asked to participate. I worry that we got the “CYNics”(1) who cared but there is a large silent majority who have a different set of stories and opinions. I suspect the cognitive edge software would help with this.

(1) See the Dave Snowden’s references to cynics.

What did we learn

Sensemaker is a great tool to provide insights into your organisation when you are planning or engaged in an Agile transformation.

The normal Sensemaker approach (e.g. Literature search for signifiers) isn’t necessarily needed when the language of the culture is already well understood.

Sensemaker facilitates difficult conversations and is useful even if “no one learns anything from it”.

Even though Sensemaker and Cynefin are valuable when used individually, they are even more powerful when used together.

Next Steps

The Sensemaker and Scaled Agile Practitioner Community need to do more work together to better refine and exapt Sensemaker and Cynefin usage in the Agile Community. A summit focused on the use of Sensemaker in the initiation and monitoring of Agile Transformations would be very valuable. In particular, packaging Sensemaker with Dan Mezick’s Open Space Agility.

Executives and Transparency

One of the cornerstones of scaled agile is transparency. This is particularly true for executive transparency. Unfortunately transparency is a double edged sword and executives involved in transformations normally avoid it like the plague.


Transparency allows executive running a transformation to demonstrate that they are a success.

on the flip side…

Transparency shows when transformations are failing.

If you are an executive and you intend to succeed, the first thing you will do is establish transparency. That way, when you are a success, it can be demonstrated rather than a matter of opinion. Furthermore, if you do not have transparency into the transformation, you cannot identify the things that need your focus to improve. As Jabe Bloom says in his 2017 Lean Agile Conference talk, data should provide an invitation to executives to “Go to the Gemba” (Go and see where the work is done). In other words, the data shows you where to go, and then the executive should go there so that they have total transparency into what is going on, not a view of the world filtered through management updates, excel and powerpoint.

The exemplar of this behaviour is Mark Gillett. I worked for Mark helping to build a dashboard that showed the state of the business. Our top three metrics were “Number of customers”, “Activity” and “Revenue”. Mark invested heavily into the accuracy and coverage of these metrics. What he wanted was not available “off the shelf” so he build a world class group of developers who could deliver what he needed. He could drill down from the number of customers into the customers per product, or drill down into “New Customers” and “Churn”. Overall we had about four hundred metrics. Once these core business basics were in place, Mark worked on the operational metrics to give a better understanding of how effective the business invested in the products… lead time, bugs, performance. The key thing is that these were not executive metrics, they were the metrics that everyone in the business looked at. And this is the key point, everyone in the organisation knew that Mark looked at these metrics regularly, and they behaved accordingly. They cared about the results because they knew Mark could see if they needed help.

Jira is a tool developed to help teams manage their development. It is not a tool to manage across teams or at an enterprise level. In order to create transparency for executives, you need an expert who can extract the data you need to create the views they need. One of the graduates working with us created an app to extract data from Jira into an SQL based database. Once the data was in the SQL database it took a couple of days to create an excel report that gave an executive view of lead time using weighted lead time.

Recently a couple of colleagues and I created the first version of a report that allows executives to drill down to a deliverable and then see view the value stream for the deliverable with colour coding for the different teams. It is possible to drill down from the value stream to a cumulative flow diagram for each team. This was all in a couple of weeks part time. The numbers ain’t great but they are better than nothing and they provide the executives with “invitations to the Gemba” as Jabe would call them. (I will shortly be creating an open source product to give executives transparency into lead time and the value stream.)

If executives want to be successful with a transformation, they will demand transparency.

Executive who do not believe they can deliver a transformation avoid creating transparency like the plague. The problem with transparency is that it no longer the responsibility of the team to deliver, but everyone in the organisation, especially executives. Executives who do not “Go to the Gemba” can be held accountable when there is transparency.

So how do executives avoid transparency? Easy, they do not demand it. Everyone in their risk averse organisations will happily avoid looking at the metrics, especially if the executives can prove that they do not care about the metrics.

The benefits of not having transparency include the following:

  • Employees do not need to improve.
  • Employees (especially the executives) do not need to learn new techniques or approaches and can continue using the “same old” methods.
  • Executives can manage using their opinion rather than using metrics to reveal reality.
  • Executives can ignore problems they do not feel comfortable with.
  • No one can be blamed when the transformation fails to generate any improvement.
  • Good people who wanted to achieve results will leave.

So if you want to be part of a successful transformation, look for an executive who is demanding transparency and has strong (but weakly held) opinions on how they will get it. When you go for the interview, ask the executive to tell you when they have “Gone to the Gemba” based on the transparency they have in their metrics dashboard.

If you want a long term coaching engagement with no expectation of delivery of improvement, look for one where the executives do not care about transparency, especially around lead time.

Why I’m going to create an open source lead time tool.

From my experience, if executives do not have transparency into the lead time of deliverables, they do not care about improvement. If they do not care about the improvements, then neither will most of the people that work for them. This makes it hell for Agile Coaches who are bought in to help people adopt new approaches.

Building an executive lead time dashboard requires specialist experience. Without the dashboard, it is hard to create that transparency. The one thing management controls absolutely is spending money which makes it hard to bring in products you have to pay for. Therefore to help my fellow Agile coaches, I intend to create an open source (free) product to visualise lead time and value streams.

More details to follow.

Three Steps to Scaled Agile

Scaling Agile requires the coordination and collaboration of hundreds, thousands or tens of thousands of smart independently minded individuals. To scale Agile, a small set of simple goals are needed that individuals and teams in the organisation can focus on, aware that if they achieve the goal, they are part of something much bigger. They can then use the most appropriate practice to achieve that goal.


One of the key learnings from our experience at Skype was that we had to keep the process so simple that people did not have an excuse for not following it. If people did not follow the process, it was because they did not want to follow it rather than the process was too complicated and they made a mistake.

To get your head around scaled agile, we need to consider the different “levels” or “concerns” in the organisation:


So what are those things? What are the goals are each level?


There is one goal at the executive level:

  1. Ensure that the executives have transparency into the system to ensure that the goals are being met.


There are two goals at the portfolio level:

  1. Ensure that the backlog of Epics (single team and cross team) is strictly ordered (i.e. no joint 3rd priority) based on the constraints in the organisation. One of the key constraints at the organisation level is the capacity of individual teams.
  2. Manage capacity by moving capacity to the constraints, and planning capacity for the future. This involves ensuring that there is capacity in the system to meet any commitments that have been made to external parties.

Team of Teams

The goals at the team of team level:

  1. Deliver Value.
  2. Reduce Lead time for the delivery of value.
  3. Reduce Lead time for fixing production incidents.
  4. Reduce the number of production incidents.

The team of teams level is fundamentally about delivering value.


The goal at the team level:

  1. Ensure that delivery is value focused. That means that each Epics (single team and cross team) should deliver value rather than be bucket for stories.
  2. Ensure that team level delivery is predictable and consistent. Consistent in terms of quality. Consistent in terms of size. Predictable in terms of quantity.

The three steps to Scaled Agile

Here are the three steps to scaled agile:

  1. Get teams to deliver value in a predictable, and focus team of teams on reducing lead time.
  2. Create a system of transparency so that you can see how everyone is progressing to achieve their goals.
  3. Bring business decision makers to come together to prioritise the backlog of Epics (single team and team of team).

These simple rules allow the organisation to coordinate and collaborate without having to understand the entire system. From these simple rules, the organisation can generate complex and speedy responses.

The following practices, tools and thinking tools will help you achieve the goals:


So what have I missed? Which goals do the organisation need to achieve in order to scale agile? Comments please.


#NoEstimates and SWAG Estimates

Just over a week ago, Vasco Duarte, my good friend and leader in the #NoEstimates tribe posted this tweet during a mammoth twitter conversation about #NoEstimates and SWAG Estimates:


I realised that there may be some misunderstanding the purpose of SWAGS, and in particular the relationship with the #NoEstimates movement.


Lets start with story points.

Story Points Versus Story Count

Story Points are crack cocaine for managers who want to believe in a world where they have more accuracy than they really do. Story points, if used at all, should only be used by the development team and the product owner to communicate relative effort. In order to create a story point estimate, the product owner must present a story to the development team that meets the definition of ready for the team. Typically this occurs one or two sprints before the team work on the story. Often the definition of ready includes the product owner taking the story through a “Three Amigoes” session with a developer and tester. This is after the product owner has detailed the story including acceptance criteria, often in the Given-When-Then format. In other words, a large amount of effort is normally required before a story is ready for the team to give a story point estimate.

Mature development teams only work on stories within a defined size range and drop the need for story points altogether. Given the number of stories to be developed, an estimate of the elapsed time to deliver an Epic can be just as easily be determined from the story count as it can using story points. The advantage of using the story count instead of story points is that an estimate of the duration can be made before any work has been done on the story at all.

So within the sprint, some teams choose to use story points and often more mature teams will simply rely on the story count. Outside the sprint, story count is the only sensible option for estimating the lead time for an Epic that spans more than one sprint.

Whence SWAGs

Story counts are useful for Epics when you know how many stories need to be developed. However, there are times when we do not know how many stories are needed, and often when we do not even know what Epics are involved.

This is where SWAGs or Sweet Wild Assed Guesses are useful. (At Skype, that is the name that we put on the field label in Jira).

Capacity Planning

At Skype, a number of us including Tony Grout and Lisa Long developed Capacity Planning, a mechanism to coordinate all of the development of Skype and Lync (now Skype for Business). The Product Executives and Managers would prioritise the backlog for the next quarter based on the capacity of individual teams. A large number of the initiatives that went into capacity planning did not make the cut because they relied on work by a team whose capacity was being used on higher priority initiatives. As a result, we needed a cheap and simple way to estimate the effort required from a team. We used a SWAG, an estimate of how many weeks it would take a team to develop a piece of work. The SWAG was good enough to help us understand how much work a team could do in the quarter. It was understood that SWAGs were not accurate and we frequently referenced the work of Todd Little and Troy Magennis that stated the actual versus estimate followed a log-normal (Weibel) distribution with a most likely actual being double the estimate.

The SWAG estimate was used in the Capacity Planning Process that occurred weeks and months before the stories in the epic were broken down into stories. Once the stories were available, they were used on some initiatives to track progress using just the count of stories.

Subsequently Dan North introduced me to his client, a large American bank, were I introduced them to the same process. Since then the approach has been used in further organisations, large and smaller.

The key issue that Vasco’s tweet asked if we had compared estimates with story counts… The problem is that the story count does not become available until weeks and months after the capacity planning session where we needed them. Not only that, but we did not want to put the effort into breaking down Epics into stories when we might not even build the Epics if they were blocked by other work.

As a result, I suspect that SWAGs and #NoEstimates are complimentary rather than in conflict with each other.


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.


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


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 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.