Agile Business Coach

JBehave leaves the clever bits to people

JBehave leaves the clever bits to people.

Writing the acceptance criteria, scenarios, for a story is done by the business coach.

JBehave then translates these scenarios into empty JBehave classes.

The developer then writes the code within the JBehave classes.

Writing the scenarios for a story may require the Business Coach to work out the conversation that the system will have with the user and then break that down into the scenarios.

JBehave does not attempt to do anything clever and its for that reason that it is so useful. It does not attempt to generate the code for the application like model driven development tools. It leaves the clever bits to the business coach and developer.

What is Business Value Driven Development

Business Value Driven Development is essentially XP using Behaviour Driven Development with an explanation of where the Stories come from in the first place.

Business Value Driven Development

The diagram below shows Business Value Driven Development.

The starting point for any project should be the business strategy. We ensure allignment to the strategy by developing a business value model that is alligned to the strategy using the Grid Model and Market Maturity Model. The business value model should be barely sufficient. If you are doing a 5 man day project, a few minutes spent working out the numbers might be sufficient. If you are doing a $10 million project, then it might be appropriate to spend more than a few days on the model.

Once we know why we are building a system, we can work out a "to be" process. To develop the "to be" process, we may first map the "As Is" process. My preference is to draw these process models on white boards or by hand on paper rather than put them into visio or a case tool (spit). These process models should not be regarded as deliverables for the project but rather as muda that is a necessary evil to understand our requirements. If you are spending more than a few hours on these you are doing too much.

From the "to be" process and from our discussions with the business, we develop the master story list. Stories on the master story list take the Form "As an X, I want Y, so that Z." The Z comes from the business value model. The X and Y come from the process. The stories should be recorded on index cards. The master story list is actually a stack of cards.

At this point, we can use the master story list to produce estimates for the project.

The estimates combined with the output from the business value model can be combined to give the return on investment for the project.

The estimates and business value model outputs are fed into the risk matrix. After all, the risks are that the project costs more than the estimates and the business value is less than the model predicts.

A really useful exercise at this point is to bring an HCI specialist to develop the user experience from the master story list. i.e. What the application will look like from an end users perspective.

The next step is to specify the detail, the acceptance criteria, for the story. The business coach specifies the acceptance criteria in the form of JBehave scenarios. This is done for the candidate stories for the next iteration. The acceptance criteria are specified in the format

GIVEN a context ( a set of givens )
WHEN an event
THEN an outcome.

The developers can then perform a more detailed estimate for the stories.

As soon as your business sponsor has identified your highest priority stories for you first iteration, you can start development. You do not need to have a complete master story list before development starts. In fact, we expect to add and subtract stories from the lilst. Is there any choice other than XP for the development? The cards for the current iteration should be placed on some wall space so that all the team can see them and sign up for development.

The first step in the development is to generate the JBehave classes from the JBehave story.

The developer then uses Behaviour (Test) driven development to develop the stories.

At the end of each iteration the business decides whether it wants to implement the software in production. The software should be implemented as often as possible to prevent the build up of software inventory. The business should then measure to ensure the business value is released by the software.

Leaving ThoughtWorks

ThoughtWorks is still probably the best company in the world to work for.

I am leaving for personnal reasons. I was ill last year and feel that I need some certainty in my life. Working for consultancy means that you do not have certainty over where you will be working. ThoughtWorks have been brilliant. They have been supportive and understanding.

My advice, if you get the chance, work for them or work with them.

Resignation Haiku

Autumn wanes
I kick the leaves
And Leave ThoughtWorks
With fond memories.

I'm sad to be leaving ThoughtWorks. It truly is a special place full of wonderful, kind, uber smart people. I have learnt so much.

However I'm looking forward to starting my new job at BNP Paribas. Now it is time to put into practice all that I've learnt over the last two years.

What is a Business Coach

What does a business coach do?

In answering this question, I decided to reread Andy and my original paper on the agile business coach.

I agree with what we wrote a couple of years ago.

In defining the role, I would focus on the following.

The business coach should ensure that there is a business value model for the project. They should ensure that everyone on the project understands the business value model.

The business coach is responsible for the business domain knowledge of the development team. Their deliverable is a development team that understand the domain and the business problem. To do this they need to be able to be learn the domain quickly and then transfer that knowledge to the developers.

They need to establish effective trusted relationships between the development team and the business users.

The business coach should help to establish a ubiquitous domain language for the project.

In order to perform this role, the business coach must be a learner and a coach. They should understand the domain well enough to argue with domain experts. They should understand the issues faced by developers (hence my desire to understand OO). Finally, they should have the structured learning (analysis) skills that allow them to translate the vaque and fluffy business language into a precise domain language.

Narrative as a teaching aid

Tim Bacon found this paper that describes the use of narrative as a teaching aid.

Check here for my thoughts on the use of story telling to aid knowledge transfer.

There seems to be a resurgence of interest in story telling in the London Agile Community. I suspect that this is a result of Dave Snowden's presentation at XP Day 4.

JBehave Parser : Unimplemented Exception

I checked with Dan North. The JBehave parser is still outstanding. He will get round to it as soon as he gets some spare cycles. He is currently up to his eyes in work on his current consulting gig.

I will let everyone know as soon as he releases the code. In the meantime we would be grateful on any feedback on the stuff implemented so far.

The value of Feedback

One of the hardest things when you write is knowing whether you are putting your message across clearly or not.

That is why feedback, especially the type that clarifies a point is so important.

I would like to say a big thank you to Liz for persevering with me in my attempts to explain how JBehave works. Her questioning has hopefully made things clearer for other people as well.

JBehave

Liz asked about the link between behaviour classes and story classes. (Check out her Blog, she is way cool)

The behaviour class relates to an individual test. It is the equivalent of the unit test class.

For foo, there will be a foobehaviour class. This will contain the methods fooShouldDoSomething.

The story class is the equivalent to the user acceptance test. The Story class will contain given(s), an event and outcome(s). The given(s) set up the context and includes mocks etc. The event class calls the foo class which initially uses mocks. As the mocks are implemented, the mocks in the givens are replaced by the real classes. The behaviour classes however continue to use mocks.

The diagram below attempts to show this.

The outer most class in the app will have a call from the story class and the behaviour class. Classes within the app will only be called from the behaviour classes.

Separate Domain and Persistence Layer

Ade completed the example of a separate domain and persistence layer. It uses xstream for persistence.

Example below:

Repository example:

import junit.framework.TestCase;

import java.util.List;

public class DepartmentTest extends TestCase {
public void testAddedEmployeesCanBeListed() {
Department sales = new Department("Sales");
Employee johnSmith = new Employee("John Smith");
sales.add(johnSmith);
Employee janeSmith = new Employee("Jane Smith");
sales.add(janeSmith);

List employees = sales.getAllEmployees();
assertEquals(2, employees.size());
assertTrue(employees.contains(johnSmith));
assertTrue(employees.contains(janeSmith));
}

public void testEmployeeCanBeTransferredFromOneDepartmentToAnother() {
Department sales = new Department("Sales");
Employee johnSmith = new Employee("John Smith");
sales.add(johnSmith);

Department marketing = new Department("Marketing");
sales.transfer(marketing, johnSmith);

List marketingEmployees = marketing.getAllEmployees();
assertEquals(1, marketingEmployees.size());
assertTrue(marketingEmployees.contains(johnSmith));

//confirm john's left the sales dept
List salesEmployees = sales.getAllEmployees();
assertEquals(0, salesEmployees.size());
assertFalse(salesEmployees.contains(johnSmith));
}

public void testPersistedDepartmentCanBeRetrieved() {
String name = "Sales";
Department sales = new Department(name);
Employee johnSmith = new Employee("John Smith");
sales.add(johnSmith);
Employee janeSmith = new Employee("Jane Smith");
sales.add(janeSmith);

DepartmentRepository repository = new DepartmentRepository();
repository.add(sales);

Department retrievedSalesDept = repository.findByName(name);
assertEquals(sales, retrievedSalesDept);

List employees = retrievedSalesDept.getAllEmployees();
assertEquals(2, employees.size());
assertTrue(employees.contains(johnSmith));
assertTrue(employees.contains(janeSmith));
}
}

import com.thoughtworks.xstream.XStream;

import java.io.FileWriter;
import java.io.IOException;
import java.io.FileReader;
import java.io.FileNotFoundException;
import java.io.File;
import java.util.List;
import java.util.Iterator;
import java.util.ArrayList;

public class DepartmentRepository {
private static final String FILE_NAME = "departmentRepository.xml";
private XStream xstream;

public DepartmentRepository() {
this.xstream = new XStream();
}

public void add(Department dept) {
try {
List departments = getExistingDepartments();
departments.add(dept);
xstream.toXML(departments, new FileWriter("departmentRepository.xml"));
} catch (IOException e) {
e.printStackTrace();
}
}

private List getExistingDepartments() throws FileNotFoundException {
File file = new File(FILE_NAME);
if (file.exists()) {
return (List) xstream.fromXML(new FileReader(FILE_NAME));
}
return new ArrayList();
}

public Department findByName(String name) {
XStream xstream = new XStream();
try {
List departments = getExistingDepartments();
for (Iterator iterator = departments.iterator(); iterator.hasNext();) {
Department department = (Department) iterator.next();
if (department.getName().equals(name)) {
return department;
}
}
} catch (FileNotFoundException e) {
e.printStackTrace();
}

return null;
}
}
===================================

public class Employee {
private String name;

public Employee(String name) {
this.name = name;
}

public boolean equals(Object object) {
Employee other = (Employee) object;
return this.name.equals(other.name);
}
}
========================================

import java.util.ArrayList;
import java.util.List;

public class Department {
private String name;
private List employees;

public Department(String name) {
this.name = name;
this.employees = new ArrayList();
}

public void add(Employee employee) {
employees.add(employee);
}

public List getAllEmployees() {
return employees;
}

public void transfer(Department other, Employee employee) {
this.employees.remove(employee);
other.employees.add(employee);
}

public String getName() {
return name;
}

public boolean equals(Object object) {
Department other = (Department) object;
return this.name.equals(other.getName());
}
}

Five Dysfunctions of a Team

I just finished reading Ade's copy of "The FIVE Dysfunctions of a Team." It is a nice easy read in which it presents the five dysfunctions of a team funnilly enough.

The five dysfunctions are:

1. Absence of TRUST (Invulnerability)
which leads to
2. Fear of CONFLICT (Artificial Harmony)
which leads to
3. Lack of COMMITMENT (Ambiguity)
which leads to
4. Avoidance of ACCOUNTABILITY (Low standards)
which leads to
5. Inattention to RESULTS (Status and Ego)

It is a nice easy read with some practical tips for overcoming the dysfunctions. It was recommended to Ade by Tim Bacon.

Learning about Object Orientation

Eric Evans proposes that the domain layer and persistance layer for an application should be seperated. It should be possible for the business coach to read the code in the domain layer. Whilst this appealled, I struggled to understand how this would be implemented.

Ade Oshineye has helped me to understand how this would work by writing the following example. The department object is persisted in the DepartmentRepository class. This keeps the department object clean of any persistence code. Thanks Ade.

public void testPersistedDepartmentCanBeRetrieved()
{
String name = "Sales";
Department sales = new Department(name);
Employee johnSmith = new Employee("John Smith");
sales.add(johnSmith);
Employee janeSmith = new Employee("Jane Smith");
sales.add(janeSmith);

DepartmentRepository repository = new DepartmentRepository();
repository.add(sales);

Department retrievedSalesDept = repository.findByName(name);
assertEquals(sales, retrievedSalesDept);

List employees = retrievedSalesDept.findAllEmployees();
assertEquals(2, employees.size());
assertTrue(employees.contains(johnSmith));
assertTrue(employees.contains(janeSmith));
}

public class DepartmentRepository {
public void add(Department dept) {
// insert into dept values(name)
// int id = dept.getId();
// List employees = dept.getEmployees();
// insert into emp values(name, did)
}

public Department findByName(String name) {
// select from emp where emp.name = name
}
}

Business Value Pattern : Reduce Costs

I have started thinking about patterns for business value models. The most obvious is the "reduce costs" pattern.

There three general types of business value model. One for increasing revenue, one for protecting revenue, and one for reducing cost.

The reducing cost model probably follows the same pattern. It also is the one that needs the most careful investigation.

The first step for a reduces cost model is to identify the current costs. Consider a project to implement a new system to replace an old and inefficient system.

The costs will include:

Operational Staff Costs
Software Licenses
Hardware Costs
IT Support Staff Costs

Normally, the intention is to achieve the cost reduction by reducing operational staff costs through automating the process.

There are a number of things to consider with cost reduction business value models.

1. It is important to make sure that the cost reductions will actually occur. Often to reduce the opposition to change a company will say that no jobs will be lost when a new system is implemented.

2. Increased automation may result in an increase in the number of IT Support Staff required to support the system.

3. You should make sure that the cost savings you are aiming to achieve are real cost savings rather than "accounting" cost savings. A system may have an annual hardware cost due to the amortisation of the system costs over a number of years. The business value model may include a term to reduce the hardware costs. This is not a real saving as the hardware has already been paid for even though its cost is being spread out over a number of years.

JBehave

James Fisk asked "How do you get Jbhave to parse the story text in order to generate the classes ?"

Stories should be written in a particular format. JBehave will then parse this text and generate the classes for you.

The format is described here

James, does this answer your enquiry?

Dave Snowden

Willem Van Den Ende has done a nice summary of Dave Snowden's XP Day 4 keynote and paper.

Story Telling

I suggest the importance of story telling in my article about feedback. This article I found tells us that there are six stories we should be able to tell.

I. Who I Am Stories
II. Why I Am Here Stories
III. My Vision Story
IV. Teaching Stories
V. Values in Action Stories
VI. "I Know what you are Thinking" Stories

TOC Answer

Clarke Ching has answered my question about whether TOC is really as simple as the five steps. The answer is "YES", err and "No". Thanks Clarke.

TOC Answer

Clarke Ching has answered my question about whether TOC is really as simple as the five steps. The answer is "YES", err and "No".

Categorisation and Relationships

The Dave Snowden meme is still having a profound affect on the Agile Community following his involvement at XP Day 4.

Another Dave Snowden meme is to think about Categorisation and Relationships.

Which is the odd one out? A Cow, A Chicken or Grass.

Chances are you chose Grass. This is because you have chosen to categorise them according to your taxonomy of life. An equally valid choice is the Chicken because the Cow and Grass have a relationship with each other whereas the Chicken does not.

Dave suggested we should elevate relationships above categorisations.

When doing analysis (learning), it is important to consider both. Relationships are equally as important as categorisations. This means that my background in relational system design gives me an advantage.

Thinking about this, we should push this even further. Categorisations and Relationships are a static view of the world. We should also consider a dynamic view of the world where the categorisations and relationships change over time. We should also consider that for a particular context a different taxonomy should be used for used for the categorisation.

This different use of taxonomy explains the difference between the relational and object oriented paradigms. The relational paradigm uses a taxonomy that works on data. The object oriented paradigm works on a taxonomy of functionality (behaviour) and data.

I'm not sure where I'm going with this but I'll keep on mulling it over.

More than

Nice quote from Peter Brown at XTC last night.

We know more than we say.
We say more than we write.

Adds to the idea that communication should be face to face so that the receiver can find out more than the sender expects.

Theory of Constraints

Clarke Ching's excellent presentation on TOC at XP Day 4 is available here

I've spent the last week trying to understand the Theory of Constraints and how it might be applied to software development.

The Theory of Constraints approach to bottlenecks is:

1. Identify the constraint
2. Exploit the constraint
3. Subordinate everything else
4. Elevate the constraint
5. Go back to step 1

Is this all there is to it? I just bought and read David Anderson's book and that is all it seems to say. Clarke ?

Another excellent night at XTC

Another excellent night at XTC. A number of people were there including Tim Bacon, Steve Freeman, Martin Fowler and Peter Brown.

I confirmed my understand of Mock Roles with Steve. Steve, Joe, Nat and Tim's OOPSLA paper on Mock roles can be found here.

We had a good discussion on Object Orientation, with me confirming my new understanding from the ThoughtWorks Away Day.

We discussed object/business modelling and Peter mentioned that Dave Snowden had said that people place too much emphasis on the objects and not enough on relationships. Dave said that we should value relationships over categorisations. This is because a lot of people focus on the categorisation of information (the objects) rather than the relationships between them. I suggested that they should both be of equal importance.

Dave Snowden gave one of the keynotes at XP Day 4. He created quite a stir in the London Agile community. Rachel Davies Blogs about Dave's Cynefin.

Risk Management for Grown Ups

I presented a session on Risk Management for Grown Ups at the ThoughtWorks UK Away Day. This involves using real options to manage your risk.

I had some encouraging comments so I thought I would share the presentation with you.

Q1: First Off, why do we do projects?

A1: A project should deliver business value of X for a cost of Y.

Q2: What are the types of risks associated with a project.

A2: One, that the project costs more than estimated.
Two, that the project fails to deliver the business value specified in the business value model.
Three, a special case of two where the project damages the existing business model. i.e. It creates negative business value.

Q3: What is risk?

A3: Risk is uncertainty over an outcome. When you known something is going to happen with certainty, it is not a risk. When you are not sure about something, then its a risk

The current "best practice" approach to risk is as follows:

1. Identify the risk.
2. Record the risk in a risk register.
3. Assign a trigger to the risk to show when it kicks in.
4. Monitor the risks in the risk register.
5. Wait for the risk to materialise

