Month: July 2013

Risk management and Impediments

When we manage projects with Agile concepts, we normally don’t give much weight to the traditional project management concept of Risk Management. Reason for this is in Agile terms we tend to deal the risks as they occur with impediments during the sprint itself. Besides when we develop software in an iterative manner, and delivering working software at the end of each sprint for the client, makes the possibility of risk considerably in a lower range.
Normally what I encourage the scrum master to maintain an impediment backlog for the sprint, where they have to clear the impediments during the sprint itself. By this way we are dealing with various risk as they occur. This doesn’t mean that we can ignore risk because we are unaware until the risk or the impediment occurs.
As Mike Cohn suggest in his article (Managing Risk on Agile Projects with the Risk Burndown Chart) I find it really easy and it is an effective way of dealing with risk in Agile projects. We normally spend time during the sprint planning meeting to identify any possible risk that could occur, such as technical difficulties that could occur during implementation of certain user stories, setting up server instances for development purposes, or it could be issues with shared resources being not available, such as system administrators, database administrators, etc. One major risk that we need to tackle is to provide requirement clarifications as soon as possible. Failing to do so may result in on hold and incomplete user stories by the end of the sprint.


How do you estimate projects with fixed dead line and must have features using Agile.

This is a scenario where no project manager would like to be. It is in fact a bad dream. At the beginning you can’t predict the rate of bugs and rework together with the change requests. These critical items that have dramatic effects on the estimates you give. In this article I am going to discuss the best practices that Agile estimation provides for us to effectively deal with this type of projects. I will take an example application to describe this scenario.

The Project: Migrating all the manual work done by a legal firm to Office 365. Basically you need to move all the operations to the Office Cloud, because the particular firm doesn’t like to maintain hardware and the staff want to access to the critical information when they are in and out of the office. All the clerks uses laptops and the legal offices and lawyers use hand held mobile devices such as IPads and Android devices. The firm handles many clients daily and they need an effective way to collaborate and communicate. Technical consultant team provided the best solution with office 365 because it provide all the needs that the user wanted. They also wants to share information with all the legal officers and lawyers. According to the agreement there is a fine if we fail to deliver the project on time, there is a fine for each delayed date. Let’s say it is $1000.00 per day. So if we delay the project by 10 days, the fine would be $10000.00.