Category Archives: Uncategorized

“Go to the Gemba” for practitioners

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


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

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

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

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

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

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

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

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

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

Screen Shot 2019-02-17 at 08.38.10

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

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

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

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

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

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

Transparency is dancing, not fighting.

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


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

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

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

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

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

The “Purple Widget” is 50% complete.

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

Screen Shot 2019-02-16 at 08.47.12

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

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

Screen Shot 2019-02-16 at 16.16.04

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

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

Everything? Everyone?

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

Transparency is not about making information visible to everyone.

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

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

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

Transparency is ‘Better’, not ‘Best’

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


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

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

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

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

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

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



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

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


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

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

There are potential drawbacks with this approach:

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

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

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

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

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

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

What is a portfolio in Scaled Agile?

An executive once told me that they wanted to implement SAFe because it offered a solution at the portfolio level. Anyone with experience of Scaled Agile will know that the SAFe solution is a failure state rather than a target state for most organisations. Whether they tell you or not depends on whether they are in the community of solutions or the community of needs.


Fighting over the constraint

The fundamental problem with most IT portfolios is that they are based on budget/funding. A large pot of money is assigned to be spent on IT. This pot of money is broken down into a number of investment pots that are known as portfolios.

Screen Shot 2019-02-03 at 16.30.23

This is fundamentally the wrong way to think about the portfolio. When portfolios are constructed in this way, there are normally capabilities that exist in more than one portfolio. In this case, team 1 is needed in both portfolios. Normally team 1 would exist in one portfolio, and be managed as a dependency by the other portfolio. This means that it is possible for the organisation to have a sub-optimal portfolio if “Team 1” is a constraint. There are two solutions. The first solution is to ensure that “Team 1” has adequate capacity to ensure that it is never a constraint. Given that capabilities needed across portfolios are often “shared resources” that are centralised in order to minimise costs, this is unlikely.

The second solution is to construct the portfolio based on shared capabilities. All investments (I have named them Epics here), that are linked by shared resources are managed together in the same portfolio. That way, the business investors can come together to construct a portfolio that optimises business value according to the organisations vision and strategy.

Screen Shot 2019-02-03 at 16.30.53

As time progresses, the organisation might identify additional resources that need to be managed in the portfolio as they become constraints. These constrained resources may be funding, visas, shipping capacity, physical space, or any other resource that is constrained.

In summary, construct your portfolio based on shared capability rather than funding, and regardless of organisational divisions. Managing dependencies is a recipe for failure and leads to sub-optimal portfolios.

Closing your eyes is not a risk management technique

When it comes to investing in IT, would you categorise yourself as a rather ignorant and cowardly lion, or an informed and knowledgeable meerkat that is constantly on the look out for new risks.


In finance, there are three categories of investor. These are:

  • The risk averse.
  • The risk neutral.
  • The risk takers.

The irony is that the behaviour of risk averse individuals increases their risk. An example of a risk averse investor is one that invests in a low risk pension fund. They are so afraid of finance that they give their money to someone else to invest. Normally they do not even know the name of the fund manager investing their money, or the instruments that they invest in. It is unlikely they would know the historic performance of the fund manager. In effect, they close their eyes and hope the person selling them their services knows what they are doing. They are happy with an annual update. The risk averse investor’s approach to risk is to bury their head in the sand and hope it goes away.

A risk neutral investor does not take a risk position, they simply buy and sell at the same time making a profit from the difference between the two. Examples of risk neutral investors are shops and warehouses where they buy in bulk from remote locations and sell individual items in a location convenient to the buyer. In effect, the retail buyer pays a fee for the service they provide. Quite often the seller will sell an item (e.g. a television) to a buyer and then buy it from the manufacturer.

A risk taking investor would typically invest in a hedge fund or invest on their own behalf. They would probably know the hedge fund manager personally, know their track record, and would have regular, probably daily, updates on the composition of the investment portfolio. They would study the individual investments and have a solid understanding of the types of investment being used. They would challenge the hedge fund manager if they were unhappy with the investment strategy. The risk taking investor’s approach to risk is to actively manage it and continual seek to better understand it.

