Risk management for agile projects

riskbalanceWhat are the implications to project risk management when you choose to deliver a project using an agile approach?

Here are a few similarities:

Risk needs to be managed through the project’s lifetime, not just at the very beginning. Even though the team might tackle high risk requirements earlier in the life of an agile project than they might a traditional one, this doesn’t mean that they shouldn’t keep an eye on threats and opportunities through late stage iterations.

Risk bias and appetite need to be assessed when managing risks. How a team, risk owner or sponsor will identify or respond to risk is tied to their individual perceptions. Influencing stakeholders to ensure that risk gets effectively managed is a critical skill for both a project manager and a Scrum Master.

Multiple perspectives need to be considered when identifying risks. Risk is a many dimensioned thing – using a single checklist, consulting a single group of stakeholders or only focusing on one source of risks is likely to leave the project exposed to threats from multiple angles. Technology, operations, change and stakeholders are just some of the potential sources of risk which need to be evaluated.

And some differences:

Close involvement of customers and key control partners throughout the life of a project increases the likelihood of effectively identify and manage emergent risks. Unlike on a traditional project where certain stakeholders will only be present at the beginning and the end of a project, on an agile project, ongoing involvement through multiple iterations provides the opportunity to better incorporate multiple perspectives.

The impact of operational risks is likely lower as expected changes are correspondingly smaller but are likely to be more frequent. Rather than having one or two “big bang” releases which will result in significant changes in the procedures or behaviors for impacted stakeholders, agile projects will deliver change incrementally.

Planning ceremonies at the beginning of each iteration and retrospectives at the end provide the team with a regular opportunity to consider risk. While the use of a risk register is a good practice regardless of whether an agile or traditional approach is used, having a watch-list of key risks in the team war room or online collaboration site will help to keep the level of vigilance high.

Risk should be a key input into back log refinement. Requirements which are critical to achieving the business outcomes but contribute significant risk should be tackled early in the life of the project in support of the principle of failing fast. Those which are nice-to-haves but are very risky might be de-prioritized or eliminated to help reduce the project’s overall risk profile.

Risk management is an important discipline regardless of the approach taken to complete a project. But as with all PMBOK knowledge areas, how it is applied needs to be tailored to fit the context of a project, the maturity and culture of the team and the organization.



Categories: Agile, Project Management | Tags: , , | 1 Comment

Human Resources needs to be part of your company’s agile transformation!

"HUMAN RESOURCES" Tag Cloud (performance management process)When we think about the journey from traditional delivery approaches to agile, the focus is normally on delivery teams or on those areas of the organization which will need to transition from being project-focused to becoming product, capability or value-stream centric.

Human resources is a good example of an organizational function which you might not think would experience significant change.

For large companies which have defined job families and roles, agile might introduce new roles such as Scrum Masters, product owners or agile coaches. Not only will organizational design professionals have to develop the required competencies and accountabilities of such new roles, they’ll also need to design career transitions from other roles into and out of these.

In many markets, experienced agile coaches might be worth their weight in gold so compensation staff will need to identify what will be reasonable median salaries for such roles and then calculate the impact of potential compensation ripple effects on the feeder roles into such positions. This is critical, otherwise the effort spent hiring, onboarding or promoting staff into these roles will be wasted if compensation doesn’t reflect market realities. As with other hot skills, retention can be as challenging as procurement.

Companies are often organized into departments of distinct, specialized skills and performance measurement programs emphasize the individual instead of teams. Traditional recognition programs reward individual performance with team celebration or recognition getting short shrift when it comes to budgets.

Agile delivery flourishes when you have long lived teams of generalizing specialists who collaborate closely. The team, rather than any one team member is the lowest level of granularity when it comes to decision-making, commitment and performance.

What this implies is that people managers who might previously have discouraged their staff from straying outside the boundaries of their specific competencies or roles will need to alter their approach and HR will need to lead this charge on encouraging the right types of leadership behavior. Performance management processes will also need to evolve to emphasize an individual’s contribution towards team performance to incent the right type of behaviors from former primadonnas.

A successful agile transformation impacts all parts of a company, including those which are usually not directly involved with project delivery.





Categories: Agile, Facilitating Organization Change, Project Management | Tags: , , | 1 Comment

Don’t forget n*(n-1)/2 when scaling agile!

linesofcommunicationStudying for the PMP exam forces a candidate to relearn project management using a standardized nomenclature, to view the world of project management in black and white rather than the many shades of grey it is, and to memorize and to be able to apply a number of mathematical formulas.

One of the simple formulas we learn during our PMP study is n*(n-1)/2 which represents the total number of communication channels which can exist between a fixed number (n) of people who are working together towards a common goal. It informs us that this total number grows non-linearly as we increase the number of people involved.

But does this equation provide us with any value beyond mere academic interest?

Large project teams are common on traditional or waterfall-type projects. On such projects it is rare that team members need to interact regularly with everyone else on the team. But on agile projects we expect that core team members will collaborate closely on a daily basis.

Imagine a daily standup meeting with forty team members. Even if every team member remains disciplined about sticking to the standard “what I did yesterday, what I’m planning to work on today, what’s blocking me” script that would still result in a meeting which lasts closer to an hour than the expected quarter hour.

Iteration planning and retrospectives will start looking like dreaded meetings more than agile ceremonies, and you can forget about sizing a large number of user stories quickly!

With large project teams it is critical to decompose the project scope or solution design such that individual features or components can be delivered by right-sized teams of five to ten individuals. Of course, there is the need for some ongoing coordination between teams in a “team of teams” construct but with a thoughtful allocation of work items most communications will be isolated within each team.

Organizations using agile approaches to deliver their projects would do well to remember n*(n-1)/2!

Categories: Agile, Project Management | Tags: , , , , | 1 Comment

Blog at WordPress.com.

%d bloggers like this: