Agile Business Coach

Frequent delivery of Business Value

In the beginning, there was Business Value. Then the project was funded and the team forgot why they were bought together. Some said that they wanted to deliver working software. Others wanted to deliver change in a controlled manner and other just wanted to have fun. The business coach came amongst them, told them stories and broke all the sacred models. There was calm and all pulled in the same direction. That direction was the frequest delivery of Business Value.

Agile is Learning

Agile is Learning

All Agile principles and practices are based upon feedback and learning. Kolb presented a model of (adult) learning that involved the following circle of actvities:

Observation
Modelling
Testing
Reflection

This is a model that underlies all aspects of Agile development. In particular, Agile tests models in a production environment. It uses ultimate truth to test models rather than proxies of reality.

XP involves building a model of the business in software, testing it in production, reflecting upon its success, observing, and improving the model. XP provides practices that make it possible to ensure that each iteration improves on the previous iteration, namely automated testing.

XP persists a failure proof memory of all previous tests. No test is forgotten. It is not possible for software to forget a problem that it was developed to solve. The automated tests are infallable compared to human testing. It is possible for software to fail due to a condition for which it was not tested. This is a learning circle for software development.

Agile learns about the process that it uses to develop software. Retrospectives are used to assess the quality of the development process / methodology. Retrospectives are a mechanism to reflect upon the quality of the development process and identify potential improvements to the process. It is then possible to improve upon the development process itself.

The business coach uses this model. Once the business coach discovers that an iteration of learning reveils no additional information, they should stop. Learning may continue if additional information is presented that causes their current business model to fail.

Business models are analagous to the physical models used to describe the real world. They are only valid until they are disproved. Also the models are only valid in the context of that that they describe. Business models do not translate between contexts / domains.

Agile Business Coach V Waterfall Business Analyst

This Blog entry highlights the differences between an Agile Business Coach and a Waterfall Business Analyst

Deliverables

ABC: Trained developer and the trust of the business users.

WBA: Analysis documentation

Focus

ABC: Learning

WBA: Documentation

Models

ABC: Break the model

WBA: Create a model

Scope

ABC: Actively seeking changes to scope.

WBA: Controlling changes to scope.

Risk

ABC: Responds to risks. Actively seeks to resolve risk.

WBA: Identifies and records risks.

Certainty

ABC: Accepts uncertainty and manages it by leaving choices open.

WBA: Seeks certainty by restricting choice.

Models

ABC: A business model, successful conditions, failed conditions and bad smells (possible risks).

WBA: A business model.

Choice

ABC: Leaves choices open until the last possible point.

WBA: Seeks to restrict choice at the earliest possible point.

Why Agilists think Up-Front Analysis is inherently un-Agile

Why Agilists think Up-Front Analysis is inherently un-Agile

Most people have the perception that the deliverable from the “analysis phase” is a set of “analysis” documents and artefacts. This perception is a result of waterfall practices. For Waterfall, the deliverable is an analysis document. Waterfall methodologies believe that the status of a project can be determined from these interim deliverables. The main reason is that they are tangible and can be measured by “thud factor” and the complexity of their contents. The analysis documents do not show what is unknown about the project, that is, the true risks associated with the project. The analysis documents also state the requirements as absolute that makes them difficult to challenge by the development team. Users place undue confidence in the documents because so much effort has been placed in them. Business Analysts in Waterfall methodologies invest significant effort in the documents because they are the visible means by which they will be judged. Business users, project managers and business analysts all focus on the documentation which causes a reinforcing sprial. Huge amounts of effort are placed in making sure the last T is crossed and I is dotted. None of this effort makes its way into the final software. The end result is that business analysts spend a majority of their time on creating documentation rather than performing analysis, that is, learning about the problem.

Agilists see the Analyst role as creating documentation. This is because Waterfall Business Analysts spend the majority of their time creating documentation. They do not see real value activity that is learning about the problem.

Agile Analysis

Agile analysis focuses on the learning of a business problem, reflecting the knowledge to the business user, and then transferring that knowledge to the development team. The Agile Business Coach’s deliverable is a developer trained in the business problem, and the trust of the business user that they fully understand the problem. The only measure of success is software that the business users can use to release business value. Focusing on a proper measure of success de-emphasises the interim analysis documentation. In fact, the Agile Business Coach aims to prepare no up-front analysis documentation. (Zero Documentation) The only documentation they prepare is to record their knowledge. They will generate documentation as part of the learning / analysis process. None of this documentation should be regarded as a deliverable.

Anyone who has attempted to write an article for general distribution will appreciate that it requires several orders of magnitude more effort to write the ideas down than it does to explain it to someone face to face. Agile Business Coaches aim to coach developers in the business problem using reflective teaching practices rather than leave the transfer of knowledge to documentation. This reduces the amount of effort required to transfer the knowledge by several orders of magnitude. The saved effort can be spent on learning and building relationships which are much more benefitial to a project.

