Posts Tagged With: Process compliance stupidity

Evaluate your ceremonies with a W5 check

I’m midway through Priya Parker’s book The Art of Gathering and her insights into how to make an event a meaningful gathering rather than “just another boring meeting” are apropos to ceremonies. A common complaint many team members raise in the early days of an agile journey is that it feels like they are in too many meetings. This shows that they aren’t perceiving the value of the ceremonies and, if these concerns aren’t addressed quickly, the team members are likely to disengage.

One way to evaluate your ceremonies is to do a W5 assessment on them.


Without a shared understanding of the purpose for the ceremonies, misalignment of expectations and behaviors may emerge. It is critical that a newly formed team understands why each ceremony is needed, but as the team evolves, the purpose of each should be reviewed to ensure it remains relevant. One way to gauge this is to ask each team member to summarize what they believe the purpose of the ceremony to be in three words or less.


Once there is clarity on why, we need to confirm that the outcomes of ceremonies are being realized and are in line with the purpose for conducting the ceremonies. Poll team members on their perception of the effectiveness and efficiency of producing those outcomes.


A common challenge with agile ceremonies and most recurring events is that, over time, you might pick up a number of participants who “just want to observe” or “need to be kept in the loop”. If everyone is needed, no one is needed. A self-disciplined, self-managing team will weed out those stakeholders who aren’t required but will be equally diligent on ensuring the right participants are at each ceremony. For example, conducting a sprint review without adequate representation from those who will be consuming the outputs of the team is a waste of time. Who is also about the role each participant plays. While new teams might lean on the Scrum Master to facilitate most ceremonies, over time, this can become a shared responsibility, giving each team member a chance to develop their facilitation abilities.


It is a good practice to hold ceremonies at the same day and time but the timing that seemed ideal in earlier sprints may not suit all participants in later ones. It is also worth evaluating the duration of the ceremonies as they should be long enough to meet the purpose and achieve the expected outcomes and no longer. If certain team members are missing certain ceremonies, it is worth confirming whether the timing is still suitable for all participants.


Whether it is physical meeting rooms or virtual video conferences or collaboration environments, it is important to ensure that the location supports the purpose and approach and doesn’t detract from it. In physical settings, this could be as simple as the arrangement of chairs around a table and the availability of white board space for spontaneous collaborative activity. Consider alternative environments for physical ceremonies. Could it be possible to conduct some in a more dynamic manner – perhaps as a walking meeting? In virtual sessions, this means ensuring that the tools provided (e.g. polls, whiteboards) are functional and everyone knows how to use them in advance of the ceremony.

How frequently ceremony reviews should take place will vary and one trigger for a health check might be to have team members vote every few weeks or every couple of sprints on how valuable they feel each ceremony is.

To paraphrase Chris Fussell “If your team is trying to be more agile, stop and think, ‘Are my ceremonies actually productive, or are we merely having ceremonies for ceremonies’ sake?’

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

How do you know when your agile ceremonies are Done?

In last week’s article, I wrote about the benefits of having a Definition of Ready for agile ceremonies as one method of ensuring that they are adding value and not being perceived as just more wasteful meetings.

But how do we know that we achieved what we were hoping to from the ceremonies? A Product Owner might walk out of a sprint planning session feeling happy that the team will be delivering a major feature but some team members might feel that they have accepted more product backlog items than can be completed in a quality manner while working reasonable hours.

The Scrum Guide encourages Scrum Teams to create a definition for what “Done” means for product backlog items and for product increments. This ensures consistency in understanding across all stakeholders and ensures that expectations have been met. The same approach could be utilized to ensure that teams aren’t just going through agile ceremony motions.

Here are a few examples of “Doneness” questions for the same ceremonies I had written about in last week’s article.

Sprint Planning

  • Have one or a few key goals for the sprint been articulated by the Product Owner?
  • Does the entire team understand why the goals are important and how they connect back to the product vision or roadmap?
  • Has the Product Owner collaborated with key solution (“How”) stakeholders such that product quality and technical debt were considered when populating the sprint backlog?
  • Has each team member assessed their available capacity and used that knowledge when contributing to the team’s sprint commitment?
  • Does each team member have a “sufficient” understanding of the sprint backlog items to feel confident in the team’s sizing of those items?
  • Has the team reviewed the top ideas from the previous retrospective, shared them with the Product Owner and agreed to act on those in the current sprint?

Scrum/Daily Standup

  • Does each team member feel the team is aligned to doing the highest priority work in support of the sprint and product release goals?
  • Does each team member have a general understanding of what everyone else is working on and the dependencies between each other’s work?
  • Have all potential and realized impediments for the day’s work been surfaced and either addressed or have an owner identified to address them after the standup?

Sprint Review

  • Do the invited stakeholders understand what was completed in the previous sprint?
  • Has feedback been received on all completed product backlog items?
  • Have any new requirements or ideas raised during the ceremony been added to the product backlog or at least captured by the Product Owner?
  • Has the team been given a chance to share their thoughts on the previous sprint?

Sprint Retrospective

  • Did every team member get a chance to contribute to the discussion and did they?
  • Have some improvement ideas been identified and is there a plan in place to act on those, ideally in the upcoming sprint?
  • Did the team assess not just “what” they did, but “how” they did it?
  • Did every team member feel it was a safe environment to share their thoughts?

Similar to a normal Definition of Done, there is no single set of guidelines which should be adopted by all teams and these guidelines may evolve over time as the team inspects and adapts their ways of working. But, as usual, caveat agilist: Focus on the outcomes, not the processes.

“If you spend too much time thinking about a thing, you’ll never get it done.” – Bruce Lee


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

Control partners should have skin in the game!

I finally completed reading Nassim Taleb‘s book Skin in the Game which I had written about in a recent article.

In that piece I had applied his principles when comparing the benefits of a product-centric orientation to the project-centric model which is still found in many organizations. But after finishing the book, I realized that there is a much more compelling example of the challenges experienced with risk asymmetry in many large organizations, namely with those staff who are responsible for developing the policies, standards and methods used by teams for delivering projects or products.

In small companies, how a product gets developed and delivered is usually defined by a “Big Brain” (e.g. a solution owner or similar role) or developed collaboratively by those actually building the solution. But as the size of the organization increases and stakes get higher, control partners emerge to influence not only what but how production occurs.

Where things get difficult is when these control partners do not experience first-hand the downside of their decisions.

For example, in some companies, project management standards are set by a centralized department such as a PMO. While some delivery roles such as program or project managers might report in to the same PMO, there are staff whose sole focus will be to define and maintain standards. As those staff are not in a project delivery role, even if they possess years of practical experience, as they won’t themselves have to use the templates and tools which they have developed, they don’t have true skin in the game. Delivery staff may complain to control partners about how onerous or non-value add specific practices are, but there is little direct impact to them.

There are a couple of ways to rectify this situation:

  • Serving in such control functions could be a rotational responsibility. After someone has spent a reasonable amount of time in a control role, they should be required to spend an equal amount of time in a delivery role. This will also help them better identify patterns and anti-patterns specific to a given context.
  • Introduce performance measures and incentives for control staff which are tied to the impacts created by their work as opposed to just the completion of this work. For example, quantifying the cost of control or conducting regular satisfaction surveys with delivery staff are two methods in which we could bring back skin in the game.

Method makers and framework formulators – practice what you preach!




Categories: Facilitating Organization Change, Process Peeves, Project Management | Tags: , , | Leave a comment

Create a free website or blog at

%d bloggers like this: