Agile Business Coach

Kolb Sites

The business coach role is that of a knowledge agent. The business coach actively seeks out knowledge for the project and then transfers that knowledge to the developers and other project personnel.

My model for IT development is based on the experiential learning model by David A. Kolb.

Here are two useful websites on David A. Kolb and experiential learning.

http://www.infed.org/biblio/b-explrn.htm

http://reviewing.co.uk/research/experiential.learning.htm#26

Knowledge Management View of the Business Coach Role

This is my knowledge management view of the business coach role. There are things we know and things we do not know. "A" represents stuff that we do not know we do not know (We do not know what question to ask). "B" is stuff that we know that we do not know (We know the question but not the answer). "C" is stuff that we know (We know the answer).

When we know something, it is a matter of transfering that knowledge to the developers on the project. This knowledge transfer is traditionally done using documentation. The Agile Business Coach will use whatever teaching/coaching aid necessary to transfer the knowledge. From experience documentation is the worst way to do this and face to face coaching at a whiteboard is the best way.

Issue resolution allows us to find the answer to the question.

Learning which uses the traditional analysis tools allows us to form the question. From my experience, using analysis tools ( Object models drawn on paper) is best performed in pairs. At Dresdner Kleinwort Wasserstein we called this eXtreme Analysis or Pair Analysis.

Requirements in the form of UAT Expected Results

On my current project, the business users are specifying their requirements in the form of User Acceptance Test Expected Results. Every Friday afternoon, the head of credit and his three most senior staff spend an hour specifying the expected results for a set of sample inputs.

They are doing this for a number of reasons:-

1. They trust us (I hope) when we tell them that they are important.
2. The can state with certainty that the results are accurate whereas a functional spec is normally too abstract or lengthy to understand fully.
3. Two uber developers Andy Pols ( www.pols.co.uk ) and Joe Walnes ( joe.truemesh.com ) did a two day XP spike where they implemented two of the UAT results using FIT. The head of credit saw this and could see how important the UAT results were to a UAT driven development. It did not need an act of trust because four man days is not a big investment on a multi-million pound development.

Business Value : Case Study Part 2 - Break it down

We now have a business value for the project which is $ Y - Z million.

The next step was for the business to break this down and allocate it to the different parts of the project. They did this as follows*:

1. Calculate exposure - 25%
2. Manage Collateral - 25%
3. Manage limit breaches - 20%
4. Synergy - 30% This is the value released when all parts of the project are in place.

We are currently at the point where we are about to break down the value to the next level. Initial discussions around collateral indicate the following:

1. Manage Letters of Credit - 75%
2. Other types of collateral - 25%

This means that most of the value for Collateral comes from Letters of Credit (LCs). LCs only account for 20% of the requirements. The agreement with the business is that a gold plated solution will be developed for LCs and a sticky tape and string solution for the rest of the collateral types.

Also the business value (to go on the XP Story card) for LCs will be an actual number, namely .75 x .25 x (Y - Z) million. The business value is a model rather than a number so we can determine the business value in a number of scenarios.

The project is calculating the ROI on the investment based on three estimates of the costs. One where the project costs the original estimate, one where it cost double and one where it costs 4 times the original estimate. This gives confidence of 10%, 50% and 90%. For more detail of this, check out Todd Little's forthcoming paper on actual versus estimate values for 120 projects.

Hopefully this illustrates how business value can be used to prioritise work on an XP project.

• These are not the actual categories or numbers used in the project.

Business Value : Case Study Part 1 - The model

We are applying business value development to my current project. We are now in a good place to start development driven by business value. This was not always the case. The business value statement for the project is now on its third version. This blog is the story to date of the business value.

The project is to replace the current credit management systems with a state of the art solution.

The first version was created by the project rather than the business users. Its premise was that there had been 6 substantial bankrupcies in the previous year including Enron. These amount to X million pounds. The argument was that if the new system was in place, the losses would be reduced by 20%. The 20% number was randomly selected based on discussions with senior management. The business value of the project would be X / 5 million per year. The main idea of the business case was that the new system would reduce losses due to defaults.

