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.

wolf-in-sheeps-clothing-2577813_1920

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.

Academic?

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.

palette-2636553_1920

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.

hand-697264_1280

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.


Investing with Cynefin: Disorder

Disorder is the fifth quadrant in the Cynefin model. Disorder is where there is no clarity about which of the other domains should apply.

“Here, multiple perspectives jostle for prominence, factional leaders argue with one another, and cacophony rules”.

hippo-3645651_1920

The solution is “obvious”, bring the leaders together to perform a “complicated” ritual that reveals the “complex” nature of the problem and hope that the personalities involved do not turn the conversation into something “chaotic”.

A technique like four corners contextualisation can be used to facilitate a conversation between decision makers. The discussion will normally reveal that the problem is one of granularity. Decision making is a classic example of something that is often in the domain of disorder. However, when we break it down into a lower level of granularity, we discover that it falls in the other four domains.

  • The output, an ordered list is obvious.
  • The process such as cost of delay is complicated.
  • The interaction between the investment options, the available resources and the participants are complex.
  • The behaviour of warring factions is chaotic.

By moving to a lower level of granulation, the domains become apparent.

Investments that remain in the disorder quadrant indicate a dysfunctional decision making group. Often a hippo will force these items into one of the other domains. Disorder is often a symptom of a group stuck in “storming” that is not coming together to communicate.


Investing with Cynefin: Complicated

The complicated domain is the realm of strategic superiority. Organisations know with certainty how customers will behave, however it is not common knowledge. This is where organisations should focus their strategic investment.

star-2496357_1280

The complicated domain is where organisations should be making larger investments as this is where they have competitive advantage. The only place where organisations should be making larger investments is where they are forced to due to regulatory dictate (Obvious) or to resist the vertiginous draw of the cliff (The Cliff). The complicated domain is where constrained resources should normally be deployed.

The complex and complicated domains are not binary in nature but rather “linear” with 0% certainty at one extreme and 100% at the other. As such, the investments are best managed using the Kelly criterion. The nature of the experiments change. Whereas in the complex domain, the experiments relate to understanding needs, in the complicated domain, the eperiments relate to the scope of the needs.

For organisations, the danger with the complicated domain is that too many investments are made in it. Either because they are classified incorrectly due to perverse cultural incentives or because the organisation is utterly risk averse. One is reminded of the risk averse anthem “No one ever got sacked for investing in the complicated domain. buying IBM.”. The real message being that perhaps some people should have been sacked for failing to think for themselves.

In summary, investing in the complicated domain is the easy option. Therefore the investment decision process should make it difficult to do so.


Investing with Cynefin: The cliff

In the Cynefin framework there is a cliff between the Obvious and Chaotic domains. Systems fall down this from the ordered domain down into the Chaotic domain. This is eloquently summarised by Mark Twain…

It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.

action-1838330_1920

Retail businesses on the high street are currently thrashing around at the bottom of this cliff. After years of pulling levers to control shoppers and extract profits, the bricks and mortar retailers now resemble Dr Who randomly playing with the controls of the Tardis as it bounces around reality. The reason is that the internet has changed the fitness landscape of business and new apex predators have emerged that are disrupting existing players.

When organisations find themselves inside the OODA loop of an Apex Predator in an unfamiliar fitness landscape, they have to act, sense and respond. As a result, investments in the chaotic domain may result in disrupting the investment process in all of the other domains. Although investments in the chaotic domain should ideally be small, there are occasions when all the resources of the organisation will need to be focused on them.

Ideally organisations should avoid the cliff all together, and if necessary they will need to invest all of their resources to keep themselves away from it. Organisations can use metrics to detect the presence of the cliff. In particular they can use churn metrics. An organisation would typically have three sets of customer metrics…. Number of customers, customer activity and customer revenue. The trend is more important than the actual value for investment decision making.

Churn

In the example above the metrics may initially appear healthy. Every week sees a 10% increase (Green). However looking at the churn number indicates a problem occurred in week 4. At this point, the organisation needs to act as it heads towards the cliff / lands at the bottom of it. The action required is normally to gather information. Why has churn just jumped up? Which customer need is not being met, or possibly which customer need is being better met by a competitor’s product or service? The research will either involve data analysis or user experience research (to understand user needs/jobs to be done).

Many organisations wallowing at the bottom of the cliff have no data analysis or user experience research capability. For these organisations, the ‘act’ is simple, to acquire these capabilities.

Modern organisations wishing to avoid the cliff need to invest in data analysis and user experience research capabilities before they find themselves being disrupted by another organisation’s OODA loop.