The Risk Averse IT executive

The risk averse IT executive lives by the maxim “No one ever got sacked for buying IBM!”. Their goal is to avoid being the slowest antelope. They are looking for someone else to blame if they have made a bad investment. These IT executives will only buy services from a company that their boss, the CEO, has heard of. They will never buy services from a niche specialist consultancy or an individual because their boss will still hold them responsible. That responsibility is transferred to the CEO if they use a household brand such as:

  • MacKinsey
  • Accenture
  • KPMG
  • Deloitte
  • Microsoft
  • IBM

The risk averse IT investor (lets call them lion) would typically make deals on the 19th hole of the golf course when they meet a partner (lets call them Salazar) from one of the above organisations.

  • Lion: I’m worried that I will become the slowest antelope.
  • Salazar: I always have your back, remember how I sold you that NHS database and the Taurus system. How can I help?
  • Lion: I want some Agile just like my competitors.
  • Salazar: We can’t do Agile. We have no experience and the people with experience wont work for us.
  • Lion: Do you have anything to help me?
  • Salazar: We have SAFE or the Scaled Agile (Academic) Framework for the Enterprise.
  • Lion: Wonderful. Because it is called SAFE, it must be safe because you only have my best interest at heart.
  • Salazar: Yes. We take our waterfall consultants and combine them in the SAFE structure. A few days of training, and out pops a bunch of SAFE consultants.
  • Lion: Good, it sounds like that  CDO you advised me to buy where you take junk bonds and turn them into “AAA” rated securities.
  • Salazar: Exactly, you can trust me. If it doesn’t work, our firm will take responsibility for the failure… for a fee of course.

The Risk Managing Executive

The risk managing executive lives by the maxim “We want to deliver value, reduce lead time with continuous quality and transparency”. Their goal is to be better, continually improving. Lead time is a risk measure for IT investments. Transparency is one of the most effective risk management strategies where culturally everyone makes sure the best person to manage a risk is actively made aware of it. Continuous quality ensures that development teams do not engage in risky short termism at the expense of long term costs and failures. The maxim can be rewritten as “We want to deliver value, reducing risk, with long term risk management and everyone involved in risk management.” That is because the risk managing executive understand that the most effective way to deliver value is to manage risk. Rather than avoid risk, they actively look for it so that they can manage it.

Rather than trust others, they take responsibility for their own decisions. In order to do that, they study the available approaches and decide which are appropriate for their context. Lets consider some exemplars of risk managing IT executives:

  1. When I met Lee Nicholls in his office I was intimidated to see that he had bookshelves containing several hundred books on Agile, Lean and Software Development. In our discussion, it was clear that he had studied them, including obscure books like “Commitment”. He did not want me to tell him a solution, rather he wanted to know about my experiences so that he could understand how to apply it in his context. He understood that experiences were more important than opinions. Lee had a number of well known Agile experts working for him to give him access to the wisdom of the agile community.
  2. My first conversation with Mark Gillett was whilst we were waiting for the kettle to boil just outside his office at Skype. Our short conversation on user stories indicated he had done extensive research on the subject, and he had given it considerable thought. Also, it was clear Mark was regularly engaged with a number of leaders in the agile community. Mark successfully implemented Scrum across the whole of Skype, invented the metrics hierarchy, and created a culture of collaboration that allowed capacity planning to emerge to solve the portfolio problem. Capacity planning has now successfully been replicated across several organisations.
  3. My current boss was the head of a IT department of 750 people. In order to better understand devOps, he learnt how to develop using extreme programming techniques. Now as the head of devOps, he has coached one of the development teams in extreme programming. Rather than rely on the opinion of others, he has hands-on experience of why various tools and practices are important.

Neither Lee, or the two Marks relies solely on the opinion of others. When making investment decisions, they have done the necessary research, sought expert advice and gained the experience to effectively manage the risk. They would never do what someone else advises simply because they work for a big brand consultancy that their boss has heard of. They manage the risk involved in IT investments rather than avoid it.

This week I was told me that on average a SAFe transformation fails after 14 months. If you are a CEO and your CIO says they want to implement SAFe using a traditional consultancy, you need to consider whether you want a cowardly lion in your team. After all, is “burying your head in the sand” really the risk management technique you want your IT department to adopt?

SAFe is the Trojan Horse.

On a number occasions, I have heard Agile Coaches refer to SAFe as a Trojan Horse. It is, but not in the way that they think.


They mistaken think that SAFe is a legitimate way to introduce agile practices into an organisation. They think that once the agile practices are established, the organisation will realise the limitations of SAFe and discard it.

However, organisations adopt SAFe because they want agile practices. So there is no need to have a Trojan Horse because the organisations want Agile practices. In fact, the presence of SAFe is likely to put off exactly the experienced Agile practitioners that the organisation is hoping to attract. As a result, they will have to fall back to their normal consultancies and system integraters that provide them with plug compatible programming units.

So SAFe is a Trojan Horse. Its a way for traditional consultancies to pass themselves off as agile with no agile experience. A short SAFe training course introduces their existing consultants to a new over constrained command and control mechanism.

So SAFe is a Trojan Horse, but Troy in this case is not the organisations that want to adopt agile. Troy is the Community of experienced agile practitioners. And as David Snowden has said on a number of occasions, the Trojan Horse did not work out too well for the Trojans.

Scaled Agile for Practitioners – The Epic

As the invited trouble maker, my contribution to the inaugural SAFe Leadership Retreat in 2015 was to suggest a session entitled “Does the “A” in SAFE stand for Agile or Academic?”.

screen shot 2019-01-13 at 17.18.39

My challenge was that SAFe is “made up” ( “constructed” ) by Dean Leffingwell and his small team at Scaled Agile Inc. ( SAI ), whereas Agile practices have been tested in many contexts by practitioners in the Agile Community. Even though many of the individual practices in SAFe are tried and tested, practitioners understand that Agile is an eco-system with the success of one element dependent on another. In effect, even though the SAFe framework contains agile practices, the framework has not been proven to be agile.

Personally I am in awe of the product management skills of the SAI. Clayton Christiansen, one of the leaders of product management, describes disruptive innovation as satisfying the unmet needs of a group. The SAI identified the unmet need of a massive and lucrative group of customers… Consultancies whose business model were being disrupted by agile and who had no experience of agile. The SAI provides a number of short training courses to convert command and control consultants into experts in agile. Even better, they even changed the language so that the traditional consultants would sound aligned and the experienced agile practitioners would sound out of step.

This week a colleague of mine was confused by the seemingly incompatible definitions of “epic” as understood by Agile Practitioners and the definition from a big six consultant citing SAFE as the source.

Epics in Agile

To understand what an Epic is, you need to understand what a story is. A story is a small piece of work that delivers value to a customer. The popular story format (developed by Connextra) clearly identifies the importance of delivering value.

  • As a blah         <– The customer who receives the value. (Non negotiable, though the story might be split if it is discovered that more than one customer is involved.)
  • I want blah     <– The thing being delivered. (Negotiable)
  • So that blah    <– A description of the value being delivered. (Non negotiable, though the story might be split if it is discovered that more than one value is involved.)

In order to stabilise the velocity (expressed in stories or story points) of a Scrum/Kanban team, it is necessary to limit the size of any story to a fifth of a sprint. (In reality, most mature teams would have at least ten stories in the sprint.) With a team of seven and a two week sprint, that means the maximum story size is fourteen man days. Fourteen man days is not a lot, especially in an enterprise environment, and as a result we end up needing an epic.

An epic is a story that is too big and needs to be broken down.

There are no hard and fast rules but an epic might contain up to ten stories. Above twenty stories is definitely too big and should be split into one or more epics.

In the world of the agile practitioner, there are no business epics or enabler epics, there are simply epics, stories that are too big.

Epics in SAFE

This is the definition of epic taken from the SAFe web-site.

screen shot 2019-01-13 at 17.36.24

No wonder the SAFE definitions appeal to consultancies with strong heritage in traditional command and control.

Epics in Scaled Agile

As a practitioner working in the Scaled Agile space, I have experienced that enterprises have additional needs that a single team working in isolation do not. Some of these needs are:

  1. It is not always possible for a single team to deliver an item of value for a customer. Several teams may be involved in delivering something of value, an epic.
  2. Organisations need to limit work in progress for each team using a technique like capacity planning. This means (SWAG) estimates need to be held against each team within an epic.
  3. The organisation often needs to predict when items will be delivered so that they can manage capacity. This is where the Agile Gantt Chart can help, either using averages or Troy Magennis’s monte carlo estimation. Once again, SWAG estimates are needed for each team.

For those organisations using Jira, it is difficult to store a (SWAG) estimate per team at the epic level. Therefore, to satisfy these needs, we require a three level hierarchy for a story.

  1. A story
  2. An epic (single team)
  3. An epic (cross team)

To minimise the impact on the majority of the organisation, ( the development teams ), we call these:

  1. A story
  2. An epic
  3. Anything really. I like “Cross team epic” * however I have seen “Deliverable” and “Initiative” used effectively.

The organisation may need to create higher level hierarchy to group “Cross team epics” and report on them for organisational or regulatory reasons. These higher “funding” levels can take any form according to the whims of the organisation.

As an aside, When delivering value it is important when calculating the lead time that you know whether the value was delivered by a “Story”, “Epic” or “Cross team epic”. One way to do this is to create a “bucket” “Epic” and/or “Cross Team Epic” for each team.

Note: Systems other than Jira may be able to hold team level estimates for a single epic in which case, you not need the third level.


My take on the Agile Manifesto is simple, the first line is the manifesto.

We are uncovering better ways of developing software by doing it and helping others do it.

The introduction of any new technique into the Agile Playbook is met with suspicion and challenge until it has been proven. Normally that means it is proven by its opponents. I have personal experience of helping to introduce two techniques, Given-When-Then and Kanban. Both met very strong opposition and there was debate that lasted years, and in some cases, that debate still continues over a decade later. Much of the debate was to understand the context in which these ideas were most valuable, and how they fit together with existing ideas. Acceptance of these ideas as agile has been hard fought and the community is stronger for it. These debates have made the ideas stronger, often with opponents becoming advocates.

SAI has avoided this challenge and debate, preferring to focus on its target customers who are mainly outside of the Agile community. Even worse, its marketing division has attacked and trolled many who dared to challenge it. SAFe has failed to understand that challenge is one of the key benefits of Agile. SAFe has presented a fully formed framework with “marketing style” experience reports. It has not built up a set of experience reports for challenge, describing the failures and associated learning. It is telling that SAFe has had several major revisions which included significant changes whereas Agile practices have tended to evolve with small revisions. This would indicate significant failures of the framework have not been shared with the wider community.

Three years after the leadership retreat, the SAFE franchise is still controlled by a small group, and there has been no attempt (that I am aware of) to engage with the wider agile community outside of the SAFe franchise and its franchisees. The definition of an epic can only be considered as academic and out of touch with the wider agile practitioner community. However the success of SAFE in the market place would indicate that they fully understand their customer’s needs. Causing confusion within companies plays to the strength of consultancies lacking deep experience in agile, and alienates those pesky agile practitioners who know what they are doing.

Can SAFe become Agile?

SAFe is here to stay. Its loyal customer base will ensure that their formerly unmet needs continue to be met.

To my knowledge, SAFe has not been endorsed by a single signatory of the Agile Manifesto. Neither has it been endorsed by a single winner of the Gordon Pask Award. In fact, I am unaware of a single leader in the Agile Community that has endorsed SAFe.

In order to gain credibility, the SAFe community needs to engage in debate with the wider Agile community.

