Posts Tagged With: improving project management

Will all improvement ideas from a retrospective consume capacity?

The Scrum Guide indicates “The Scrum Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

During a class which I was teaching this week, one of the learners asked: “Won’t the ideas from a retrospective use up some of the team’s capacity in the next sprint?“.

As usual, it depends.

Here are a few scenarios and I’m sure there are many others.

If an improvement idea requires the team to learn a new skill or to perform a task which they wouldn’t have done otherwise, then yes, it will consume capacity in the next sprint. Teams which aspire to be as transparent as possible will make these types of ideas visible to all stakeholders by explicitly adding them into the sprint backlog. When deciding on whether to implement these ideas, the team should balance the capacity costs against the potential delivery, quality or happiness benefits.

For those ideas which relate to improving behavior or interactions within the team or with the stakeholders supporting the team, there might be no capacity impacts beyond the team figuring out how they will remember to behave in a different manner. If the team was used to working virtually but saw some benefits in face-to-face interactions at least once a week, they could do so without reducing available capacity.

Some suggestions might require work effort from those outside of the team. For example, a dedicated testing environment might be desirable to reduce the impacts of limited access to a shared environment. An external person might provision the environment hence there would be no capacity impacts for the team beyond confirming that the new dedicated environment was setup correctly.

Finally, other suggestions might change the effort required to complete work items. If the team enhances their Definition of Done to include more criteria to improve product quality, this might increase their effort per work item.

Regardless of the nature of the improvements, there is a critical difference between retrospectives and traditional lessons learned practices. With the latter, only a small fraction of what was identified is immediately applicable, whereas with the former, the majority of the vital few ideas identified should get implemented before attention shifts and memories fade.

Thanks, Deepak, for inspiring this week’s article!

Categories: Agile | Tags: , | Leave a comment

Humility is a prerequisite to agility

The Scrum Guide identifies commitment, courage, focus, openness and respect as Scrum Values. Those values apply regardless of the delivery framework or method used and missing any one of those reduces the benefits of an agile journey. But it might be worth adding one more to round out the list: humility.

Merriam-Webster defines humility as “Freedom from pride or arrogance“. I prefer the Cambridge Academic Content Dictionary’s definition that it is “the feeling or attitude that you have no special importance that makes you better than others“.

Similar to the other Scrum Values, humility could be considered in the context of both the individual and the team.

We don’t consider ourselves to have any special authority or rank over other members of our team. We also don’t assume that we are always right which makes us open to hearing differing viewpoints and not shying away from healthy discussions in order to produce the best possible outcomes for our customers.

False humility doesn’t cut it.

We openly acknowledge when are skilled in some areas and best positioned to help the team achieve a goal but will honestly communicate when we know less. While we are happy to accept accolades for our work, we will recognize that our successes were realized through the support of the rest of the team.

We remain open to feedback about our personal work activities and outcomes and are able to resist the natural tendency to become defensive when we receive constructive feedback.

Without humility, the pillars of Inspection and Adaptation crumble.

We know there is no ONE right way (or framework, or method, or practice or tool).

We may meet our sprint goals every sprint and receive rave reviews from our customers but we have the humility to acknowledge that we can always do better. This supports true continuous improvement.

Product Owners will possess a deep understanding of the product domain but effective ones have the humility to acknowledge when a pivot in product direction is needed and don’t allow customer value and team morale to be sacrificed at the altar of preserving the Product Owner’s ego. The scientific method which underlies the good practice of Minimum Viable Products depends on the humility of a scientist acknowledging that their hypothesis might be disproven.

Humility extends to the roles supporting our agile teams. Coaches should know what they don’t know and be capable of recognizing when those being coached have outgrown their services. Such coaches possess the humility to step aside to let others who are better positioned to help those being coached through the next stage of their capability development.

Be like the bamboo, the higher you grow the deeper you bow” – Japanese proverb

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

Project lessons from playing pool

A few months ago, I rekindled my enjoyment of the game of pool after having played it sporadically over the past twenty years.

I find something soothing about the clickety-clack sound of balls ricocheting off one another and relish the challenge of figuring out which shot to play to sink a ball and line up my next shot or if I miss, at least prevent others from making their shots.

Racking my brain (pun intended) for a topic to write about this week I thought why not explore whether there are any lessons we can learn from playing pool which might be applicable to project work?

  1. Standard pool is played with fifteen colored balls (not counting the cue ball). Diversity within teams is a source of strength. Yes, it might make the storming and norming phases of team development more challenging, but higher performance, creativity and resilience can be the rewards for persistence.
  2. No two pool tables play exactly the same. Until we understand the unique attributes of a given table, making assumptions based on previous games played on different tables is likely to get us into trouble. With our projects, while historical data can be relevant, we need to understand the specific context of a project to avoid using the wrong tool or technique.
  3. Define the rules of play with your opponents. There are some generally accepted rules for playing pool, but certain practices might vary by who you play with. There are generally applicable principles for project delivery but work with your teams to develop working agreements and ways of delivery which are best suited to them and the needs of the project.
  4. Balance risk with reward. Yes, that tricky bank shot would look impressive to bystanders if you can make it, but if you miss, you might set your opponent up to run the table. But playing it too safe usually won’t work out well either, especially if your opponent has a greater ability than yours! When working on projects, we need to find the right balance between playing it too safe and living on the edge. The former might result in mediocre business outcomes but the latter could result in project failure. This is why having good judgment is critical for project team members.
  5. It takes self-control to do well. It can be really tempting to apply full force on a shot, but you could end up scratching or sinking one of your opponent’s balls. Being mindful about the amount of force required to make a given shot and leaving your ball well positioned for the next shot is important. Delivering challenging projects takes discipline and sloppy execution will hurt us in the short or long term.

Finally, “Take care of your cue ball, and it will take care of you“. Support and lead your team and they will help your project succeed.




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

Blog at

%d bloggers like this: