As part of the work that Chris and I performed on the product management framework (ref the link), we tested it for fit against a series of different sources of insight. Interestingly, we found that the three branches of Business Outcomes, User Needs and Target Groups were sufficient for progressing to design concepts; the trick was identifying the order in which the disciplines are involved.

The table we came up with is shown below. While it might seem curious that, for example, an iPad starts with the business outcomes, we began here because it’s clear that Apple would have a very clear view of what they wish to achieve from a future product and would build their product to those KPIs. They have a clearly identified target segment for new products and subsequently focus on meeting that group’s needs. Note that leaving the User Needs until last does not imply that these are subservient to the remaining disciplines; rather that the met needs will be focussed toward driving the KPIs for the identified segment.

We do not show Technical Insight here. This was a recurring theme in the recent book “How Google Works”. However, a technical insight makes something possible that was previously not possible (or cost effective / adaptable). One must still meet the needs of a target group for a given outcome, even if the ultimate use is not apparent at the start of the process. Thus technical insights help us prioritise; however, we still create products that meet the needs of a segment of users, in line with our business goals.

Note that business analysis is the correct approach for Technical Improvements or Regulatory Compliance. These are the role of domain experts – the Complicated space in the Cynefin model – rather than the safe-to-fail experimentation of product management as befits the Complex space.

We’d love to know whether this tallies with your understanding of how insights can be used. And are there any missing cases?

Much of my thinking recently has been on Culture in Organisations. I am also interested in the Culture in Communities, and in particular Communities of Practice like Agile and Kanban. My thinking has lead me to observe that there are two distinct communities within a Community of Practice. One community based on solving problems, or a “Community of Need” and the other based on promoting solutions or a “Community of Solutions”.

Context

Crossing the Chasm by Geoffrey Moore is a well established way of looking at technology adoption. It is so well established that Seth Godin rebranded it as Purple Cow for the Marketing Community over a decade ago. To summarise, through out its life time, a technology will be adopted by “early adopter”, then the “early majority”, “late majority” and finally the “Lagards”

Between the “Early Adopters” and the “Early Majority” is the Eponymous Chasm that many great ideas have fallen into, never to be seen again. “Crossing the Chasm” is about getting an idea across that Chasm to the riches and success on the other side.

It has helped my understanding of this to overlay Julian Everett’s excellent work on “The Meme Lifecycle“.

From Julian’s Meme Lifecycle, all meme come about as the result of a need. Before the meme or solution exists, there is simply a need*. There are often several independent groups or individuals working on solutions to the need which it is why there are often several independent and competing solutions that occur at the same time. Once a meme has come into existance, it goes though a period of evolution and natural selection. During this phase, the meme is tested in different contexts, or fitness landscapes. In each fitness landscape, the meme might take a different form or expression known as an extended phenotype. The key issue about this stage is that a great idea might fail because of the context, and as a result it will need to evolve to satisfy the needs of that context. As a meme approaches the chasm, the uncertainty about the contexts it will and will not work in is resolved. A necessary condition of a meme exiting the chasm is that there is certainty not only about the meme and how to use it, but also which contexts it will and will not work. People who claim that a meme fits all contexts and then modify it to fit a new context are preventing the meme from exiting the chasm. In my opinion, Scrum needed Kanban to leave the Chasm.

For example, Recently someone asked Richard Warner and I about Scrum and Kanban. In fact, they knew what they were and how to do them, what they wanted to know, was “when to use Scrum or Kanban”. Richard came out with the following conditions:

1. In order to put work into Scrum, you have to be able to estimate it (or time-box it). This means for discovery (PM/UX) work, Kanban is a preferred mechanism.
2. Scrum is only possible when the work is predictable for at least the next week or two. For highly unpredictable work, such as IT Operations or UAT, Kanban is preferred.
3. Kanban works best when the person responsible for prioritisation (Product Owner) is highly available, preferably co-located. In situations where the prioritiser is not highly available, it preferable to batch requests using Scrum. So for an off-shore development team, the PO team might use Scrum to manage prioritisation. The development team might use Kanban inside the Scrum framework.

Its is now known when to use both Scrum and Kanban most of the time. This makes them far more appealing to the risk averse who hate uncertainty.

Next, I overlaid Dave Snowden’s Cynefin. Doing this helped me link to the cultures associated with each part of the curve. (More to come later on this)

Cynefin maps nicely to the Meme Life cycle. From creation of the meme to exiting the chasm, agents engage in safe to fail experimentation to test multiple hypothesis in order to map the meme to the different fitness landscapes.

Mapping to Cynefin made it easy to map to Real Options. An option’s value is only greater than the intrinsic value when there is uncertainty. When there is certainty, there is no value in deferring a commitment. This is where “unless you know why” comes in. If you know why, if you have certainty, then you can commit early.

And finally, it is possible to map to principles versus practice.

Those operating before the chasm act based on principles. They understand that they may be operating in a fitness landscape where the meme they are using fails. Once the meme has exited the chasm, the users expect that they only need to follow the practices, and the principles become less important. Often the principles are forgotten or ignored and this leads to failure as more obscure fitness landscapes are discovered. This failure corresponds to the cliff in the Cynefin Model. Fundamentally, principles should dominate before the Chasm, and practice dominates after the chasm. This causes real problems for memes that are principle driven like many of the Agile practices.

Communities of Practice

There are two clear communities of practice that overlap considerably:

• The “Communities of Need” are centred on the creation of memes. Members of this community operate in the area of “Need” to create a meme and then work with the meme to identify fitness landscapes where it fails, and evolve them accordingly. These communities have problems that need to be solved. They take solutions developed for one context and attempt to implement them in their own context (exaption), and modify (evolve) them as appropriate.
• The “Communities of Solutions” are centred on the Chasm. Members of this community attempt to extend the number of fitness landscapes that a meme works in and then sell the meme to the early and late majority on the other side of the chasm.

Communities of Need

Communities of Need can easily be identified by their gatherings. For example, conferences would consist of the following:

• An un-famous Keynote, often talking about ideas that are unfamiliar or novel to the community. The keynote has practical experience of the material they discuss. The keynote is not normally a draw for the conference., (The gathering of the community, and exchange of ideas is often the draw.)
• Experience Reports dominate, and spark discussion. There is an understanding that Communities of Need grow based on experiences. An experience prompts others to share stories and a “model” is built accordingly.
• The conferences have a heavy open space element as the participants are often as knowledgeable as the speakers/facilitators. Organised sessions are often workshops ( Gold fish bowls ) to harvest community knowledge.
• Context is everything.

Examples of “Community of Need” conferences include XP Day, Lean Agile Scotland, Agile Lean Europe 20xx, Lean UX NYC.

Once a need has been resolved, communities of need may dwindle, or move on to solve another need. A classic example of this is XTC. The needs of the London XTC community have pretty much been met. They know how to write software in small teams, and there are no significant community needs outstanding. As such, those interested in personal development now gravitate towards the software craftsmanship community.

Every member of a “Community of Need” is a leader. They are Problem Champions. As such, these communities do not tend to have leaders. If anything the leaders are often servants of the community who support the community, organising events but no one knows who they are.

Communities of Solutions

Communities of Solutions are about promoting meme across the chasm and beyond. Their conferences are also obvious:

• The keynote is famous. More often than not talking about a subject they have no practical experience in. They have either read a book or done a bit of study. Malcolm Gladwell is the ultimate expression of a keynote for a CoS. If they do have any experience, it dates back years in the past.
• There are normally workshops added onto the conference on subjects near the chasm.
• The sessions are organised in advance and consists of talks, workshops and “taster” sessions where the attendees learn from the speakers. Attendees want to be told what to do.
• The Conferences are organised as commercial ventures with the profits generated going to the organisers.
• Context is not considered relevant.
• “Community of Needs” individuals are normally the speakers and hold small impromptu conferences in “The Corridor”

Examples of “Community of Solution” Conferences include Agile20xx, QCon, Goto.

These communities have leaders with a clear pecking order. The leader often annoints the next generation. The leaders of a “Community of Solutions” are often not practitioners or even members of the “Community of Need”. Their position is normally due to their relationship with the existing leaders. “Communities of Solution” have leaders and followers. The leaders are the Solution Champions.

Scaling Agile

So where am I going with this?

The Communities of Need in the Agile Community are in a terrible state. Very few members of the Community of Need attend Agile 20xx anymore. There just aren’t enough practitioners around to create a decent corridor conference.

There is a belief that Agile is crossing the chasm, or that it has crossed the Chasm. Merging these different views has helped me to understand the following:

1. Some Agile Practices have crossed the Chasm.
2. Agile has not crossed the Chasm.
3. Scaled Agile certainly has not crossed the Chasm.

Picking on Safe as an example of Scaled Agile, there are three parts:

• Team level Agile – This has crossed the Chasm. Safe provides a nice packing of the established Agile Practices.
• The Agile Release – This is halfway toward the chasm. There are several successful case studies.
• Portfolio Vision – Agile at this level has not even identified all the needs. There are still several problems to be identified.

So some of the Safe practices are across the chasm with the uncertainty resolved. Others have not. You need to hire people from the “Community of Solutions” to train and coach your organisation. That is not enough though. Any company considering an Agile Adoption at Scale should also hire a number of people from a “Community of Need”. The people from the “Community of Need” will help you with the context issues. They will also help you create safe to fail experiments for those problems where there isn’t a known solution. To misquote Dave Snowden “You need Chefs as well as cookery books”.

I’ll end there. This is part of the Keynote I’m preparing for Agile Lean Europe 2015. My next post will be to discuss the problems caused by the lack of structure linking these two sets of communities.

* This is known as the entrpreneurs in “Crossing the Chasm”

Inspired by Ron’s Comments on the Risk Adjust ROI of Agile and Waterfall post, I wrote a simple example to illustrate the point I was trying to make.

The expected ROI of an investment is often put into a spreadsheet where the present value of future expected cash flows is calculated using a discount factor based on the appropriate interest rate.

The ROI for a Waterfall Project:
equals
Discounted returns of expected future cash flows.
minus
Project Costs

The ROI for an Agile Project:
equals
Discounted returns of expected future cash flows (Higher due to getting cash flows earlier)
minus
Project Costs (Higher due to additional testing & release costs)

The higher value of discounted returns due to getting cash flows earlier is not that significant, especially in low interest rate conditions such as we are currently experiencing. The expected project costs are much higher as the testing and release will happen more times. The person putting the spreadsheet together would rightly assume that if we can reduce these costs, we would do so in both scenarios.

As such, Agile does not fair so well when compared to Waterfall using expected ROI.

Now lets consider the Risk Adjusted ROI.

The RAROI for a Waterfall Project:
equals
Discounted returns of expected future cash flows (The cash flows should be risk adjusted as well as simply discounted due to interest rates, resulting in a much smaller value).
minus
Project Costs

The RAROI for an Agile Project:
equals
Discounted returns of expected future cash flows (Higher due to getting cash flows earlier, especially given risk adjustment)
plus Option to increase investment
plus Option to change requirements
plus Value realised by reducing uncertainty through the tests
minus
Project Costs (Higher due to additional testing & release costs)
less Option to terminate early without losing investment to date
less Option to release without having to manually test

Using RAROI results in a much higher value for the Discounted Cash Flows in Agile than Waterfall. This is because the risk adjustment would be more significant and would have a great impact on the Waterfall cash flows that occur at the end of the project than the Agile project where the cash flows occur earlier. The risk adjustment would take into account for things such as:

• The longer time before the product reaches the market increases the chance a competitor releases a similar product.
• The longer the project is running, the more chance it has of being cancelled.

The options cannot be valued accurately. Only snake oil salesmen and fools would advise using Black Scholes. Instead, we make up some values for illustration purposes only. A simple option payoff multiplied by the probability will suffice.

Option to increase investment

If the value of the investment is shown to be significantly more than expected, more can be invested.

e.g. 10% chance of Value being double that expected.

5% chance of Value being ten times that expected.

Option to terminate early without losing investment to date

This option would save an amount of the costs. This option requires that the people on the project can be re-deployed onto something useful instead. For simplicities sake, lets assume that this relates the forty percent of feature never, or rarely used according to the Chaos Report. i.e. Forty percent of costs of the project.

Option to change requirements

So this relates to those forty percent of features cancelled. That money could be re-invested in valuable features instead. A potential up-tick of forty percent in the value.

Option to release without having to manually test

This is a particularly valuable option as it improves the resiliency of the system. Emergency production fixes can be put live without the risk of putting untested fixes into production, and without the delay of manual tests.

It can be seen that the Options in the RAROI create a significantly more robust argument for using Agile than Waterfall.

In summary, RAROI shows that Agile is superior than Waterfall whereas ROI does not. Often people think they are using ROI when in actual fact, they are using RAROI. Whilst it does not make a difference to normal people, it does to people who are experts in finance.

Thank you Ron for your thought provoking comments.

“In theory there is no difference between practice and theory. In practice there is.” This week I saw one of those examples.

Nice.

ROI $$ (agile) > ROI $ (waterfall)

A great compelling argument for those promoting agile over waterfall. The only problem is that it is naive and WRONG. The argument can only be had in retrospect. The organisation runs two projects, one agile and one waterfall, and compares the ROI on the two projects. I am not aware that anyone has run such an experiment. It is a religious belief without proof.

In reality, the comparison of the two approaches is done before the project starts. The comparison is made on the expectation of the ROI. Those performing the evaluation compare what they expect the ROI to be. The fact that they are considering waterfall indicates the project has a knowable outcome and is in the complicated domain of the Cynefin framework. The functionality is known. If at this point, it is known that the functionality could be reduced, then it would for both. However, when we look at the costs, waterfall only has one test and production release and agile has lots. Given the information at the time, Agile will cost more compared to the waterfall approach. The fact that they are considering waterfall also would tend to indicate a risk averse culture at play which means they wont consider risks or changes.

In summary

Expectation ( ROI (agile) ) < Expectation ( ROI (waterfall) )

Which means that if you encounter someone competent from Finance or a Finance background and start talking about ROI, you are going to sound like an idiot. Someone will use your lack of understanding to undermine your argument to their advantage.

Now lets consider Risk Adjusted ROI. Risk Adjusted ROI is exactly as it sounds. It adjusts the ROI for risk. There are many types of risk associated with an IT investment. Steve Freeman and I wrote an article in The Agile Times (published by the Agile Alliance in 2005) where we list the three categories of risk.

1. Delivery risk – Failure to deliver the investment within the agreed constraints
2. Business Case risk – Failure to deliver the identified value
3. Damage to the Existing Business Model – The investment damages the exisitng business model

Agile can be used to manage all three categories of risk better, but only if it is applied properly. A Scrum or Kanban project that only releases once a year is not managing risk (and is not really a Scrum or Kanban project).

Now lets compare the expectation of an agile and a waterfall project. All of a sudden, all of the real options that exist in an agile project and make it less risky, can be considered in the valuation. i.e.

Expectation ( Risk Adjusted ROI (agile) ) > Expectation ( Risk Adjusted ROI (waterfall) )

And this is where theory and practice come in. In theory, the ROI argument is good enough. You read a few books and write down that ROI is the way to compare agile and waterfall. The practitioner tries this out and it does not work. They then have to dig deeper into the theory to come up with a something that does work. “As simple as possible but not simpler”. “A simple as possible” is the battle cry of the theorist. “but not simpler” is the retort of the practitioner. Finding “As simple as possible but not simpler” for your context can only be determined by praxis, the co-evolution of theory and practice.

For me, a humbling example of this on a personal level was when I was trying to come up with a definition of business value in 2003. I read “The Goal” by Eliyahu Goldratt and thought “A project creates value when it increases revenue or reduces costs”. I asked the business manager on the trading floor and he said. “Nope! Eighty percent of our investments are to protect revenue, either retain customers or build risk management systems.” – To quote Jabe… “Praxis makes perfect.”

The most innovative and Agile organisation I have worked in during my entire career was Dresdner Kleinwort Wasserstein, DrKW ( Formerly DrKB Benson ). DrKW had an innovative, competitive and risk managed culture. This was not an accident. It was not some kind of freak accident. It was the deliberate creation of Al-Noor Ramji, which was built upon by JP Rangaswami. Without doubt, the two stand out leaders (so far) of my career. DrKW was not a happy clappy place. It was an extremely disciplined organisation whose IT department allowed it to punch above its weight and compete in markets that similar sized banks could not.

Al-Noor did not inherit DrKB IT in that state. It was an IT department formed of a conservative German Bank and a traditional English Merchant Bank that had massively under-invested in IT for years. The first thing Al-Noor did was raise the bar which was a painful process for those who did not make it, and for those that survived.

In retrospect the key thing Al-Noor did was reduce the power distance gap. Subsequently JP destroyed it all together.

Power distance? DrKW had the hardest recruitment process I ever encountered. Getting into ThoughtWorks was a breeze by comparison. You had to give up an entire Saturday to do tests, including how you worked in a group. And you had to score higher than the average of everyone already there. The bar rose and rose. The final step tripped up many. You had an interview with Al-Noor himself. Al-Noor had an office on the trading floor. The hottest piece of real estate in any bank. It also meant he was close to the business in case they wanted him, or he needed to hear what was going on. The only question I remember was “Chase Manhatten* is a rich bank with lots of money, how will you cope here where we have very little money?” In retrospect, it was perhaps a question about innovation, I just assumed that Al-Noor was trying to put me off. A while later a candidate I put forward called after after his interview. He had passed but did not want the job because “he never wanted anything to do with that a**hole again.” I asked him if he had ever met his current or previous CIOs. I pointed out he had had a one to one with CIO. If he wanted another, they knew each other, though he would probably have to make an appointment. Al-Noor reduced the power distance gap.

Every night JP finished work at five o-clock. Regular as clock work he went to the same place. If you needed to speak to him, you knew where to go, no appointment necessary. JP destroyed the power distance.

Delivery? We had one rule. Deliver something of value to the business within three months or you lose your funding (and your job). This was back in 2000 before Agile was mainstream. This was the hardest learning for me as I was used to six month and one year projects. Al-Noor declared victory at an all-hands. He reflected that the challenge to change thinking on IT had been hard. But it had taken the business a lot longer to make the transition.

Learning? Dresdner was a highly competitive environment. One day, Al-Noor asked everyone to do brainbench tests. Lots of muttering and dissent. A few did it begrudgingly. They shared their scores. Within an hour everyone was doing Brainbench tests. You would not believe how competitive people could be about their knowledge about “Harry Potter”. I won a digital camera for scoring second on SQL skills. Learning and being honest about your ability became cool. Pure gamification.

Mastery? We had three day hackathons. Four teams of six that merged into two after the first day, and became one for the last day. I was team lead when we learned about C⌗ (in beta at the time) and Bandwidth trading. My team lost but the real headline was the play fight JP had with one of the guys the night before he was announced as CIO. Power distance index?

Innovation? Al-Noor demanded that we think of the IT department as an incubator. We were asked to examine our systems as candidates for start ups. DrKW spun off several including Yolus that I encountered at subsequent banks. DrKW also released its best software as open source. Open Adpator and Bhavaya. Early forms of the practices known as Feature Injection, Specification by Example and Staff Liquidity were all practiced at DrKW. Developed through necessity without budget. Something about the coffee?

Mentorship? I had a lot of one to ones with JP about Strategy. The truth is he was my first mentor. He gave me books to read including Jim Highsmith’s “Agile Eco Systems” which started me on a path to Agile. As Business Analysts we were the first involved in many projects. I was a good way of hearing news from the front, and influencing direction.

Loyalty? I only remember two one to ones with Al-Noor. the first, my final interview. The second at Heathrow airport. Market conditions and I had made me redundant at DrKW and I needed a job. Al-Noor said I was one of his and asked where I wanted to work. I just had to do a test. At the time Al-Noor was CIO at QWest where Jane Tabeka and Michael Spayd met him.

Unlikely as their need would be, if Al-Noor or JP needed my help, I would instantly hand in my notice.

So for those who say it impossible to change a culture. I say hire Al-Noor Ramji or JP Rangaswami. Or at least raise the bar and destroy the power distance.

*I worked at Chase Manhatten before DrKW.