Need help team building? Try to escape an escape room!

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.

Advertisements
Categories: Agile, Project Management | Tags: , , , | Leave a comment

Helping functional managers through an agile transformation

A lot has been written about the challenges caused by functional managers when their company undergoes an agile transformation. But with this emphasis on what they shouldn’t be doing, not as much gets published about the specific activities we should be doing to help them through the change.

Here are four questions to ask when considering this key role.

Are they learning?

To support a change you need to understand the change. Delivering training focused specifically on what functional managers need to know about agile which includes scenario-based learning to understand what sorts of behavior changes are expected when faced with common situations will help. But it is also important to identify which managers have already shown evidence of having embraced an agile mindset and recruit them to help support their peers who will have a harder time with the transition. In the absence of such internal support, coaches could be hired to create a critical mass of change advocates among middle management.

What are they measured on and what are they measuring?

Metrics aren’t the sole driver of behavior but they do draw a lot of focus. As Tony Robbins would say, “Where focus goes, energy flows“. If we haven’t updated performance measures for functional managers and their staff, it will be much harder to encourage them to change. If existing metrics are focused on how well team members and their managers achieved certain objectives but didn’t also consider how those objectives were achieved, deadlines and budgets will continue to dominate rather than collaboration and engagement. These measures need to be augmented with ones specifically assessing stakeholder and team member satisfaction to understand whether the “how” was as good as the “what”.

Who are they hiring?

I’ve written previously about the importance of adjusting job descriptions and hiring criteria but it is equally important to train functional managers on how to leverage these changes. If the job profile calls for servant-leadership but all the functional manager asks about is what a candidate accomplished, the risk of hiring people who are not aligned with the new way of working will persist. Pairing functional managers with properly trained HR staff for panel interviews is one way to address this.

How are they supporting their staff?

Team members will be experiencing many of the same fears and doubts that their manager has about the transformation so it is important that functional managers meet regularly in both one-on-one and team settings to address these concerns. Managers play a critical role in helping their staff gain the confidence to take their first baby steps towards self-organizing and becoming T-skilled. To do this, managers must cultivate a psychologically safe environment within their teams so that their team members feel safe about expressing themselves and taking chances both in the project roles and in their functional ones.

Buy-in from middle management is necessary for any successful organization change, and even though you might think that the sandwich approach of committed senior leadership and enthusiastic front line staff squeezing out compliance, actively guiding and supporting functional managers will be essential to a sustainable transformation.

Categories: Agile, Facilitating Organization Change | Tags: , | Leave a comment

Are regulatory projects a better fit for adaptive or deterministic delivery approaches?

During a presentation at a local agile meetup this past week I asked the audience to think about what sorts of projects, products or organizations wouldn’t be a good fit for the use of agile or adaptive approaches and one of the attendees felt that regulatory projects weren’t suitable.

Non-discretionary compliance projects present many challenges, but does this make them help or hinder their delivery via agile approaches?

Here are some advantages to using adaptive life cycles with such projects.

  • The “what” is inflexible, but there is usually wiggle room around the “how”. Once external regulations have been translated into a set of internal business requirements there are many ways in which those requirements can be met. With deterministic approaches, a business owner might be tempted to go for a “Cadillac” fully automated solution whereas with an adaptive approach, the focus might be on minimally meeting the requirements through a combination of manual and automated steps and then letting empirical data and budgetary and schedule constraints dictate what incremental enhancements get made.
  • Adaptive approaches encourage fixing schedule and cost and letting scope remain variable. With regulatory projects, schedule is usually externally fixed and since there is no business value in going above and beyond the regulatory requirements, a ceiling on costs could also be set.
  • Frequent feedback from end users on what is getting delivered increases the likelihood that complex regulatory requirements are correctly understood.
  • Early and regular releases will reduce the learning curve for sustaining the process changes.
  • Risk exposure can be used as a criterion for prioritizing the backlog of regulatory requirements. With this approach, a regulatory business owner can feel confident that those requirements posing the highest risk exposure to the company get delivered first.

However, there might also be some good reasons to follow a deterministic approach.

  • These projects often involve changing multiple legacy processes and systems. Such changes might require heavy governance oversight and there could be blockers such as a lack of automated test capabilities or dedicated environments.
  • Regulatory staff are often unable to dedicate themselves to the delivery project given their operational responsibilities so it might be difficult to secure a product owner or other business users.
  • Regulatory projects often require participation of external partners such as vendors and government regulators. These stakeholders might be unwilling or incapable of working with an adaptive delivery approach.
  • Regulatory business owners might be uncomfortable with not fully reviewing and approving the details of the “how” upfront. While this could be said of any business owner who hasn’t previously worked with adaptive delivery approaches, the perceived risks and impact of failure are much higher for regulatory projects.

As usual, when deciding what delivery approach to take, the specific context of the project and supporting organization have to be taken into consideration.

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

Blog at WordPress.com.

%d bloggers like this: