LeadingAnswers: Leadership and Agile Project Management Blog

Agile Project Leadership and More on Accreditation

Last week I taught the “Agile Project Leadership” course with Sanjiv Augustine in Manchester, UK. The course went really well and we were looked after by Ian and Dot Tudor our hosts from TCC Training and Consultancy. They have a number of training facilities around the UK and ours was Aspen House, a converted church that retained all the arched doorways and high vaulted ceilings you would hope for.

It was a rare treat to teach in such nice surroundings and the church setting made evangelising agile all the more fun. In truth we were “preaching to the choir” as most of the delegates were already familiar with the benefits of agile and were looking for practical tools and more leadership techniques to move their organizations to the next level.

Agile Project Leadership Training Course

On February 4-5th I will be co-instructing with Sanjiv Augustine our new “Agile Project Leadership” training course in Manchester, UK. Sanjiv is the author of the excellent “Managing Agile Projects” book and fellow APLN board member.

This is a fast paced, practical focussed course that covers agile project management, leadership, and avoiding common agile project pitfalls.

You can find further details including a course outline at here.

Calgary APLN Planning Session

Last week we had the planning session for the 2007/2008 Calgary APLN Chapter. The goal was to create a prioritized list of topics to explore this season and demonstrate some of the values and practices of agile project leadership along the way.

We started by using the Speedboat game in small groups to identify impediments and propellers towards our goal of “Connecting, developing, and supporting great project leaders”. Speedboat is a group exercise for “Issue” and “Enabler” brainstorming that can be used with any group. It helps people to clarify goals, air their concerns, and suggest options for avoiding risks and moving forward. My colleague and co-host for the session, Janice Aston, wrote up these useful notes on using Speedboat and the outputs from the group.

Download Speed_Boat_Instructions.doc

Download Session_Results_10-17-07.doc

I previously wrote an account on Speedboat and other Innovation Games in an earlier post.

Following the Speedboat exercise we brainstormed presentation topics for the upcoming year. The thought process was: “Given the issues and enablers you just identified with agile leadership, what are the topics you would most like to see presented and discussed this year?”

Each group wrote ideas on sticky notes and we then posted them on the wall. Went through an affinity grouping exercise that sorted them into themed groups and removed duplicate suggestions. We all then went through a dot voting exercise where we assigned three votes among the topic suggestions. The topics and votes counts (shown in brackets) are shown below:

Agile Risk Management

Risk Management processes may have the air of a traditional, process-driven project management activity. However, agile methods are great risk reduction vehicles, and are actually very well aligned for rapid risk identification and reduction.

What is a Risk?
A risk is some event or circumstance that could transpire and impact the project. The PMBOK talks about good risks (opportunities), but most risk literature focuses on events with potential for negative impacts (project risks).

The risk management process outlined in the PMBOK is shown below:

Where’s the “Risk Response Doing” Step?
One step absent from this process is a “Risk Response Doing” step that focuses on executing the actions identified in the risk mitigation plan. In the defense of the PMBOK, these activities get moved to the project plan and scheduled with the regular work activities.

However the apparent lack of a doing step mirrors a problem seen on many projects. Namely, that risk management is undertaken as a separate (sometimes once only) passive activity that does not drive enough action on the project to prevent the risk happening. As a result we see risks occurring and can point to the risk list to where it was identified, yet not enough was done to prevent it happening.

Agile Exception Processes – What to do when bad stuff happens to good projects

When caught by a fire or other urgent situations it is useful to have emergency equipment on hand and know how to use it.  The same goes for Project Exception Processes, if something untoward happens then that is not the best time to be creating new processes to deal with the event and explaining how to use them. Emotions are high, people respond to bad news differently, and it is better to practice an agreed to procedure than figure out new rules.

Project tolerances and exception plans provide an agreed to emergency plan for when bad stuff happens to good projects. They act as guardrails to help prevent us going off track and provide a mutually understood and agreed to resolution process. So, just as during an emergency is not the best time to collaborate on improvising a rope ladder, nor is during a major project scope change the best time to define a resolution process between project stakeholders.

We will look at the two components (Tolerances and Exception Plans) individually and then examine how they work together. Project tolerances are the guardrails, the upper and lower boundaries the project stakeholders are willing to tolerate for a given project metric. Another way to think of it is how much slack rope we have as a project team to do our own thing (or hang our selves with). Tolerances can be set on a variety of metrics and the degree of variation will depend upon the individual risk tolerances of the collective stakeholders. Some projects might be very time critical, others more concerned with budget, or user satisfaction.

New Agile Project Leadership Training Course

In September I will be co-instructing with Sanjiv Augustine the new course “Agile Project Leadership”. Sanjiv is a fellow APLN board member and author of the excellent “Managing Agile Projects” book. I’m really excited because a) we have an excellent course that will stretch attendees while engaging them, and b) co-teaching with Sanjiv will be a blast since he is such a knowledgable and personable expert.

Our first course offering will be in Manchester, UK on September 10-11th. You can find further details including a course outline at Agile University here

The Top Five Software Project Risks

I recently posted an entry on a risk assessment tool you can download and use. Risk management (or more precisely risk avoidance) is a critical topic, but one that is often dull to read about and therefore neglected. One of the few useful and entertaining books on the subject is “Waltzing with Bears: Managing Risk on Software Projects” by Tom Demarco, Timothy Lister, authors of the ever popular “Peopleware”. This post provides a useful summary of their top 5 software project risks.

While not an agile focussed book, I find it interesting that of the top five software project risks identified in Waltzing with Bears, all have suggested solutions rooted in agile methods. Demarco and Lister rate the top five risks and their mitigation strategies as...

A Consistent Project Risk Assessment Tool

This post introduces a useful risk assessment tool you can download and use on your projects. While I created the spreadsheet formatting and presentation, the risk categories, questions and scores come from IEEE analysis of actual software project risks, so they have a reputable source.

The Risk Assessment Challenge
A problem with risk assessments is that risks are often relative to the observer. What might seem like an acceptable risk to you might be unacceptable to me. For many organizations it is difficult to get an objective view of their project risks across a portfolio of projects because different project managers have different risk thresholds. What a “Gung-ho” project manager rates as a “Medium Risk” project might actually be “Very High Risk” project to the majority of other project managers. Even more problematic, is when project risk assessments miss major categories of risks and are rated much lower risk than they should be. The risk profile tool I will introduce is a mechanism to help bring consistent risk assessments across an organization and ensure no major risk areas are omitted.

Smart Planning: Balancing Functional and Non-Functional Requirements

Agile projects prioritize requirements based on business value. There may seem like no business value in the non-functional requirements of Compatibility, Usability, or Reliability, but if the systems fails to deliver one or more of these “~ilities” then the system is a dead-duck delivering no business value whatsoever. (We may design and build the highest specification car on the planet, but if it only runs on unicorn sweat, needs three hands to drive it, or manages only 5 seconds between break-downs it is not useful.)

So, given that we do need to prioritize non-functional development alongside functional requirements, what mechanism do we use? One approach that business folks understand uses money as the prime driver. A fancy descriptor for the technique might be “Feature prioritization based on balancing predicted ROI against expected monetary value of risk mitigation” but let’s just call it “Smart Planning” for simplicity.

Creating Risk Profile Graphs

Risk management is an important activity on both traditional and agile projects. This article will introduce a method for quickly visualizing the risk status of a project and identifying risk trends.

A widely accepted definition of a risk is:

“A discreet occurrence that may affect the project for good or bad”

However, I prefer the less comprehensive, but higher impact statement:

“Today’s risks could be tomorrow’s problems”

We need to actively attack risks before they become problems on the project. Unfortunately, all too often risk analysis and risk management steps are conducted alongside the regular project tasks rather than being drivers for work scheduling. Risk management plans and risk lists are created, but their findings do not influence task selection and scheduling, then risks occur and people identify the issue “Oh look, risk #4 occurred”, but the risk mitigation steps had never made it into the project plan.

Agile projects have many opportunities to actively attack the risks on a project before they can become tomorrow’s problems. Iterative development allows high risk work to be tackled early in the lifecycle. Features (or stories) that carry high risk can be undertaken in early iterations to prove technology and remove doubts. Carefully balancing the delivery of business value and risk reduction is a wise strategy for feature selection that I will write more on shortly. Until then how do we illustrate the risks on our projects to all stakeholders?