Process Peeves

Thoughts on simple optimizations that could make daily processes better…

A camel is a horse designed by a committee

The old saying about committees came to mind when I was considering the default approach companies often use to achieving a control objective. Bringing together diverse perspectives can help to reduce bias, but in many cases a simpler approach might result in a better outcome.

Let’s focus on the specific example of a solution architecture review.

It is rare that there is accountability for each member of a committee if their decisions were poor as they have no skin in the game. The power imbalance between the committee and the creator of the architecture proposal being reviewed might also encourage nitpicking over format or style rather than substance.

There is also an increased likelihood of incurring delay and other forms of waste. Committees meet at scheduled intervals which might not align well with the needs of a specific team. The committee might also be faced with a “feast or famine” challenge where they are overwhelmed with submissions at some meetings with the result that certain teams don’t get their proposals reviewed. Beyond the proposal review itself, there is usually a need to go through some type of formal intake process and to provide other documentation for committee-specific needs. The overhead costs of running the committee are likely to be charged across all teams.  And don’t get me started with the increased costs of re-work or repeat reviews beyond the initial presentation…

So let’s consider a simpler alternative as the default approach with a committee used only an exception basis for the most complex situations.

Why not require all architects to spend a fixed percentage of their capacity on conducting structured peer reviews of each other’s architectural proposals? Each architect is expected to have a clear understanding of enterprise standards and good architectural practices, so control objectives should still be met.

This addresses both of the previous disadvantages:

  • Greater skin in the game. The architect who reviewed the proposal will be sharing accountability for the outcomes with its creator. On top of that, should the reviewer not be fair in the review process, this behavior will be rewarded in the future when it is his or her turn to be reviewed.
  • Reduced delay and waste as it is much easier for two people to meet than a committee and the level of process or bureaucracy around the review can be minimized.

It might also result in a better architecture as we may be more open to incorporating feedback from one of our peers than a group of seniors.

Ensuring that there is a fair balance of review work across all architects might be achieved through some sort of random allocation system that prioritizes reviewers based on their last review date.

Delivering in a leaner manner should not require sacrificing the control objectives which will keep us safe, it will just require re-thinking how we approach governance.


Categories: Agile, Facilitating Organization Change, Process Peeves, Project Management | Tags: , , , | Leave a 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

No bugs in agile?!?

When a team is following an agile delivery approach and they have developed a Definition of Done (DoD) containing one or more criteria indicating that no defects are permitted in or as an outcome of completed work items, they should not have to deal with bugs escaping a sprint, and hence, the practice of documenting defects should become obsolete.

But how often does this happen in the real world?

Let’s consider what’s required to achieve this:

  • Pairs programming or other quality-focused development practices
  • Dedicated test environments covering the totality of the solution including all points of integration
  • Full coverage automated regression testing
  • Frequent (if not continuous) integration and deployment to support the progressive testing of completed requirements
  • The planning, definition and automation of test cases covering all of the requirements being worked on in the sprint
  • The ability to execute full non-functional testing within each sprint – security, performance, accessibility and localization to name just a few

If any of the items in the preceding list look daunting in your current context, don’t panic – you are not alone.

Teams in organizations early or midway through agile transformation will work on products possessing none, some or all of the above prerequisites.

In the interim, here are three choices for those teams:

  1. If the defect relates to the natural evolution of the customer’s wants and needs then it should be captured as a new requirement in the product backlog and prioritized by the Product Owner.
  2. If the defect can be resolved and properly re-tested within the current sprint, there is almost no value in documenting it. If there are significant time zone or geographic boundaries separating development and test roles, or if either the developer or tester are unable to work on it right away, the defect might still need to be captured somewhere to ensure it doesn’t fall through the cracks before the end of the current sprint.
  3. If the team’s DoD excludes the resolution of cosmetic or low severity defects, the defect should be added to the product backlog and prioritized by the Product Owner. This is an acceptable compromise for many lower maturity teams, but over time as their delivery capability improves, they will want to tighten up their DoD to prevent a progressive increase in this specific type of technical debt and to avoid their customer experiencing Death by a Thousand (quality) Cuts.

Linus Torvalds said it best “I’m generally a very pragmatic person: that which works, works.


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

Create a free website or blog at

%d bloggers like this: