Easy in theory, difficult in practice

I'm seeing increased similarities between online hype surrounding agile and the marketing of weight loss products. Losing weight or being agile are being promoted as the main objective when both of these are just a means to an end.

We don't invest significant effort and cost just to lose weight. We want to feel better about ourselves, look slimmer for others or gain health benefits.

Similarly, agility should never be a goal until itself - we need to define what we are hoping to realize by achieving a higher level of agility.

This is an important distinction.

If our focus is purely on becoming more agile, it can cause leadership teams to define overly ambitious time frames for achieving certain objectives or demanding unrealistic levels of capability given their industry, culture or other context. This is similar to someone who doesn't attempt to connect their weight loss desires to specific achievable outcomes. Over time, this can cause the individual to engage in obsessive dieting behavior which might leave them worse off than before.

A traditional, multi-product large company undergoing an agile transformation should always aspire to reaching a higher level of capability, but it is doubtful that they will ever be as agile as a new, small startup. I enjoy playing golf and try to set achievable goals for myself each playing season but comparing myself to a PGA tour professional will demoralize me and eventually cause me to give up the game.

When managing projects, it is wise to understand what the relative priority of the constraints on a given project are. If a sponsor indicates that delivering on time is most important, then cost, scope, quality and other constraints could be subordinated to schedule.

With an agile transformation it may be advisable for the supporting leadership team to prioritize their objectives before getting started. Are they primarily focused on increasing customer value, is it about improving quality, cost containment or increasing the engagement and happiness of their team members? It can be very educational to have each senior executive rank a predefined list of such outcomes individually and then have the leadership team compare the differences in perception. This exercise might help to avoid misalignment issues at a later stage of the transformation.

If we don't know where we are going and why we want to get there, no road will take us there.

Although the PMBOK Guide has individual chapters covering key project management knowledge areas, it also highlights the importance in an approach which integrates these knowledge areas in a pragmatic, tailored manner to fit the needs of a specific project taking into consideration organizational and team culture.

One of the most common examples of poor integration across the knowledge areas occurs with risk management.  Risk management needs be tied at the hip with other project management practices, but too often it is as isolated as a porcupine at a balloon convention.

What do I mean by this?

Risk is the embodiment of the uncertainty which is inherent in the DNA of projects.  Until all agreed-to scope has been delivered and accepted, risk does not disappear so why do we not connect the dots by referencing it in other key project management artifacts?

It starts with the charter – while expressing the desired outcomes and drivers for the project, there should also be coverage of the key sources of risk which could impede the realization of these outcomes.

It continues with other core planning artifacts such as stakeholder analysis documents and organization change management (OCM) plans – risks from the register should be referenced in specific stakeholder management plans and should form part of the rationale supporting your OCM strategy.

Risk drives variation in outcomes and hence the cost and time contingencies reflected in cost estimates and schedules should link back to specific risks in the register.  Risk responses for high severity risks should show up as line items in the schedule and should have been baked into your baseline budget.

Project changes should directly tie back to items in the risk register – closed and open risks.  Some project changes may eliminate certain risks – this is why one of the ways to implement the risk avoidance response is to reduce scope.  Other changes might introduce a whole new set of risks.  A well maintained risk register should be able to provide a forensic trail of project change.

Issue logs should also show evidence of traceability to risks – when known unknowns are realized as issues, linking those back to the originally identified risks provides the opportunity to assess whether there is a future likelihood of occurrence and can provide valuable input into post-project assessment of risk management practice effectiveness.

All decisions need to consider risk – analysis leading up to a decision should consider the risks associated with each option, and risk register updates should capture the uncertainties tied to the final decision.

Risk management is like quality – if you tack it on, the value derived is less than if it gets baked in as an intrinsic part of your overall project management approach.

(Note: this risk-free article was originally published on kbondale.wordpress.com in September 2014)

I've run into a few situations recently where Scrum Masters (SMs) are performing multiple roles and while they might have the capacity to do so, on any moderate sized initiative, it might be difficult for them to fulfill all the responsibilities of the SM role.

Some people may challenge this by stating that the SM needs capacity for daily standups, sprint planning, sprint reviews & retrospectives, but that should still leave them plenty of time to take on another role.

This perception is incorrect.

Agile ceremonies represent just the tip of the iceberg for an SM. As the intro to the SM role in The Scrum Guide states: "The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values." Notice the use of the word "everyone" instead of "the Development Team". Surrounding any project or release are many stakeholders who the SM needs to work with to ensure that their interactions with the Development Team are in alignment with Scrum values. And as any good Project Manager will tell you, effective stakeholder management consumes a lot of time! Removing impediments from the team's path will also take significant effort.

If the company does not have separate agile coaches to work on elevating organizational capabilities, the SM will likely spend effort on activities such as coaching executives, training functional managers and collaborating with their fellow SMs to identify patterns.

But let's say we have agile coaches and there are minimal stakeholders for the SM to work with. Couldn't an SM play another role?

Even if capacity permits, I'd still recommend avoiding either of these roles:

• Product Owner: Even if an SM has sufficient product domain knowledge, an effective PO has to spend a fair bit of their time interacting with all the stakeholders who have needs and wants related to the product and the effort required to distill these requirements into a clean product backlog is significant. There is also a potential conflict of interest by having the "what" and the "how" intermingled.
• Technical Lead: I know that a true agile team is "flat", but for organizations going through their transformation journey, until quality development practices have been institutionalized and the shift from specialists to generalizing specialists is well underway there will be a need for senior technical contributors to review the work of more junior team members, mentor them and make key solution decisions. It might be difficult for one person to balance the servant-leadership and coaching stances of an SM with the more directive nature of a technical lead. When an SM is providing guidance to a team member, will that team member know which hat the SM is wearing?

Focus is one of Scrum's five values. An SM playing multiple roles may not be providing their team with a good example of this value in action.

Resiliency is the ability of an object to return to its original form or position after being affected by a force.  Change resiliency represents the ability of an organization or individual to bounce back after experiencing change.

Why is this an important ability to possess? 

The cliché about change being the only constant applies to all industries, hence organizations with low change resilience are unable to adopt change at the pace required for them to remain competitive.

Some writers have used the analogy of a spring to describe this attribute – if you stretch it too far, it won’t bounce back, and if you don’t stretch it all, it will rust and also be unable to bounce back when pulled.

I prefer to use the analogy of a muscle.

A muscle needs to be fed, given the time to rest, but also needs to be stressed to the point of exhaustion and fatigue so that growth happens.

How do we know if we are feeding change resiliency well?

Check employee engagement survey feedback.  If staff are indicating that they don’t feel engaged and believe that there is insufficient recognition of their efforts, the muscle is likely not receiving the nutrition required.  Regular, right-sized recognition, coaching for development (and not just performance), and an emphasis on good quality talent management can help.

What about rest?

Ask any professional athlete what happens if they push themselves too hard for too long and they’ll tell you the same thing – their performance drops dramatically.  It’s the same with change resilience. If staff experience a volley of changes with very little breathing room between to find their equilibrium, they will soon experience change fatigue and the good will which may have been built through well managed changes of the past will be lost.

So why do we need stress?

Although continuous change results in change fatigue, minimal change can reinforce a desire to maintain the status quo such that when a large change occurs, staff are unable to adapt in an agile manner. This is why it is good to have staff experience changes of different sizes and impacts on a somewhat regular basis such that their ability to cope becomes more dynamic.

Like all muscles, when properly treated, change resilience grows. Neglect it and you run the polar extremes of atrophy or fatigue.

(Note: Publishing this article in September 2014 on kbondale.wordpress.com boosted my change resiliency!)

There are multiple types of external events which a project manager or Scrum Master could consider to increase the level of collaboration and cohesion within their team. Escape rooms provide a fiscally responsible, but highly effective option.

For my readers who have never experienced one of these, an escape room provides a small team (ideally no more than eight people) with the task of completing a set of puzzles within a fixed duration of usually 45 minutes to one hour. These puzzles are incorporated within a fictitious scenario such as escaping a prison or surviving a zombie apocalypse. The narrative and challenges in lower quality rooms will follow a linear path and focus on solving one combination lock after another whereas better ones will provide the opportunity for parallel and alternate paths as well as providing puzzles which test multiple senses.

So why am I such a proponent of this type of team building activity?

Collaboration is a must, not a nice-to-have

I've enjoyed almost a dozen escape rooms and the mental and physical work involved in solving most challenges requires close collaboration. If one is shackled to a fellow "cell mate" at the start of a scenario, both have to work together to ensure that the keys to their shackles can be reached. Many puzzles require team members to coordinate their activities across different points in the room so once again, you can't go it alone!

We is greater than the smartest Me

It's a lot of fun trying to solve escape rooms with a group of self-stated Type A leaders. As the clock ticks down, it becomes apparent that the wisdom of the group needs to be harnessed rather than relying on a single leader. Situational leadership is exercised as some puzzles require spatial acuity, some memory or mathematical skills and others will demand physical dexterity. Escape rooms often have a few fiendish red herrings which can mislead one or more team members and ignoring these can be a good exercise for overcoming group-think.

We all need a helping hand sometime

All escape rooms provide teams with the ability to ask for assistance from a staff member at least once over the duration of the game. Deciding when is the right time to ask for help can pose its own challenges, especially if some team members are unwilling to show vulnerability. The same is true within the team - someone might believe they can solve a puzzle, and refuses to ask for help, but with limited time, the team will need to have the discipline to swap them out if they aren't making progress.

Communicate, communicate, communicate!

With clues to solve a puzzle scattered around the room or even split across multiple rooms, team members need to effectively communicate with one another in order to efficiently solve puzzles.

Focus

There are lots of distractions in an escape room. Multiple puzzles, false clues, artwork and interesting (but useless) trinkets and gadgets can trap us into losing focus. Support from the team is needed to help individual players focus on solving one puzzle at a time.

Unless the escape room is very simple it's rare that a team will complete their first escape room. When time runs out, rather than just rushing to the nearest watering hole, it might be worth holding a quick retrospective to understand what everyone learned and to identify opportunities for improvement with the next escape room event as well as with our projects.

To plagiarize Michael Jordan, a single team member's talent can solve individual challenges, but teamwork completes escape rooms.