Author Archives: theitriskmanager

About theitriskmanager

A IT programme manager specialising in delivering trading and risk management systems in Investment Banks. I achieve this by focusing on risk rather than cost. A focus on costs can lead to increased costs.

Communities of Need & Community of Solutions

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


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”

crossing chasm

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

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)

memes cynefin

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.

cynefin real options

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

real options principles

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”

Risk Adjusted ROI of Agile & Waterfall – A simple example

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:
Discounted returns of expected future cash flows.
Project Costs

The ROI for an Agile Project:
Discounted returns of expected future cash flows (Higher due to getting cash flows earlier)
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:
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).
Project Costs

The RAROI for an Agile Project:
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
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.

Risk Adjusted ROI of Agile versus Waterfall

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

ROI of Agile


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

Changing Culture – A Case Study

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.

“Left Shifting” a culture.

Yesterday, Richard Warner and I ran a session at Cukeup. The session included a “Left Shifting” exercise. This exercise was based on the Seeing Culture post.

I explained that I had recorded the different behaviours I had observed in an “Innovation” (or Risk Managed) culture, and the corresponding behaviours I had observed in a “Traditional” (or Risk Averse) culture. Richard and I then ran the exercise:

  1. Each group was given a cut down set of the behaviours listed in the seeing culture post.
  2. Each group selects a behaviour pair.
  3. The group then discusses what they could do to shift the culture from the behaviour on right to the behaviour on the left, or “Left Shifting”.

Examples so far discussed.

  • Count the number of times people praise “Hero” or “Dragonslayer” behaviour versus collaborative behaviour.
  • Create a game where you exchange a risk card for an option card every time you transfer a risk to someone else.
  • Publish how much has been invested based on hypothesis testing versus hippos.

Please leave other examples of things you could do as comments, and examples of behaviour pairs as comments on the Seeing Culture post.

“Inclusion” The BDD principle we call “The Three Amigoes”

There was an amazing panel discussion at Cukeup yesterday. If you are interested in BDD I would recommend watching it when it is posted. For me, the main take aways were:

  1. BDD is a centered community rather than a bounded community. This means that there is no division between those that do BDD and those that do not. Instead, teams are closer to the principle or further away.
  2. The BDD principles should be defined as a set of examples.

This is a great opportunity to explain “Break the Model” in Feature Injection.

We start by spotting an example. e.g. The Three Amigoes. We then create an examplar:

GIVEN we can identify all of the users of an investment

AND we can access those users

AND we can confirm the output they require

AND we can confirm their needs for the output

AND we can confirm the value to the business by satisfying the users needs

WHEN we prepare our set of examples

THEN The Business Analyst, The Tester and the Developer should create the examples together

AND They should ask the users to confirm their correctness.

This one example is our model, so we can easily spot another example that breaks this model.

GIVEN we cannot identify all of the users of an investment

AND we cannot access those users

WHEN we prepare our set of examples

THEN The Product Manager, The UX Designer, The UX Researcher, The Big Data Analyst, The Business Analyst, The Tester and the Developer should create the examples together

AND They will confirm the examples using usability tests and MVT.

We now have two examples and we can abstract out a model. The purpose of the model (Olaf)  is NOT to define the principle. The purpose of the model is to help us spot other examples.

The model we abstract is “Include someone representing every aspect of the the development process”

We now have another example:

GIVEN we are a start up containing a product manager and a developer only

AND we have customers prepared to work with us

WHEN we create examples

THEN the product manager, the developer and a customer should create an example together

AND we test the examples using usability and MVT.

We now abstract a new model “Inclusion”. The principle of BDD is that it is better to include as many people in the creation of examples as possible. Its a common sense thing though. Too many people in a single workshop can be disruptive and counter-productive. Those people not in the workshop should be engaged to confirm the correctness of the examples, and be encouraged to find additional examples that break the model.

Now that we have a model called “inclusion”, it helps us to focus on trying to find examples where someone should  be excluded from the process of example creation.

“Inclusion” is a useful name for the Olf/Model/Abstraction. It is not a good name for the principle which is “The Three Amigoes” which refers to the first (founding) example in the principle.

The model does not define the principle. The examples do. We can add to the examples and as we do, the model/abstraction will change. The principle name will stay the same.

I’m looking forward to seeing the “BDD by Example” wiki.

Risk Aversion and Risk Management – A case study.

WARNING: I’ve been lazy. It is quicker and easier ( and more fun ) to write this than hunt through the inter-web to find out if someone else has already written this down (I’m kinda assuming Troy or Liz have). I just need something to refer to.

I have been helping a waterfall Scrum* project adopt some Agile practices. Unfortunately the project had reached the point where there was a large backlog of manual User Acceptance Testing to be done. During the week I had a great conversation with the test manager for the project (The person producing the management reports). I realised that it was the perfect case study to understand the impact of the culture (risk aversion versus risk management) on a project.

The test manager categories all bugs as either Priority 1 or Priority 2. All of the Priority 1 & 2 bugs need to be fixed and signed off for the UAT to come to an end. Note that it is not desirable to time box the UAT on a Waterfall project as this will drive the wrong behaviours. The inspiration for this post came from a conversation on whether Priority 1 or 2 bugs should be fixed first.

Managing the UAT

In order to manage the UAT, the test manager needs two graphs.

  1. A burn-down of the tests to be run.
  2. A Cumulative Flow Diagram showing bugs as they are opened and closed.

The graphs below illustrate this point.

new doc 4_1

The UAT is over when the number of bugs closed line (Green) intersects with the number of bugs open line (black), assuming the zero outstanding test cases which have not reached the end of the test cycle.

There are two key milestones for a UAT.

  1. The most important milestone is reaching the end of the UAT (Obviously).
  2. The second important milestone is when all test cases have reached the end of their cycle, even if they contain bugs and are not signed off. The burn down for this is the blue dotted line. The reason that this is so important is that this represents the point at which further bugs are unlikely to be raised. The bugs discovered after this point are likely to be introduced as a result of fixing another bug.

The impact of Culture

So what does this have to do with culture?

In a risk averse culture, we avoid or ignore risk. We would want to demonstrate our competence as soon as possible. This would means we would want to demonstrate progress as soon as possible to gain the confidence of our managers.

In a risk managed culture, we would want to address the riskiest elements of the work first. We would be more interested in doing what is right for the organisation than demonstrating our own competence quickly.

Opening Bugs

So how would this impact the testing cycles?

If we are a risk averse tester we would want to demonstrate progress. We would want to show that we were getting through the test cases as quickly as possible.

Our focus would be on the pink line as this shows progress to the end of the UAT, the most important milestone.

To do this, we would pick those test cases that are easiest to sign off. We would pick those test cases that are least likely to contain bugs because they are quick and easy.

Furthermore, we would want to close bugs and sign-off test cases in preference to finding new bugs.

A risk managing tester would want to find bugs as soon as possible. Our focus would be on the blue dotted line. We would want to get to the end of all the test cases so that we would know most of the bugs in the system. For us, the most important thing would be to see the number of bugs raised flatten off as this allows us to manage the fixing of the bugs.

The graphs below demonstrate the impact of culture on the shapes of the lines. It is assumed that the same project with identical number of bugs discovered.

new doc 6_1

Both projects finish on the same date because the contain the same amount of bugs that require the same amount of effort to fix. However, consider the perspective of the test manager. In the risk managed culture, they know that they have discovered most of the bugs much earlier, and can take appropriate resourcing decisions.

Closing Bugs

So how would this impact the fixing of bugs?

If we are a risk averse developer we would want to demonstrate progress. We would want to show that we were getting through the bugs as quickly as possible.

Our focus would be on the green and pink line as this shows progress to the end of the UAT, the most important milestone.

To do this, we would pick those bugs that are easiest and quickest to fix and sign off. We would defer bugs that are complex, or take a long while to fix. We would potentially defer those bugs that block us reaching the end of the test cycles if they are complex or take a long time to fix.

Furthermore, we would want to close bugs and sign-off test cases in preference to finding new bugs as this looks better on management reports.

A risk managing developer would want to find bugs as soon as possible. Our focus would be on the blue dotted line (fixing bugs that block us from reaching the end of test cycle), and on fixing bugs that are most likely to result in further bugs, namely the complex and large bugs. The number of bugs closed and the number of test cases signed off would be of secondary importance.

Assuming a risk managed tester, the below graph shows the impact of culture that the developer works in impacts on how bugs are fixed.

new doc 8_1

The risk averse developer would want to work on easier bugs that show them making progress. As a result there might be a delay (marked as “A” on the graph) on finding all the bugs in the system. This means that the risk managed developer would know with more certainty how much work needs to be done for “A” units of time.

The risk managed developer trades uncertainty at the start of the testing cycle for more certainty at the end of the test cycle. Conversely, the risk averse developer pushes more uncertainty (risk) to the end of the test cycle.

The risk averse behaviour makes it very difficult to manage resource loading for the test cycle whereas risk managed behaviour allows effective management of resource loading.

Simply put, risk managed behaviour gives more options than risk averse behaviour.

A final point on this, consider the projection (using a velocity measure) of the end of UAT. The graph below shows that the risk averse behaviour results in larger and larger time extensions at the end of the testing cycle ( A -> B ), whereas the risk managed behaviour results in smaller and smaller reductions of the time to the end ( A -> B ).

new doc 7_1

In conclusion, risk managed behaviour does allow management of testing, whereas risk averse behaviour does not. Anyone managing a testing cycle should understand that attempting to demonstrate early progress leads to a loss of management and control.

*These days it is really easy to find Waterfall projects. They are normally called a “Flagship Agile” project. The irony escapes them. A Culture Changing Agile Project would be called an “Agile Canoe” or “Agile Raft” or “Agile Rowing Boat”. Certainly not the flagship which is normally an aircraft carrier.


Get every new post delivered to your Inbox.

Join 81 other followers