A risk management ode to project managers!

Father’s Day might be a holiday which is much newer than the project management profession itself, but let’s not miss the opportunity to celebrate the many ways in which project managers help their projects succeed through effective risk management.

F is for Failure Mode and Effect Analysis, which can be a mouthful to say,

A is for avoidance to hold critical risks at bay,

T is for risk transfer for which we’ll have to pay,

H is for human bias, which can stand in risk management’s way,

E is for expected monetary value analysis, which calculates outcomes come what may,

R is for reserves, which prevents realized risks from ruining our day,

S is for simulations like Monte Carlo for us to play,

D is for Delphi where estimators go to pray,

A is for assumptions which come in many shades of grey, and

Y is for yellow which our project dashboards should never display.

Happy Father’s Day to all!

 

Categories: Project Management | Tags: , | 1 Comment

Which compromises are making your agile transformation fragile?

Agile transformation is a long journey for large companies. Holding off on getting started until all the necessary enablers are in place for successful adoption means the valuable learning which comes through experimentation will be lost. During this formative time, teams will have to cope with constraints which hamper how far down the agile delivery continuum they can operate.

An inability to dedicate primary roles on teams is normal and it is reasonable to start an agile journey with this impediment. However, if nothing is done to address the underlying root causes such as a continued belief in the productivity benefits of multitasking or a lack of understanding of how much work can be done concurrently based on resource capacity then delays, the waste of context switching, and higher defect volume will persist.

Environment or technology constraints might prevent teams from completing all stages of delivery for work items. Phase-based life cycles supported the model of shared testing environments which could be booked by teams for specific periods of time. A shift to end-to-end testing throughout the life cycle will be hampered by a lack of dedicated environments. This forces teams to work in a “Scrum-fall” manner which prolongs launches and will increase the cost and schedule risks of delayed defect detection and resolution. The tactical fix might be to throw money at the problem by provisioning sufficient additional virtual or physical environments, but a more lasting solution might require a shift to a partial or full product/capability/value-stream focus from the current project-centric one.

A lack of high coverage automated testing is a common blocker for teams working with legacy applications. Without this, the cost of testing through the life cycle increases dramatically as does the likelihood of missing regression defects. Investments in developing full automation for an existing application are extremely costly and are rarely justified unless there is a significant backlog of enhancements to be delivered over long product lifetimes. But unless there is a real commitment to empower teams to automate test cases from the very first release for new applications, this situation will never improve.

Constraints and compromises are common when undertaking an agile transformation. But not addressing the underlying root causes will significantly impede the ability to achieve sustainable benefits.

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

Applying Lencioni’s Five Dysfunctions to agile teams

Patrick Lencioni’s book The Five Dysfunctions of a Team can help agile leads guide their team building efforts.

When team members feel afraid to express vulnerability or feel that any mistakes they make will be held against them, they will be much less likely to take educated risks, to challenge the status quo or to unleash their creativity towards achieving customer goals or overcoming hurdles. Lencioni correctly places this dysfunction at the very bottom of the pyramid as without psychological safety, delivery excellence is a mirage.

For team members who have never worked together before, trust is a fragile, slow growing crop which is easily destroyed by careless comments in early sprints. This is doubly true in corrosive corporate environments where the agile lead will need to expend greater effort to ensure that external stakeholders don’t destroy nascent trust.

But as trust begins to form, an unintended consequence might be that team members hesitate to engage in healthy conflict or to hold each other accountable. An overly cautious, politically correct team dynamic means that behavioral issues don’t get addressed and minor irritations can fester causing long term damage to team morale and productivity.

A fear of conflict can also encourage mediocre decision making. For example, designs will not incorporate the collective wisdom of the group but will instead reflect the least common denominator.

Ceremonies such as daily standups and retrospectives can provide good opportunities to identify these dysfunctions, but should an agile lead directly intervene in such situations?

If the agile lead takes too direct an approach to address this, the team’s journey towards self-discipline and self-management will slow down. In such cases, it might be better for the agile lead to act as a catalyst for bringing such issues into the open. Asking leading or thought provoking questions during retrospectives might cause one or more team members to become sufficiently uneasy that they are willing to slow down the journey to Abilene.

Without conflict and trust, commitment is superficial. If the majority of a team is willing to sign up for work items for their upcoming sprint, but one team member is uncomfortable and does not feel confident in voicing their concerns because of a fear of ridicule or coercion, they might resort to the passive-aggressive approach of appearing to support the sprint goals but not really committing to them.

When team members look at themselves as individuals and give higher priority to their ambitions, egos and agendas, they will focus on completing their own tasks rather than tackling what’s best for the team as a whole. Corporate cultures which reward individual instead of team performance encourage such behavior. Standups and retrospectives can provide evidence of the inattention to team results and the agile lead will want to reinforce the importance of collective ownership.

Understanding and addressing the five dysfunctions of an agile team will help us realize the fifth principle of the Manifesto: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

 

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

Blog at WordPress.com.

%d bloggers like this: