Posts Tagged With: Peer-level support

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.


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.

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

Does knowledge transfer change with agile?

We have all experienced this: a key contributor announces their departure and a mad scramble ensues to transition their knowledge to the rest of the team.

But does this change when the team is using an agile lifecycle?

On the surface, it might appear that there wouldn’t be any significant differences in how it is done regardless of the nature of the work or how it is performed. After all, knowledge transfer is usually a case of a subject matter expert educating others through either a live session or through some sort of persistent record such as a wiki, a video or an audio recording.

While this is true, there are characteristics and specific practices in agile delivery which can impact knowledge transfer.

Traditional delivery usually relies on individual specialists who remain focused on their role and area of expertise. On the other hand, agile delivery encourages the development of generalizing specialists who will develop a broader set of skills and knowledge. Higher levels of collaboration are also expected in such contexts which increases the amount of exposure that individual team members have to each other’s knowledge.

While this won’t translate into full fungibility across a team, there is less likelihood of only one team member possessing critical information. This won’t happen over night. It will take many weeks of working together as well as explicit encouragement by supporting stakeholders such as functional managers for generalizing specialists to develop.

Another enabler is non-solo work – pair programming, hackathons, mob programming and model storming are all practices using this principle. While the primary purpose of these practices is not knowledge transfer but rather quality and speed, it is a valuable side benefit. Rather than having experts share knowledge in an academic manner, demonstrating how their knowledge can be applied towards completing work items is more effective.

Whereas traditional delivery tended to emphasize documentation as the medium for passing work between roles, agile approaches focus on minimal sufficiency. While a newly formed team might require more documentation to facilitate shared understanding, a long lived team might successfully deliver with much less. The challenge becomes when a new or junior team member joins as there may be insufficient reference material to enable self-learning. But this should not cause any major issues if someone on the team volunteers to pair up with the newcomer to help fill in the blanks.

While the need for shared knowledge is there in all contexts, effective agile delivery can reduce the critical of explicit knowledge transfer.





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

Respect the 5 R’s of project transition!

transitionWith shifting business priorities caused by internal strategic or external environmental changes, it is not uncommon to find yourself pulled off one project to manage a new, higher priority one. In some cases, the project you had been previously leading is put on hold or could even get cancelled but other times, the previous project is handed over to a different project manager.

Under such circumstances, you are likely going to be under some pressure to start planning and leading your new project, so you might be forgiven for just pointing your replacement in the direction of your project control book and introducing them to the sponsor, key stakeholders and the team. If you really want to reduce the likelihood of getting pulled back in when things start to go wrong, it would be much better to negotiate with your leadership team for some breathing room to help you complete the following activities.

  1. Refresh your project control book. If it has been a few days (or weeks!) since you last reviewed and updated your schedule, RAID log and other living project control knowledge, do it now to save your successor from the frustration of having to bridge gaps between the documented and actual state of the project.
  2. Review open risks, actions & issues with the new project manager but also walk them through key decisions which were made over the project’s lifetime and any critical assumptions which haven’t been validated. A detailed review of the stakeholder register, project schedule and financials is also required.
  3. Request the new project manager to facilitate a short lessons identification workshop with the team and some stakeholders. This not only gives you the chance to share lessons you’ve identified to date before you leave the project, but it also provides your successor with insights into the personalities of the key players on their new project.
  4. Recognize your team members – just because a transition is happening shouldn’t mean that the good work they’ve done so far gets forgotten. Thank your old team members personally, and if your relationship with them supports it, meet with them individually to coach them on any opportunities for development. Send their people managers a brief note highlighting their accomplishments.
  5. Reset access. I’ve lost count of the number of times I’ve taken over the leadership of a project only to find that I’m lacking the appropriate level of access required to work with key systems or documents. Credibility and precious time gets lost in resolving this if the transition has already happened. As part of the transition, the new project manager’s access privileges should be configured and yours should get reduced or removed.

Running for the hills might seem a natural reaction to being handed a new project, but resist this temptation and review the 5 R’s!



Categories: Project Management | Tags: , , , , | 2 Comments

Create a free website or blog at

%d bloggers like this: