Risk Management for Agile Projects

This is the second article I translated for InfoQ.com. It is a challenging one because risk management itself is a very broad topic, and honestly I am not very good at it. Thus, I spend quite some time reading different articles, from the traditional to agile communities before I translated this article.

The very first thing about risk management is to understand what risk is. It is a very common misunderstanding where people mixed "risks" with "problems". "Problems" are certain to happen while risks involve probabilities. SEI provides a very good description on what risk is and what are not risks, and further divided into continuous risk and non continuous risk.

* Non-Risk, a certainty - it is a problem.

* Continuous Risk Management, risks are assessed continuously and used for decision-making in all phases of a project. Risks are carried forward and dealt with until they are resolved or they turn into problems and are handled as such.

* Non-Continuous Risk Management, risks are assessed only once during initial project planning.

SEI also provides a concrete (but heavyweight) continuous risk management framework. In the Agile world, the iterative nature of the project already provides a framework to manage risk. These activities include, daily standup meeting, sprint planning, release planning, and project retrospectives.

Michele Sliger proposed a structured approach for risk management. This includes the following steps:

Risk Identification - the whole team does this exercise on an iterative basis. The results are recorded on white boards or flip charts.

Risk Analysis - qualitative analysis using judgment, intuition, and experience in determining risks and potential losses. Short development cycles and constant reviews in Agile, make this feasible and effective. This is different from traditional projects where quantitative analysis is done and numbers are assigned to the damage which can occur.

Risk Response Planning - entire team participates in developing options and actions to reduce threats.

Risk Monitoring and Controlling - risk is monitored and controlling strategies are discussed at the end of each iteration. Risks are monitored on a daily basis too by using information radiators.

It is good to have a structural approach rather than thinking what to do when there is any potential risk. However, mandating such steps in each project would easily lead to wastes, especially if the team sees no risks ahead. So even with structural approach in place, it is down to the team/stakeholders to decide on whether to put this exercise in place.

Barry Bohem at USC proposed Incremental Commitment Model, where they have "risk driven anchor point milestones" to decide the next step:

* The project can proceed if project stakeholders think the risk level is acceptable.
* If the risk level is acceptable but risk management plan does not meet its needs, extend this part of work and review it afterward.
* If the risk level is low, and the project can proceed.
* Terminate the project if the risk level is too high.

I wish I could read and write on the Incremental Commitment Model very soon. It looks interesting because Barry Bohem has been developing software development models for very long time and ICM is one with the most Agile elements inside. I believe it is interesting to learn the mix between Agile and the heavyweight methodologies.

The second of the article discussed the responsibility of risk management. Although there seems to be different view existing, I think what Ron Jefferies said is correct. Product Owner is responsible for risk management since he/she is responsible for ROI.

It makes the issue clear to all the stakeholders. No one can deny or push the responsibility within the team when there is a clear candidate who should be responsible. More importantly, although PO is responsible, the team needs to assist him/her to achieve the goal. Being not responsible is not the reason for keep hands off completely.

Share with:

Barcamp 2008

barcamp Hong Kong 2008

(A great photo from Belle)

A photo worth a thousand words. With such a big crowd, it's enjoyable to meet new people and catch up with familiar faces.

Compared to the Barcamp 2007, this is more spacious and has better ventilation. With more time per session, speakers can cover their topic better (although it seems never enough).

There are three interesting topics I am impressed:

1) TCP window problems. (sorry I don't have links yet)

Presented by Yusuf Goolamabbas. It's short but sweet. There wasn't many people in this session as I expected for such a highly technical topic. However the speaker managed to speak on interesting issues about TCP window sizing problems. I sincerely look forward to any updates from him on his latency modeler.

2) Augmented Reality, by Ben Lau

The "Quake" and "Kung Fu" demo is particularly interesting. Besides the interesting demo, the cool thing is the way to interact with the system. I am always interested in human computer interaction. Opportunities are still open in this area.

Also, the interface has more human elements on it. This introduces challenges in testing, especially automated testing, or manual testing needs to be done.

3) Agile, by Conrad and Jenny from ThoughtWorks

This is a gentle introduction of Agile methodologies. I know that they prepare this in a very short time. They manage to do a good job in introducing the concept. The talk is yet fundamental but still encountered some questions:

- Conflicting requirements

Besides the more formal sessions I learned something new. The interesting part is always chatting with different people, knowing different things around our community.

Look forward to seeing Barcamp 2009!

Share with:

To manage a lazy team with a Burndown Chart???

Burndown Chart is a very common useful artifacts in Agile Software Development teams.

The main purpose of the Burndown chart is to keep track of the development progress and compare with what is planned at the beginning of the iteration.

However, this is not a mean to check if the team has (intentionally) selected less work than they are capable to complete.

Firstly, Burndown chart is not the artifact to blame the team for having "slow" progress. It is simply too late to realised that the delay existed where it showed no clue on why the delay existed.

Futhermore, if the team deliberately selected work that is less than they are capable of, the story points to finish in the "planned velocity" should also look "lower" than that if they planned to work in full speed. So, what would happen is the team is likely to finish the work they selected (since they should be more than capable to finish). The Burndown chart would then look very perfectly well. And this only leaves the PO obtaining small piece of done work by the end of the iteration. This is why Burndown chart is not the right artifact to check if the team selected less work than they are capable of.

Coping with a lazy team is a very often discussed topic in the Agile communities. I have basically two points on this:

  • Daily standup meeting - This is when each developer answers the question of what he/she did in the past 8 hours, what he/she plan to do in the coming 8 hours, and what are the obstacles he/she encountered.

    Product Owners are welcome to attend this meeting. This is an important way to build confidence with product owners and other project stakeholders that the team are fully committed in their work.

  • Questions - It is very true that ScrumMaster is not the person who dictate what the team does. I certainly don't expect a ScrumMaster could come out and say: "Hey, how come you signed up for that little work for the entire iteration?". However, ScrumMaster should ask questions when he/she notices something wrong.

    A team picking up sustainably less work than they should be capable of (in the sense of the ScrumMaster) is probably having some other problems behind. Asking questions could reveal more information what the team is thinking about the work they selected. This could be very fundamental reasons like they think they are working on something unfamiliar with; they could be under some other external pressure to avoid lagging behind in the Burndown chart; or simply some other authorities asked them to work on something else during that time.

It is very true that the ScrumMaster, nor the Product Owner, aren't dictating the team for how much work the team should complete in an iteration. Agile teams always rely on trust. At the same time, when it comes to the very worst scenario, the Product Owner always have the right to choose to finish the project after the end of the iteration as he/she has to be responsible for the ROI of the project.

Share with:

Use Cases or User Stories

This is the first article I translated for InfoQ. The topic is "Use Cases or User Stories"

There is often misunderstanding about the different artifacts and techniques as if one were replacing the other. "Use Cases or User Stories" is one of such question.

The other misunderstanding is even more fundamental, not understanding enough about the techniques in question.

Mike Cohn did a very good job in identifying the differences between the two techniques.

  • Scope and completeness, user story usually covers the main success scenario, while a use case covers the main success scenario plus acceptance tests.
  • Purpose and longevity, story cards are usually discarded after an iteration, while use case is good as a permanent artifacts for documentation.

Another good piece of work is from Scott Ambler, <Apply the Right Artifact>. It's not just about use case or user stories, but apply the right artifact in general. Besides the characteristics of the technique itself, it is also important to consider the context of the project, and the skill level of the team itself.

You can see my work here: Uses Cases or User Stories

Share with:


Welcome to my blog! I always want to record down things I learned. But I am always lazy. Having spent some time thinking what to write and discussed with my friends, I decided to open a new blog for this.

I have always been interested in software engineering, and realised that the current state of knowledge is far from enough for the problems we face in practice. I always like to read about different viewpoint of the problem and I always like to put my opinions on these issues. Until recently, I was invited to join InfoQ to translate and contribute articles. This blog comes into place for recording opinions I expressed and also things I read. I hope you also enjoy reading this. Please do kindly share your view too.


Share with: