Easy in theory, difficult in practice

My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

Does a Scrum Master have to be a techie?

Are you just following up or are you micromanaging?

Essentialism is agile

Reduce risk by enhancing estimation

Because "It's there" is not a good reason to pursue agility!

Does a Scrum Master have to be a techie?

Recently I wrote an article about the potential for a Scrum Master to take on additional roles. While I was teaching a class this week, one of my learners voiced a concern about Scrum Masters who didn't possess deep technical knowledge of the product solution. He felt that without this expertise a Scrum Master would run into difficulties in building credibility with the Development Team. He also believed that a Scrum Master lacking this knowledge might not know enough to ask the right questions when trying to understand specific technical risks or impediments and hence wouldn't be effective in clearing hurdles from the team's path.

Having been posed similar questions in the past with regards to project managers, I believe the answer is consistent for both roles. Some technical knowledge is necessary, but given a choice between a technically savvy Scrum Master who isn't an effective servant-leader and one who has some technical competency but does a much better job of improving interactions within and outside of the team to enhance value delivery, I'll always pick the latter.

To keep myself honest, I decided to double-check my views against The Scrum Guide™. The only activity listed for the Scrum Master role which could be interpreted as requiring technical competency is listed in the Scrum Master's service to the Development Team: "Helping the Development Team to create high-value products". I take this as meaning that a Scrum Master has sufficient competency to encourage technical excellence but isn't necessarily challenging specific technical decisions or contributing directly to solution design or development.

A few years back I'd written an article covering the pros and cons of a project manager being a technical subject matter expert. The same risks apply to a Scrum Master such as the potential for the Scrum Master making assumptions based on their past hands-on experience or the likelihood of their butting heads with team members when they disagree on specific technical matters.

As with all Scrum Team members, I would encourage Scrum Masters to become generalizing specialists and if they possess the capability and capacity to help the team achieve sprint goals, they should, but making this a default expectation of the role suggests that the supporting organization is not able to form a "whole" Development Team. Quoting The Scrum Guide™ again, "Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment".

Servant-leadership is a lifelong journey of self-discovery and personal development. Let's not divert focus from that critical path by requiring Scrum Masters to also develop deep technical expertise.

Posted on: October 21, 2018 07:00 AM | Permalink | Comments (9)

Essentialism is agile

Categories: Agile, Project Management

I'm reading Greg McKeown's book Essentialism: The Disciplined Pursuit of Less and many of the lessons within it echo the tenth principle from the Manifesto for Agile Software Development which is "Simplicity--the art of maximizing the amount of work not done--is essential".

In the past, I've mostly considered this principle as it relates to how we deliver value to our customers. It provides a constant reminder that practices, ceremonies, tools and artifacts are just a means to an end, and shouldn't be elevated as an end unto themselves. Minimal sufficiency should be our goal when expending effort on anything which doesn't create business value for our stakeholders.

But we can also apply this principle to our products.

While Greg's book provides a lot of insights, there's one line which really resonates with me: "If it isn't a clear yes, then it's a clear no."

Greg provides an example of the company Vitsoe which applies this filter when hiring new staff, but the same principle could be applied when deciding what to include in product backlogs. Let's consider the example of the mice provided with the first Apple Macintosh computers. The design team at Apple could have added multiple buttons and scroll wheels the way future generations of PC mice were designed, but a single button sufficed to allow a user to effectively use the Macintosh graphical user interface.

This principle is key when defining Minimum Viable Products (MVP). A good MVP should generate empirical evidence to support or refute a hypothesis and adding features which won't directly support that learning is waste.

But minimal sufficiency could be applied beyond MVPs to general releases. By doing so we can reap some of the following benefits:

  • Reducing learning curve. One of the attributes of well designed products is that they can be used with minimal instruction.
  • Reducing ongoing maintenance costs. To quote Scotty from Star Trek III: The Search for Spock - "The more they overthink the plumbing, the easier it is to stop up the drain"
  • Reducing ongoing regression testing efforts. As system complexity grows, the points of interdependence between seemingly unrelated components makes it almost impossible to avoid regression defects.
  • Focusing development teams on core capabilities.

To quote Greg, the next time you are considering whether or not to add a feature, ask yourself the question "Is this exactly what I am looking for?"

Posted on: October 14, 2018 07:00 AM | Permalink | Comments (14)

Because "It's there" is not a good reason to pursue agility!

Categories: Agile

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.

Posted on: October 07, 2018 07:00 AM | Permalink | Comments (16)

How many hats should a Scrum Master wear?

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.

Posted on: September 30, 2018 06:59 AM | Permalink | Comments (18)

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

Categories: Agile, Team Building

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.

Posted on: September 23, 2018 07:00 AM | Permalink | Comments (20)

"If at first you don't succeed, try, try again. Then quit. There's no use being a damned fool about it."

- W. C. Fields