Sanela Hodzic and I were working on the project. We were uncomfortable with the business case because it assumed significant defaults every year. However, defaults tend to cluster in bad years such as a couple of years ago when the economy was in a poor state. We suggested a second model. This was based on a monte carlo model to calculate the possible losses developed by Sanela as part of her masters degree. I will cover the detail of the model in another blog. The model gave a distribution of possible losses rather than a single value.

Sanela then worked with the head of credit to develop the current model. This argument was very different. Currently the credit limits in use are very conservative which restricts the growth of the business. This is because the credit managers do not fully trudt the accuracy of their system. The new system will give more confidence in the exposures calculated. This will mean that higher limits will be given and result in more business growth. The model suggests a 10% growth in revenues will result. This translates to an $ Y million increase in profit. However, the higher credit limits will result in a $ Z million increase in losses due to counterpart defaults. The business case is that $ Y – Z million additional profit will be generated each year. This is directly opposed to the original business case because the introduction of the new system will actually lead to higher, not lower losses. The difference will be that management will be able to make strategic decisions on where those potential losses will occur. This model is owned by the business users and they are presenting it to senior management to justify the investment in the new solution. I will cover the model in detail in another blog.

Agile Manifesto : "Over", not "Instead of"

I just read an article by John Seely Brown ( http://www.slofi.com/IKM_Practice_vs_Process.pdf ) that was recommended to me by Adewale Oshineye. It is about the tension within firms and communities between innovation and control. I thought that a new agile principle could be that we value innovation over control. It made me revisit the Agile Manifesto and I now have an even greater respect for the people who created the document. We all know the Agile Manifesto ( http://agilemanifesto.org/ ). Whilst we value the items on the right, we value the items on the left more. For example, Responding to Change over Following a Plan. I suspect that many people read it differently to what it actually says. Many people, myself included, read “Instead Of” rather than “Over”. The Agile Manifesto does not say that we should not plan, it just says that we should value change more than the plan. This is because software development by its very nature is all about change. We should therefore do planning but in a way that allows for change. Similarly, the manifesto says we should value people and interactions over processes. This is one of the biggies for people who opposed to Agile and XP. They claim that XP is for hackers with no process. In fact, XP has a very clearly defined process, it is just very light and allows for change and creativity. We should therefore have a process rather than randomly lurching about as people assume. In fact, most agile processes are excellent in that they are based around the business (sponsor) controlling the order of development rather than the IT manager. Working software over extensive documentation. Once again, it does not say no documentation. The documentation should have a purpose rather than for its own sake because the methodology calls for it. And the same for customer collaboration over contract negotiation.

My current project needs documentation. It needs a plan. It needs contracts with third parties. It needs a process (which will be a variant of XP if the business sponsor and myself get our way). Why does it need a plan and all the other stuff? Quite simply, it is a massive programme of work that will cost about $30-50million. It will require about fifty interfaces and ten systems to be developed for use by users in five different global locations. The development team will be performed by a number of teams that need a common way of working. Not all of the team will be alpha prime developers, some will be more junior or less able because the company has a policy of looking after its people and helping them to develop. The project funding is an investment funding decision which is a business decision based upon estimated costs from a plan. The interfaces need scheduling and coordinating with systems that are also currently in a state of development or rework. A number of the projects will be to implement systems from third parties that will need modification. The development team cannot sit with the users because there are so many of them and also the users are located throughout the world so we need to communicate decisions and issues using documents in some cases.

So if I tell you I need a plan, don’t think I’m not agile because I still value change more than the plan. I also value innovation over control.

What is Agile?

I just got back from the eXtreme Tuesday Club, XTC ( www.xpdeveloper.com ) where I had an interesting chat with Austin Iduoze, Romilly Cocking and Adewale Oshineye about what is Agile.

We evolved a single sentence to describe Agile. "Agile is about delivering Business Value (with Software) through learning via continuous feedback.

Tom Gilb and Lindsey Brodie joined us and I told him the definition. Tom disagreed. He said Agile is about keeping it simple (small) and direct. It is about stripping away the pointless documentation that clogs up projects. It is the opposite of non-agile processes such as CMMI.

Overall a really nice evening with some great conversations.

XTC reminds me of the description of the early days of the Royal Society in Neal Stephenson's Quicksilver. A group of people keen to learn and discuss the latest thing in software development that meets in the back room of an old London pub.