Analysis tools should be learning tool.
Learning on a project should be directed to reduce risk.
Analysis should be directed at reducing risk.
Analysis tools should therefore focus on reducing risk.
Analysis tools should not be used for any purpose other than reducing risk.
Documenting what you already know does not reduce risk. Using analysis tools to document what you already know does not add any value to a project.
Analysis (Learning) should be barely sufficient. What does this mean?
As described earlier, an analyst uses a model to learn. They create a model and then test it. At any point, there will be a number of:
1. Known problems (issues) with the model that have not been solved. If an issue needs to be resolved before successful completion, leaving the issue unresolved is a risk.
2. A number of unknowns (risks) associated with the model.
Barely sufficient means that the risks associated with the project are understood and deemed acceptable by the risk owners of the projects. XP practitioners are risk takers and as a result are prepared to move ahead with almost no analysis (learning) about the business domain in the belief that they will be able to iterate quickly to the final solution. Their problem is convincing the real owners of the risk (the business) to allow them to proceed. Early business adopters of XP have been prepared to take on the additional business risk for two reasons:
1. They are natural risk takers.
2. The project has already failed and the downside of another attempt is not considered significant. i.e. Failure has been established as the standard against which they will be measured.
The decision to progress with known risks on a project is the responsibility of the ultimate holder of the risk. If the risk is a development risk, it is the responsibility of the development team. If the risk is a business risk (including requirements change), it is the business owner of the project that should take the risk.
If the development has been linked to the strategy of the organisation, changes to requirements should only occur due to a change in market conditions (external events), or a change in strategy. Linking an individual requirement (e.g. an XP Story or Use Case) is explained a future paper by the Agile Business Coach called "The road to Agile - Working Title".
XP and Agile are currently attempting to "Cross the Chasm".
The chasm can be defined according to the risk preferences of the market segments on either side of the chasm.
This means that the marketing message for XP and Agile needs to change to reflect the risk preferences of the participants in the "early majority" segment.
Courage was the right message for Entrepreneurs and Early Adopters who regard themselves as risk takers.
Courage is the wrong message for the Early Majority who are Risk Neutral and a negative message to the Late Majority who are risk averse.
XP says that developers should have courage. What is courage?
Courage is following a course of action when the level of knowledge and certainty are low, especially when it is anticipated that the outcome can have significant negative impact. i.e. Entering a project with a high level of risk and taking the personal responsibility for its delivery regardless.
Bravery is continuing with a task when the level of risk increases significantly to the extent that personal success is likely to be unlikely.
XP suggests that Test Driven Development allow a developer to act with courage. The developer will be able to change software without breaking it because the automated tests will identify any bugs entered into the software. This is not courage ! The risk of failure has been removed by the automated tests. It is the equivalent of a modern army attacking a primitive army on an open battlefield.
An army using automated weapons, tanks and helicopters against an army holding spears does not require bravery.
Telling clients that XP allows developers to act with courage (i.e. Accept high risk) is the wrong message. The developer almost never takes on the true risk of failure. When a client hears "I am prepared to take on more risk than anyone else", they mentally add "at my expense". The client imagines a bunch of loose cannons and cowboys tiliting at windmills.
Telling clients that (Automated) Test Driven Development removes the risk of change to existing software creates a much more powerful message. I am a coward, but I will still win.
Who would you want on your side? A brave loose cannon, or a coward who guarantees delivery?
Modelling tools are learning tools. Kolb's circle of learning describes how adults (all people) learn.
Step 1. Concrete Experience. Something that works
Step 2. Reflect and Observe.
Step 3. Abstract and Generalise. Formulate a model to represent reality.
Step 4. Test the hypothesis.
Circle back to Step 1.
In order to learn, the Analyst attempts to model reality. They then test the model. The most effective way to test a model is to try to break it rather than try to prove that it works. Therefore an analyst should focus on things they cannot explain, understand or things that they have a bad feeling about.
It is not always possible to prove a model works, especially models of reality. The model should be defined by the tests it passed, and those that it failed.
Testing a model as important as creating a model for the purpose of learning.
Pair modelling is more effective than analysis performed on its own because whilst one person is creating a model, the other person is testing it. This accellerates both participants around Kolb's circle of learning.
A traditional Business Analyst uses modelling tools to produce artifacts / documents that are used to communicate with software developers.
This is a fundamental misuse of modelling tools.
Using modelling techniques as a communication tool
Peter Senge describes an unstable (beer ordering) system in his book The Fifth Discipline.
I agree with his suggestion that the missing discipline is system thinking.
Once the connection to system thinking has been established it is a matter of determining the edge of the system, and then modelling it.
Peter Senge does not suggest modelling systems. It is a natural extension.
There are numerous techniques for modelling systems that can be applied to business processes. Business processes can be modelled as delays, feed back loops, and amplifiers. It should then be possible to use standard control techniques to determine the impact of various inputs to the system.
Techniques such as Bode Plots and Laplace can be used to understand the system.
For example, the "beer ordering" example in the Fifth Disipline describes the response you would expect from a Chebyshev filter when a step impulse is applied. Analsys of this system in the S-Plane could be used to determine the response.
Therefore, in determining the limits of a business process, one should identify all of the feedback loops that directly influence the behaviour of the system. This may be outside the organisation under analysis.
One of the aims of the Agile Business Coach is to develop true Agile practices that will disrupt the Business Analysis role. The traditional Business Analyst role will be replaced by the Business Coach.
It has been suggested that the Agile practices are being adopted by the "Early Majority", that is, they have "Crossed the Chasm".
A few of the more mainstream Agile practices such as eXtreme Programming (XP) have started to be adopted more widely, however the general Agile practices are still being developed.
Agile is a set of disruptive practices (technologies). The term "Disruptive technologies" was introduced by Clayton Christensen in "The Innovator's Dilemma".
Agile practices have a different value chain to traditional "Waterfall / Up frontist" methodologies. The consultancies that sell services to support the "Waterfall" methodologies are unlikely to be able to make a profit from Agile Practices. "Waterfall" consultancies rely on intelligent graduates at the bottom of the pyramid to turn the handle on their methodologies. Agile practices require that the bottom of the pyramid is staffed by highly motivated and experienced developers. Traditional consultancies will find it difficult to convert their business models. David Maister's "Managing the Professional Service Firm" explains how consultancy practices make profits for the senior partners.