Until SAFe engages with the wider community, people should understand that the “A” in SAFe stands for Academic. If SAFe wants to earn the right to use the word “Agile”, it needs to welcome the challenge and engage in debate.

* “Cross Team Epic” and “Single Team Epic” are terms that Andy Carmichel came up with.



Balancing the portfolio using Cynefin

The Cynefin framework can be used to assess whether the current and planned portfolio are balanced appropriately.


There are three patterns of portfolio investment depending on the maturity of the product.

  1. A startup would have a portfolio dominated by investments in the Complex domain as the organisation strives to understand customer needs and whether there is a viable product.
  2. A teenage organisation would see the majority of investment shift from the complex to the complicated domain as it seeks to scale and exploit its knowledge of customer’s needs.
  3. A mature organisation would have a portfolio dominated by investments in the complicated domain with a healthy slice of investment in the complex domain providing knowledge for the next generation of investments in the complicated domain. These investments in the complex domain allow the organisation to better understand customer needs as they evolve. Although an organisation should have a portfolio where the majority of investment is in the complicated (and obvious) domain, a portfolio with no investments in the complex domain will probably lead to the organisation losing touch with its customers and driving off the cliff.

Investments in the chaotic and obvious domains will normally be significantly smaller than investments in the complex and complicated domains. In times of crisis, investments in the chaotic and obvious domain may dominate.

  1. When the company loses touch with customer needs, investments in the chaotic domain may dominate. In such situations, normally heralded by a significant increase in churn, the organisation will be forced to focus a disproportionate amount of investment into addressing the issue. In this situation, the portfolio will naturally shift back to a healthy balance.
  2. In times of crisis, when the industry is forced to change by regulators, investments in the obvious domain may dominate. The Chief Product Owner (CPO) must ensure that the portfolio returns to a healthy balance and “crisis investment” does not dominate beyond the crisis. Managers responsible for Investments in the obvious domain tend to have a “Just Do IT” / command and control attitude. These managers “know what is needed” and do have regard for those who want to understand customer needs. The CPO should ensure that valuable people who research and understand customers are not lost during the crisis. These kind of managers find it hard to give up the significant resources at their command after the crisis, and the transition back to a balanced portfolio will require strong leadership.

Investments are in the disorder domain when the product organisation may not agree on which domain some of the investments  are in.

  1. “Four corners contextualisation” can be used to better understand the investment and how it should be treated.

Automated Test Coverage as a goal is at best, misguided

Setting Automated Test Coverage as a goal is at best, misguided. Automated test coverage is useful as a strategy or as a diagnostic metric, however using it as a goal is idiotic and will lead to waste and the wrong behaviour.


For any IT system, there are three options for testing:

  1. Automated tests
  2. Manual tests
  3. No tests

Lets pop the why stack on automated tests. Automated tests are faster and more reliable than manual tests. Automated and Manual tests are normally safer than no testing. So the reasons for automated tests are:

  • Reduced lead time.
  • Reduced variability in lead time.
  • Lower probability of a production incident.

Our goal should be to improve one of these metrics, normally reduce lead time. Lead time and automated test coverage are correlated. If you attempt to reduce lead time, one of the strategies you are likely to apply is to increase automated test coverage. As such automated test coverage is an excellent diagnostic metric to help the team identify ways to reduce their lead time.

There is not a causal relationship between automated test coverage and lead time. Increasing automated test coverage does not automatically reduce lead time. Many years ago I worked on system with no automated test coverage. Management imposed a 100% test coverage goal for all systems. Everyone on the project stopped working on anything else and spent a few days writing tests. As the business analyst I was given a list of classes and told how to write standards tests for each method to ensure the test coverage tool would register us as meeting our 100% target. We achieved 100% automated test coverage but no improvement in lead time or anything. The activity generated no benefit to the organisation, it was pure waste.

If you set reducing lead time as a goal, you will likely see an increase in automated test coverage. If you set increased automated test coverage, it is possible you will see no benefit.