Financial markets use options to manage risk. An option is the right but not the obligation to do something.

Real Options are the application of options theory from finance in project decision making.
A real option is any situation where you have the right but not the obligation to do something. You can use option theory from finance to value your option.

Real options allow you to defer decisions.

Financial mathematics tells you that it is never optimal to exercise an option earlier than necessary. This means decisions should be deferred to as late as possible but not later.

Real Options allow you to handle uncertainty in your IT project.

The option value is the loss incurred if the negative outcome occurs multiplied by the probability of it occurring.

1. Calculate the loss in the event of a negative outcome.
2. Estimate the probability of the event occurring.
3. Multiply the two numbers together to give the amount to spend on the option.

e.g. If the DBA is unavailable, the cost to the project is £10,000 per day for a month to hire a replacement. i.e. £200,000. The probability of the DBA being unavailable is 10%

The option to cover the risk that the DBA is unavailable is worth £20,000. This is the amount that you have available to spend to protect yourself against this risk.

Agile allows you to manage risk using Real Options.

Agile grants you the option, the right but not the obligation, to change the requirements at any point up to the last iteration. This allows you to manage the risk, the uncertainty, surrounding the requirements.

TDD grants you the option, the right but not the obligation, to change the design of the system at any point. This allows you to manage the risk, the uncertainty, surrounding the design’s ability to support the requirements.

Risk Management for Grown Ups.

1. Identify the risk.
2. Record the risk in a risk register.
3. Assign a trigger to the risk to show when it kicks in.
4. Identify an option to handle the undesired eventuality.
5. Value the option.
6. Invest the premium in the option.
7. Monitor the risk.

Interfaces II

The JBehave/Mock Roles processes use Interfaces as part of the design strategy.

1. Specify the next behaviour that a class should have.

e.g. The delivery van object shouldDeliverToMoreThanOneDestination.

2. Specify the interfaces that the object should talk to using Mock Objects.

3. Code the class.

4. Repeat 1-3 until all the behaviour that the object should have is specified.

5. Move onto the next object that implements one of the interfaces.

This is very different to the up front analysis and design that I have seen before. In up front analysis and design, you identify the objects and their relationships. You then specify the interface based on the object implementation rather than the other way round.

P.S. I'm well out of my depth here.

Interfaces

I never really got the point of interfaces in Java. That is because I assumed that you start with the object and then see the interfaces as a way of presenting views on the object. I often saw interfaces and objects that fall into the antipattern of

object fooImpl Implements foo

Joe pointed out that for a shop object, there should not be a shop interface, Rather, a delivery van object would use a destination interface, a bank object would use an account holder interface and a customer object would use a product supplier interface. Each of these three interfaces would be implemented using a shop object. An interface is a role that an object plays.

In terms of designing a system, the interfaces should be identified by the objects that use them. An object should then implement the interfaces. As a result I see that Mock Objects neatly support this design approach. It also supports the design process that JBehave encourages. I now realise what Joe and Nat have been talking about when they talk about Mock Roles

There is an analagy to lean manufacturing. Objects should "pull" functionality out of other objects using interfaces rather than objects pushing interfaces out based upon the functionality in the object that implements them. The interface comes first, the implementation object comes second. Thus the anti pattern

object fooImpl Implements foo

identifies where the interface is being pushed out the implementation object rather than pulled out of an object that needs it.

ThoughtWorks Away Day

ThoughtWorks UK had an Away Day on Saturday. This is a day where the whole UK practice gets together to share ideas. I organised it this time and I was lucky to have some excellent sessions to offer. I had a great time.

In the morning I attended a session on "Principles for the Agile Designer" by Joe Walnes and Nat Pryce. I learnt how interfaces should be used in OO design. In the afternoon I attended a session by Dan North on JBehave. Damian Guy and I provided support to Dan in his presentation. Roy, the CEO of Thoughtworks, sat in on the session and afterwards dragged some of the management team in to see JBehave. After the JBehave session, I went to a show and tell on Analysis tools. To end the day I gave a session entitled "Risk Management for Grown Ups." which applies Real Option theory to IT Project Risk Management.

There were seven tracks for the Away Day and most of the sessions were of high enough quality to be run at a conference. This reflects well on the depth and quality of the people in ThoughtWorks.

eXtreme Analysis

Olivier Lafontan gave a speech at XP Day on Business Value and an approach he calls eXtreme Analysis. Olivier has also started a Blog where he talks about business value and XP.