October 29, 2003

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.

Posted by chrismatts at October 29, 2003 1:56 PM
Comments

About the only thing I would add is that the risk management process, identification, classification, and monitoring of risks, is more important than the actual outcome. "It is not the destination that makes the journey worthwhile."

That is why something as simple as a "Top 10 risks" list is so valuable. It only takes a little bit of time to create and a little time to maintain, but pays back tons more in the increased chances for project success/completion.

Posted by: Darrell at November 14, 2003 3:41 AM
Post a comment









Remember personal info?