Evaluate Process Qualities, not Process Compliance

Many people are familiar with process evaluation like The Nokia Test. There are also mash-ups of popular assessments, and I like The Borland Agile Assessment about the best, because it focuses on qualities (We work in an environment of trust and respect), rather than compliance (Single Product Backlog).

Jeff Patton wrote an article, Performing a Simple Process Health Checkup that is based upon properties taken from Alistair Cockburn’s book Crystal Clear.  The following is a modified version that a client and I put together for their context. 

Evaluate Process Qualities, not Process Compliance

Evaluate process based on qualities you hope to see in a process and not process compliance. Successful approaches encourage continuous process innovation and improvement, and recognize that success is more a function of the skills of individuals and their willingness to collaborate, improvise, and improve.

Evaluation Criteria

We start with the qualities below to evaluate product-centric organizations. Feel free to change is as needed to fit your organization’s values and context. Try a self-evaluation and do this at a team level. Subjectively grade your process using the criteria below where an “A” would be the ideal envisioning of the quality, and an “F” would be the absence of it.

1. Shared understanding of success

  • What the product is and who the target customers are
  • Benefit to the organization and audience, guiding success with measures/KPIs
  • Expected outcomes and impact, and a list of items that we believe will help us get there
  • Incremental release plans with focused target outcomes on a focused target market

2. Deliberate discovery

  • A product manager, supported by a user experience professional and senior engineer, plans and leads discovery work
  • Makes decisions to answer; is the outcome:
  • valuable to the audience, usable to them and feasible for us to build?
  • Identify problems to solve, not just build features customers ask for
  • Imagine and describe possible solutions (hypothesis) to achieve the outcome
  • Build and measure small experiments that test the hypothesis imagined

3. Whole-team product ownership

  • Feels responsible and accountable for what is put in the market
  • Elements and priorities of the work are understood
  • – especially with respect to the target audience and their needs
  • Reflects often on how well the product is doing in the outside world

4. Predictable delivery

  • All work committed to is finished within a development cycle, or within the cycle time SLA
  • Velocity/throughput is measured, made visible, and doesn’t vary too drastically
  • Just enough work is done ahead of the development cycle and when planning to not often be surprised by its difficulty

5. Whole team process ownership

  • Shows discipline in work habits and feels responsible for success
  • Choose to follow the process for working effectively together
  • Deliberately change process when it’s not effective
  • Follow through with changes and reflect on how well those changes worked
  • A coach or manager isn’t needed for reminding what the process is, but is leveraged to facilitate learning and improvement

6. Working effectively – gel factor

  • Talk ad-hoc and frequently, instead of relying on meetings or ceremonies
  • Help each other to overcome challenges and finish work together
  • Speak openly, tolerating and handling conflict productively

7. Team balance and autonomy

  • Aware of organizational goals, the team is allowed to control their own destiny
  • The organization does not distract the team with internal strategic discussions
  • Most decisions are made at the team level
  • One team can deliver their work in to production without involving anyone else

How do you know if your process is working? How do you diagnose teams, or have them reflect deeply on their own process? Please let us know in the comments!

Aaron is an Agile coach and a snowboarder that actually likes riding down a mogul field. Follow him on twitter @_aaron_sanders.

This entry was posted in #agile explained and tagged , , . Bookmark the permalink.

2 Responses to Evaluate Process Qualities, not Process Compliance