I ran an experiment with the last three business analysts, Tim, Kevin and Senela when they started working with me. I spent between 10 and 20 minutes training them in the business rules relating to the credit risk associated with selling a commodity. In Kevin’s case, he had no previous experience of credit risk concepts or commodities. I then gave them a 40 page specification of the same rules and asked them to tell me if it contained the same information I had given them. The specification was one of the better ones I have seen. After a few hours they came back to tell me that the document did not explain the same idea, and that there were several mistakes in it. The document had taken at least 4 weeks to prepare.

Is there a place for up-front analysis in Agile?

Is there a place for up-front analysis in Agile?

The answer is “Yes”, but there is no place for up-front documentation.

Dan North at ThoughtWorks recently asked “Is up-front analysis inherently un-Agile ?” My short answer was “No.” but producing up-front analysis documentation is un-Agile. A better question is “Is there a place for up-front analysis in Agile?”

This article is my answer to this question. It explains the benefit of analysis in an Agile methodology. It explores why many people with experience of Waterfall methodologies believe that up-front analysis is inherently un-Agile. Finally, the article investigates the differences between analysis in a Waterfall and Agile Methodology.

Analysis is Learning.

Analysis is learning about a problem. Learning about a problem before you start is a sensible risk mitigation tool. Starting to develop a solution before you understand the problem is a very risky approach, which may result in the right solution being developed for the wrong problem. The amount of learning depends on the risk appetite of the sponsor, the criticality of the system, the complexity of the problem and your starting level of knowledge about the problem.

The learning is not limited to the business coach. In fact, the business coach’s role is to act a knowledge agent to cause business people and developers to learn more about the problem.

I worked on a risk project for a trading organisation where a number of people focused on the system as the solution. We set about learning about the real problem. In order for the system to work, it had certain requirements that were not initially understood. Also, the solution involved changes to several other systems, business processes, the culture of the organisation and the reward structure for key people in the organisation.

The Agile Business Coach regards the traditional analysis tools such as object modelling as learning tools. They allow the Agile Business Coach to identify areas of their knowledge that are incomplete. They create “bad smells” about an area of their understanding. The Business Coach can then focus their investigations in the areas of the “bad smell”. The Business Coach attempts to break any model of the business that they create rather than prove that it works. At the end of the analysis, their “model” will consist of a model, a set of business conditions that are met by the model, a set of conditions that the model failed to capture, and a few “bad smells”. It is probable that the “model” is not documented in the traditional sense other than in rough notes. The Business Coach should understand the problem though and the issues and risks surrounding it.

The issues and risks represent the uncertainty about the problem. The uncertainty is represented by the business conditions that fail the model, and the “bad smells”. The biggest risk to a project is the one that no-one knows about. The business coach should make the sponsor aware of all the possible risks. Risks can result in unexpected delays or the software failing to deliver business value. The significance of a risk is a factor of it likelihood and its impact. The likelihood should be expressed as a probability and the impact as either a cost or a delay, which can also be expressed as a cost. Ranking risks as high, medium or low has little use other than to prioritise them. Most risks that cause projects to fail are either not identified in advance, or ignored because they are misunderstood or are felt to be out of the control of the project.

The risk appetite of the Sponsor will determine how much learning (analysis) is performed on the problem before the development starts. Someone’s risk appetite is an indication of how much risk they are prepared to accept. People may have different risk appetites for different activities. Someone with a high risk appetite might be prepared to take risks at work that may result in them losing their job. Other people might take very few risks in their job but take huge risks in their hobbies and personnel life. The risk appetite of the sponsor will be affected by the level of trust they have in the business coach. If they trust the business coach, they will seek their advice as to when to proceed. If they do not trust the business coach, they might demand further investigation of the problem.

The key information that a sponsors needs to determine whether to progress is the impact of those business conditions that do not satisfy the models and how bad the smells are. The business coach should give the sponsor guidance on whether they feel the work should continue.

The criticallity of the problem will determine how much up-front analysis might be performed. The only true test of any software is how it performs in a production environment. Any activity to learn about the problem before this point could be regarded as analysis or learning, including user acceptance testing. In some cases, projects are restarted as a result of a failure during User Acceptance Testing. All the previous development can be considered as learning about the problem, i.e. Analysis. This is why some projects such as Chrysler’s C3 project can be regarded as having a significant amount of up-front learning or analysis. If the project is not critical, such as an internal web-site, it may be possible to start it with very little analysis. If the project is critical to the success of the organisation or if failure would result in the loss of life, much more analysis / learning is needed before it is used in a production setting.

The complexity of a problem may affect the amount of up-front analysis or learning required. Simple problems require very little understanding but complex business problems can require significant effort to understand the real problem.

Obviously, previous experience in a domain will have an impact on the amount of learning they need to understand a problem. Someone with a lot of experience should be able to pick up a problem quicker than someone with little experience. This is not allways the case though and sometimes a person with a different perspective may be able to identify the true problem quicker than someone who is too close to it. It is important for a business coach to have reflective learning skills. Their advantage is not their domain knowledge but rather their ability to learn new things and leverage their existing knowledge.

Zero Documentation II

The point of "zero documentation" is to build the knowledge in the minds of the developers and business users rather than focus on creating a document that may well not be used.

Documentation should be created if it is going to be used. It should be created on demand rather than in advance of a request.

Effort should be spent coaching and training developers and users rather than on writing documents.

As an experiment, on my current project I spent 20 minutes explaining how a set of business rules worked to three people on different occasions. I then gave them a 40 page document that was meant to explain the same rules. After four hours each they came back and said that:

1. The document did not clearly explain the rules.
2. They had found a number of errors and omissions in the document.

The document had taken a couple of months to prepare. I had explained the rules in 20 minutes because I had focused on coaching rather than writing a document.

The business coach may have a lot of documentation that they use to remember information but it is for their own persistent store. As such they do not need to spend much time working on it.

Zero Documentation

Our approach is to deliver zero documentation.

Learning about a subject results in documentation such as business models or state models. Zero documentation regards this material as the internal persistent store of the business coach. They know how to access the knowledge in the documentation ans can do so to refresh their memory. Other people (developers, business users) may ask for the documentation but it is not created for them.

Plug for Alias Sketchbook as Business Coach Tool

I have been using Alias Sketchbook on a Tablet PC to draw my analysis diagrams.

Hand drawn diagrams give the reader a feel for the completeness of the diagram. They help prevent developers from using model driven development without understanding the business model.

Tell a Story

I intend to publish a cleaned up version of this when I find a magazine to publish it in.

“They blew up the Death Star!”

Is this a good thing? Did the good guys win?

A story’s ending has little value unless the listener understands the context. “The Usual Suspects” start with the ending and then builds the context. Telling a story provides context for the ending and should generate interest for the listener so that they care about the out come. When you listen to a story, you can imagine how you would alter the outcome by making a different decision at a key point “Why didn’t Romeo wait five minutes?” The same rules apply to presenting the results of learning.

When presenting the results of learning (analysis), people have a tendency to present the final results and omit the story that built up to the result. This approach makes it difficult for the person being presented with the results to understand the context for the final results. Even worse, it makes it very difficult for someone to provide feedback. The learner often feels frustrated because the person they are transferring the knowledge to does not care about the results as much as they do. The listener often ignores the results and goes back to the original source in effect building their own story.

To illustrate this I would like to tell a story.

A colleague, Rohit Darji, and I were working on a risk system for an investment bank’s trading division. We needed to calculate the risk numbers for various levels of the organization. A separate project was developing a common system to manage the organization structure for risk, management accounting and performance management systems. The business manager on the project had a bit of experience with modeling databases and had created the model shown below.

We spoke to another business user who added an extra couple of management levels to the model. They also told us a couple of the problems with the current model “Its not flexible enough. Management often reorganize which means levels are added or removed depending on which way the political wind is blowing.” And “It does not handle joint ventures where two groups share the profit and risk on an initiative” We updated the model as shown.

From experience on a previous project, I knew that there were a few problems with the model. The first problem we addressed was the ”Account”. The business users with the hardest problem to solve were the management accounting group. They have to reconcile the trader’s view of the organization with the general ledger, that is, the financial accountants’ view. They explained that each trader had a number of books that could be split across legal entities for a number of reasons. The organization had a number of legal entities for a variety of reasons including regulatory constraints, tax and so that it could trade with counterparts using an entity registered in the same country as the counterpart. The traders expect to see a view of their profit and loss ignoring the legal entities, and the financial accountants want to see it by Legal entity. The management accountants told us that each department had a general Ledger account in each legal entity. The tricky part for them was to ensure the trades in the book were posted to the correct profit centre. We redrew the model including the concept of a “portfolio”. A portfolio identified which legal entity a trade was in.

Next, we decided to tackle the flexibility problem. Two “pigs’ ears fixed the problem. We kept the group as the entity that included everything, namely all legal entities and all management units. The group would be the root of the organization structure tree.

Finally, We addressed the joint venture issue. We asked the management accountants “Is there a single line on the general ledger for a joint venture or does each participant in a joint venture have its own line. Their reply “Each participant has its own line, and by the way, the risk and profit are split in different proportions.” The first part meant that the JV was below the department, and the second part meant that there was an allocation type associated with the allocation. Our final model looked as follows:

We had developed the model using Visio. We went over the model with all the business users including the business manager explaining how it would support all of our requirements. They nodded and smiled. We handed our model to Steve, the developer, who quickly implemented the model using 4 classes. The System handled all of the problems that I had encountered on previous projects. We moved on to our next project feeling we had done a good job.

We had spent about 2 hours on the modelling and a 8 hours getting buy-in from the business. Our approach was “They blew up the Death Star.” We did not take them through the story of how we came to our final model. We just presented the final model.

Three months later, the business manager on the project called us to say there was a problem. We attended a hastily arranged meeting to discuss it. The system could not handle the reporting requirements of the traders. We asked what had happened.
“The traders want to see their Profit across Legal Entities and the system does not support it.” We were confused. We had specifically addressed this requirement with the model, in fact, it was the first change we had made to his model. We had checked the system to ensure the data could be entered. “The system should support it look” we said. We took out our final version of the model and explained how it would support the requirement. The business manager took out his model that he had given to us at the start of the project. “I entered the data based on my model. I could not see how your model would work. For Example, what would the user see?”

I sketched the following screen layout on a flip chart.

“ Yes, that’s the screen we built for the users. But how would the user see the results for a single legal entity or for all legal entities?”

I added a drop down box to allow the user to select either a single legal entity or “All” legal entities.

The colour drained from the Business Managers face. “I could not see how it would work so ignored your model and stayed with my own.”
“Can it be rectified?”
“No. It took 2 months to set up the data and we have gone live in production.”

On my fourth attempt at creating an organization structure data system, we had solved most of the problems with the software. But we had failed because we had failed to explain to the business manager why we had changed his model. We had told them the final result without explaining why we had come up with the model. We should have told the Business Manager a story rather than “They blew up the Death Star”

Celebrate Failure !

Celebrate failure. Most projects are so dysfunctional that they continue even when they know they have failed. This is so pervasive that people will avoid turning over stones in case they discover problems.

My current project was a classic case of ignore anything that might mean failing to follow the plan. Any possible problem or bad smell was buried deep.

We started a rival analysis project. Instead of ignoring problems, we celebrated breaking our model. Any time anyone found a problem with our model, we bought them a bottle of champagne. Very soon, everyone on the project was trying to break the business model. It may have cost us a couple of cases of champagne but it meant we had a much more robust business model. Not only that but we started to have fun and celebrate failure.

In other words, we failed fast to win early. (This is a phrase coined by David Spann of Westminster College at The Agile Conference in Salt Lake City, 2003 )

Agile Business Coach Principles

These are the work in progess principles of the Agile Business Coach

Principles

The Agile Business Coach role is based on a number of principles. They are listed below. Grouped into the categories of Why, What and How.

The first thing we established is Why do we have a Business Coach. We then established What the Business Coach should deliver. Then we focused on How. Finally we specified what the role does not do that the traditional business analyst might do.

Our original articles were about What and How. The Why is the most important question of all.

Why do we need a Business Coach?

1. To coach the Business in how to identify and model business value and ensure that it is linked to the strategy of the organisation.
2. To coach the Business and IT Team to ensure the frequent delivery of Business Value.
3. To find information about the project before it would naturally emerge. The Business Coach is a project risk management tool.

What does Business Coach do?

1. They establish a trusted relationship between the business and the IT Team.
2. They coach the business and IT Team in how to identify and release Business Value.
3. They seek to remove waste. (The Business Coach is a Muda evangelist).
4. Focus on finding possible problems that might affect current decisions.
5. They extract themselves from the project as soon as possible leaving behind knowledge and trusted relationships.

How does the Business Coach achieve this?

1. By acting as a knowledge agent.
2. By learning about the business.
3. By coaching the business and IT Team.
4. By delivering zero documentation.
5. By providing barely sufficient deliverables.
6. By setting the project up for success. This is done by getting the business users to specify the expected test results that can be automated before the solution is developed.
7. By working in pairs on all thinking activities.
8. By attempting to break models rather than proving them.
9. By actively pushing knowledge and seeking feedback as confirmation.
10. By creating knowledge (trained people) rather than information Documentation.
11. By seeking negative rather than positive feedback.
12. By eliminating batches anywhere they are to be found.
13. By specify the scope of a project by what business value is AND is not to be delivered.
14. By focusing effort scoping the edge of the project rather than the middle.
15. By using whatever tool works.
16. By reflecting on progress and review the approach on a continual basis.
17. By refusing to deliver anything that does not reault in the delivery of business value.

What a business coach assists with but does not do (and who should do it):

1. Estimate effort. (Developers)
2. Identify Constraints and Takt Time. (Project Manager)
3. Write user acceptance tests. (Business Users)
4. Write system tests. (The IT Team, namely architects, designers and developers)
5. Run system or user acceptance tests. (Testing Team).
6. Track progress against the plan. (Project Manager).
7. Report Progress. (Program Manager)
8. Buy the pizza. (Project Manager)

Lean IT Processes

The Blueprint for Lean IT Processes are a Lean / Just in Time Manufacturing Process.

The implications for IT architecture are:

1. Single Piece Flow.

a. A messaging architecture facilitates single piece flow.
b. Messages should be published as soon as they are available. No batch processes holding up messages.

2. Standard Parts to reduce complexity of process.

a. The Producer (Publisher) and the Consumer (Subscriber) should agree the specification of standard parts. A single process cannot specify a standard. All publishers and subscribers should agree the Common Messages critical features (Shape, Objects, Relationships).

3. No Batches.

a. No overnight batch processes. Assemble the parts when they arrive and pass them on to the next process. Do not assemble in batches.

4. No redundent Processes

a. Do not paint something before you know what colour the customer wants. Paint the part when needed, do not paint everything a common colour. Mapping of Cross Reference data should occur in the Subscribers.

5. Pull.

a. Build components on demand of the customer.
b. Combine standard parts just prior to the process that needs them assembled. Not before.

6. No Inventory.

a. No components (data warehouses, systems, functions) built in case someone might need it.

7. Do not pre-assemble parts. (No redundant processes).

a. This creates inventory of part assembled parts. These parts may need to be de-assembled into constituent parts to be used to assemble a separate product. Double muda!

8. Fix failures immediately otherwise flow is interrupted.

a. Monitor the entire process for failure on a real time basis. A single process to reconcile all sytems on a real time basis. Fix exceptions immediately. A realtime reconciliation system is required.

9. Focus on the Goal

a. Only measure of success is Business Value, i.e.
i. Protect / Increase P&L
ii. Protect / Increase ROI
iii. Improve / Protect Cash-Flow

b. Ensure localised performance measures do not focus on wrong goal.
c. Optimise the delivery of business value, not the local process.
d.Management by Constraint. Identify bottlenecks and plan around them to achieve flow.

Zero documentation Explained

"Zero Documentation" means creating knowledge within the minds of the business and development team rather than information in documents. The Agile Business Coach does not aim to create any traditional documentation. Hence "Zero Documentation".

In reality, the Agile Business Coach will coach the creation of various artifacts. For example on my current project we have created a context diagram, a "To Be" set of business processes, interface specs and a set of User Acceptance Tests to be fed into FIT. ( Senior business users have commited to spending significant time to creating the automated user acceptance tests as their requirements. Note that it is the business, and not the ABC who is creating the expected results. The ABC is simply facilitating the process. ).

When presenting any information, we start with a blank sheet of paper / whiteboard and build up the story. We do not present finished artifacts as this tends to discourage negative feedback. (I'll do a Blog on telling a story later.)

Why UML is Bad (for Business Analysis.)

UML is a bad tool for Business Analysis.

These are following reasons:-

1. UML, the L stands for language, i.e. for communication, however it is a specialised IT language. The business users do not know the language, or the developers (they are struggling to understand the 5000 classes in Java).You will never get the end users to learn UML or any IT looking design language. So there is always the error of translation without a feedback loop to the user. I have often heard users say "Don't show me boxes."

2. UML gets in the way of Test Driven Development. Creating a system so that it can be automatically tested has a big impact on the design of that system.

3. The users understand expected results. On my current project, the business have stated a hard requirement that they want automated User Acceptance Tests. They want the confidence that they can change the system in the future without breaking it. The users, all senior business people, have commited to completing Excel spreasheets (to be used with FIT) that contain all the expected results that will specify the acceptance criteria for the software. They will do this ahead of the development. The users will have real confidence in the system and they will be able to change it without laborious manual regression testing.

4. Modelling should have a purpose. We only created a business model (Simplified E-R / UML object model hybrid) in order to identify the interface requirements for the system (60 interfaces so best to try and reduce the number of iterations. We will throw the business model away or let the developers use it if they are interested. It is certainly not being considered a deliverable as it would in RUP.

5. UML (and RUP) is prescriptive. XP hasn't really specified the form of analysis results. For our project, the "Analysis results" will be spreadsheets containing the expected results, interface specs and the business rules that the users will enter into a rules engine. We are also specifying the business value in Excel.

6. UML focuses on features and functionality. Agile (hence XP) should focus on business value (Note the arrogance ;-) ).

7. UML is only of use if all the developers know UML. In reality, the BAs will probably have the best knowledge of UML and the developers will miss some of the subtle nuances of the model. i.e. Too much detail in the model.

8. UML puts the BA and Designers between the Developers and the End Users. XP attempts to create direct dialogue between the Developers and the End Users. This means less chance errors creeping in due to the Chinese Whispers effect.

Metaphors and XP

XP introduced the idea of a single metaphor to create a common Vision for the project. The metaphor has proven to be the least successful of the XP practices. The concept is correct but its application is flawed. XP attempts to create a Single metaphor for the whole project. A metaphor should be created for each individual that the concept or model is being explained to. People from different backgrounds will need different metaphors. The metaphors can be reused but only for individuals with the same contest/background.

Metaphors are a powerful teaching tools. They are used in a large number of fields. The aim of a metaphor is to create a bridge of understanding : The person trying to explain a new idea or concept attempts to find a common frame of reference between themselves and the person they are explaining the idea to. They then explain the new idea using the common frame of reference .

XP attempts to find a single metaphor that works for everyone. This will not work.

The light dawned for me at the Agile Development Conference in Salt Lake City. I was explaining a concept to Hugh Robinson, Sanjiv Augustine and Russell Hill when I realized they both knew Smalltalk. Smalltalk uses a concept called model view controller. I explained my idea using the model view controller metaphor and was greeted with nods and smiles. They got the idea immediately. Armed with my new all powerful metaphor I attended the “documenting requirements ‘’session run by Pete McBreen .I launched into my explanation using the model view controller metaphor. Once again/was met with nods and smiles from everyone except one woman who looked blank and said “I do not understand what you are getting at.’’ She was a project manager and did not know Smalltalk. Without thinking, I asked her which industry she worked in. “Software for the construction industry‘’. I then drew the following diagram

…and explained that there is a single model but you create many views for different users of the software. The system presents a pictorial view for a customer, a gantt chart for the project manager and the quantities of material for the quantity surveyor. She got it straight away. I had created a metaphor using a context that the person I was explaining it could understand. XP should not try to create a single metaphor to explain the model of the project but rather use a number of them, creating new ones as required.

Review of Christopher Alexander's Timeless Way of Building.

Truly brilliant.

Read it, then buy it as Christmas presents for your friends and family.

It is more about Philosophy than Building or Architecture.

Draft of Business Value Stories

This is an early draft of stories used to explain Business Value. We might try to get them published. This is a very early draft. The "Tale of Two Stories" is two sets of stories. The first shows traditional approach and the second, the business value approach.

Business Value : A Tale of Two Stories

Gary works in the accounts receivable department of an Electricity Supplier. One day, he approaches his boss, Tom the CFO, with an idea.

Gary: “Tom, I reckon we can save $2m dollars a year on bad debts where customers go bankrupt.” said Gary.

Tom: “Sounds good. Tell me about it.”

Gary: “Last year, we lost $10m in bad debts. I reckon we could save 20% of that if we had a ChaseUp system to identify anyone more than 10 days overdue. I reckon it would cost $1m to build giving a net profit of $1m.”

Tom: “Go and ask Bob in IT to check your costs.”

Two days later, Gary and Bob meet with Tom to discuss the results.

Bob: “We can do it for three quarters of a million. There is a nice package just out from GrabITquick that should fit the bill.”

At this point, there are two scenarios. The traditional approach and the business value approach. In both, Bob would spend a couple of weeks gathering more information and putting it together into a more detailed estimate.

The Traditional Approach:

Tom: “Right Bob, sounds like it might be a winner, go and prepare a more detailed estimate. Lets present it to the board.”

Two weeks later, Gary and Bob present Gary’s idea and Bob’s estimates to the board. Bill the CEO starts the questioning.

Bill: “That sounds good. Bob, your numbers look good. What are the risks?”

Bob: “Main one is getting the right developers to integrate GrabITQuick into our existing accounts package. The job market’s quiet and there are lots of good people around, so I’m not too worried.”

Tom looks through the plan “Lets see, Software, Developers, Support, Training, erm, What about hardware?”.

Bob: “Ah, I forgot about that, we should add fifty “K” for a couple of linux servers.”

Bill: “Tom, what do you think of the savings?”

Tom: “Well Bill, Gary has worked in accounts for fifteen years and knows the business backwards. I’m confident they are right.”

Bill: “Lets go for it then!”

The Business Value Approach:

Tom: “Right Bob, sounds like it might be a winner, go and prepare a more detailed estimate. Lets present it to the board. Gary, take a look at this article from Cutter and prepare me a business value model.”

Two weeks later, Gary and Bob present Gary’s idea and Bob’s estimates to the board. Bill the CEO starts the questioning.

Bill: “Thanks guys. Bob, I think you might want to add something for hardware into your estimates. Gary, tell me about this model that Tom is so excited about.”

Gary: “Well, I read the cutter article and realised that you were about to spend one million dollars on my say so. This made me a little uncomfortable. Bob said he would be spending about 5 days on the estimates so I spent a similar time on the model.”

Gary: “I spoke to Debbie in the debt recovery department and told her about the idea. She suggested I speak to someone she knew in a local Business School about default models.”

Gary: “The business school were very helpful. My original model was very simplistic. Its obvious now, but there is probability of default for each grade of customer, not only that, but defaults cluster in certain years. In order to work out how much we would lose, we would need to run a simulation. One of their students put together a spreadsheet for me. They told me that I needed to find out the credit grades of each customer and the related probability of defaults, the exposure to each customer and our recovery rate for bad debts. Anyway the result showed that over a ten year period we have a 50% chance of losing $5m each year and a 10% chance of $50m without the GrabItAll software. We re-ran the simulation assuming a new recovery based on using the GrabItAll software. It showed that we would have a 50% chance of losing $4.5 million but a 10% chance of losing $20m.”

Bill: “I do not like the idea of running this model that a student built.”

Gary: “Its not as bad as it sounds. The student is on a year out from an investment bank. Also, the Business School were quite excited about it. Ten of their students and a professor spent two hours pulling the model apart before agreeing to it. So I’m fairly comfortable with it.”

Bill: “OK, but what are these default probabilities?”

Gary: “The default probabilities came from Moody’s and Standard and Poor’s. Both are well established rating agencies that are used by Wall Street.”

Bill: “Who gave you the recovery rates?”

Gary: “Debbie in accounts. However she said that she would need two additional staff to run the new process which would cost two hundred thousand a year. We put these numbers into our new model.”
Bill: “Well it sounds like the original idea doesn’t hold up. The saving is only five hundred thousand a year with a 50% probability. Tom, what about the other number?”

Tom: “I see what you are saying Bill. Fifty million lost revenue could seriously put us in jeodpardy with our Loan covenants. We will be fine with twenty million.”

Bill: “Great work Gary. OK everybody, lets do the project and focus on protecting ourselves from the fifty million loss. Lets make sure we get the 500 hundred thousand as well but it is secondary.”

Gary: “One other thing about the model”

Bill: “What’s that Gary.”

Gary: “We should update it everytime we find out new information, and we should re-evaluate it every month to find out if the conditions change. It should only take a couple of hours to update the spreadsheet. We should also re-evaluate the project decision every time the estimate goes up.”

Bill: “Sounds good. I’ll assume everything is fine unless you let me know otherwise.”

---------------------------------------------------------------------------------------

And there are many ways in which the model can be improved, or its results evolve. For example,
* If the credit worthiness of a company changes, its credit rating may be updated by the rating agencies.
* Credit card companies use different classifications to group customers in credit ratings. Rating agencies are only useful for large companies.
* Alternative sources of probability of default information exist such as the credit derivative market.

• Customers come and go….. and many many more.

Break it Down I
The stories now show the results of breaking the business value down rather than leaving it as a single value to be claimed by the whole project. Two stories.

Bob, Gary and Debbie meet to discuss the project plan.

Bob: “Gary, What is the most important feature?”

Gary: “We need to be able to track which customers have paid late and chase them up.”

Bob: “Right, we can install the GrabItAll software for you to start configuring as the first release. We will then build the interfaces between the accounts system and GrabItAll. Once we have the data in we will build the reports.”

Gary: “What about costs?”

Bob: “$300,000 for the GrabItAll license, $50,000 for hardware, $200,000 for the interfaces, $100,000 for reports, and $100,000 for training.”

Gary: “When will we be able to start using it?”

Bob: “Should be ready in 6 months time. But that assumes we have no problems or scope changes.”

Gary: “What about configuring the software? Who will do that?”

Bob: “Debbie needs to do that.”

Debbie: “Can’t I have a spreadsheet instead?”

Gary: “Not if you are going to keep track of one thousand outstanding debts at one time.”

Bob: “GrabItAll has a spreadsheet extractor but it will take about a month to set up.”

Gary: “Can we speed it up and cut the costs?”

Bob: “We could use the other workflow package we looked at but that would only save us about $100,000 on the license and we would have to spend an extra $50,000 to $100,000 to build an excel link because it does not come with one as standard.”

Gary: “Lets get on with it then.”

Break it Down II

Bob, Gary and Debbie meet to discuss the first iteration of the project.

Bob: “What should we do first?”

Gary: “As you know, Debbie and I have broken the business value down onto the following story cards.” Gary spread out four index cards.

Identify customers who are 1 day late with a payment. 35%
Future payment profile of late paying customers. 30%
Future payment profile of top 20 exposures. 20%
Workflow to chase up late payments. 15%

Bob: “Thats interesting, they do not match the costs. Look.” Bob added the costs to the stories.

Identify customers who are 1 day late with a payment. 35% $20,000
Future payment profile of late paying customers. 30% $40,000
Future payment profile of top 20 exposures. 20% $40,000
Workflow to chase up late payments. 15% $700,000

Bob: “Why has the work flow got such low value? I thought it was key.”

Debbie: “When we initially looked at the benefit it was based on recovering as much as possible. Our real benefit is to capture a few big exposures rather than lots of little exposures. My team can handle the workflow on a few exposures in a spreadsheet.”

Bob: “In that case, lets cancel any work on the GrabItAll system. We can solve the other problems with our existing system. We will give you a working version of the first story by the end of next week. We will review again then.”

Frequent Change

The true requirement of the business.

Bob, Debbie and Gary meet to discuss changes to the project.

Debbie: “I need a change to the automated ten days late letter. It currently prints the first and family name. I want to change it to title and then family name. Some of our customers have been getting upset with our “familiarity” on such a sensitive letter.”

Bob: “No problem, I’ll raise a change request.”

Debbie: “How long will that take?”

Bob: “Depends on priority. We currently have 6 months of changes already.”

Debbie: “Why not just make the change?”

Gary: “As you know, that’s what we did when we started. But every change seemed to break something that already worked. The consultant who reviewed the project suggested that we implement the change control process. It means we control the change at a rate that the test team can keep up with.”

Debbie: “Can’t you speed up the test team?”

Bob: “Only if you want a mistake like October to happen again. That’s why we insist on a full month of testing for each new release.”

Debbie: “Let me get this straight. The best way to prevent the system from breaking is to make it hard to change it.”

Bob: “No, we test it properly and make sure we focus on the most important new features using the monthly change control forum which you head up.”

Debbie: “I’ll stick it in at the top at the next change control forum. I cannot face another Monday of answering the phone and explaining why we are not a rude company to someone who sounds like my old maths teacher.”

Frequent Change II

Debbie calls Bob to discuss a problem.

Debbie: “I need a change to the automated ten days late letter. It currently prints the first and family name. I want to change it to title and then family name. Some of our customers have been getting upset with our “familiarity” on such a sensitive letter.”

Bob: “When do you need it by?”

Debbie: “Assuming its only a couple of days work, I would like it as soon as possible.”

Bob: “Can it wait until the next iteration?”

Debbie: “Sooner would better, we are getting a lot of complaints which is not good for the company or my sanity. If I have to listen to my old maths teacher one more time!”

Bob: “We had planned to deliver the next version next week. Do you want it sooner? You will need to check the new changes before we put it live.”

Debbie: “Sooner. Your automated testing stuff is great. We spent ages testing existing functionality at my last company. They called it regression testing. I called it agression testing. Bugs still got through as well.”

Bob: “They still get through, although they tend to be new ones. By the way, thank you for the support to get the budget for the automated test and build hardware. Its cut our build time down from 2 hours to ten minutes.”

Debbie: “No problem. Did you hear about Gary?”

Bob: “What’s he been up to in his new job?”

Debbie: “He got them to cancel the DragOn project. Apparently, even the outstanding costs were twice the real business value.”

Business Value Definition

An extract from our article on Business Value.

Business Value must be expressed in the language of the business. The language of the business is profit. As such, there is only one definition of Business Value for a Corporate IT department or Product Company:

• Increase or protect profit.
• Increase or protect Return on Investment.
• Improve cash flow.

One or more of the above should be increased although not at the expense of the others. For example, a project that delivers on time but results in staff leaving has reduced the assets (staff) and hence return on investment.

Increasing or protecting profit is achieved by:
* Increasing or protecting revenue
* Reducing costs

Many IT projects start without the business value being clearly articulated. As a result, it is difficult to determine whether they are a success from a business perspective. It is also difficult to decide when the project has completed. Business Value provides a simple measure for determining when to stop a project. Once the estimated cost of implementing additional software is greater than the expected business value released, the project should stop until additional value is discovered or the cost reduces.

Zero documentation and "The Timeless Way of Building".

In the Timeless Way of Building, Christopher Alexander states "Only in the fluidity of your mind can you concieve a whole." and "Each new pattern in the sequence transforms the whole design created by the previous designs.... it transforms it as a whole, it shakes it up, and realligns it.", then "This can only happen if the design is represented in an utterly fluid medium; it cannot happen in any medium where there is the slightest resistance to change. A drawing, even a rough drawing, is very rigid." [Pg 422].

This alligns with the Agile Business Coach practice of "Zero Documentation". No "documentation" should be produced. The system should live in the minds of the project members including the business and the developers. They may draw diagrams etc. to build the common picture but they should certainly not create version controlled documents that require a high level of effort to maintain.