Golden Rules for Agile Process Improvement

I’ve worked in a multi-site Process Improvement Team that adopted an Agile way of working.The team used a set of “Golden Rules”. These rules helped them to understand the agile approach, and to work together in a smooth, efficient and positive way. These golden rules were formulated based upon principles from the Agile Manifesto, EVO, Open Space Technology, Solution Focused, Root Cause Analysis, and Retrospectives.

The rules that we have used are:

Dare to share – As early as possible and frequently
The result depends on the team – Not the individual members
The one who checks out a task is not necessarily the one who has to finish it
The one’s working on a task are the right people
You may critique anything, but you may never criticize anyone

This simple set of rules was used throughout the project as a guideline on how we collaborated, they were our team values. They helped the team members to learn and adapt the agile approach, in a very practical way.

Dare to share – As early as possible and frequently

Team members often worked in short chunks of just a couple of hours, whenever time was available in their personal schedules (In Dutch, we applied Het Nieuwe Werken). They produced and updated slides and documents, web pages, news items, or other content. Work items were frequently reviewed, the feedback was visible for all team members. By sharing early we were able to continuously add value to our products, enabling delivery in short iterations.

This origins back to Agile and EVO, iteratively deliver value for your customer. You can use a a wiki as working space (as we did with our team), or a cloud solution like Google Sites, or Huddle. Recently I’ve started evaluating and using Worknets as a collaboration environment, for the team of veranderproject.nl.

The result depends on the team – Not the individual members

Team members frequently asked other team members to support them, or to contribute their experience or results from their own R&D centre to the project. This rule helped the team members reminding that we all brought value to the team, at different times and in different ways, using our individual strengths. Since we were all also representing our local R&D centre, this was an important value which helped the team, and the stakeholders to focus upon the contribution to the business unit result, and be open for experiences from other R&D centers. We weren’t competitors but co-workers, and the way we collaborated was beneficial for all involved, and for the company as a whole.

This rule focuses on using strengths, as described in techniques like Theory U, Angels Advocate, Perfection Game, Appreciative Inquiry and Solution Focused. (I recently wrote an article in Dutch on this subject: Veranderen vanuit je Sterktes: Da’s Anders!).

The one who checks out a task is not necessarily the one who has to finish it

Team members supported each other, and collaborated where possible. It was ok for a team member to contribute just a little bit to a product, and release it for others to work on. If somebody wanted to contribute to a product that was being updated, then (s)he picked it up when it became available, and then added his/her contribution. Since work items were checked-in quickly (often within minutes or an hours after check-out), this worked very smoothly.

Also this rules is based upon using strengths, as described for instance by Alistair Cockburn in the Delta Method (which is based upon Solution Focused). To be effective, team members have to trust each other, and assume that everybody is doing the best job they can; this principle uses the Retrospectives Prime Directive.

The one’s working on a task are the right people:

We saw that when team members had the time, and the energy to work on a certain task, then they added real value to the product or service that they were working on. Team members did not wait for others to pick up tasks, but contributed when they had the possibility to do it. The team members felt empowered to contribute to the result of the process improvement project in ways that we did not expect when we started the project. Their experience and knowledge came forward, simply by giving them the means to contribute, and setting the right culture to do it.

We learned this rule from Open Space Technology: “Whoever comes is the right people”. Team members that manage their contribution to the the result in an discplined way, they contribute what they have, when they can, in the best way that they can do it.

You may critique anything, but you may never criticize anyone

This reminded the team to always focus on the products and services that were developed. Often it was just a matter of wording, how team members expressed their critique, but that didn’t make it less important to be aware how they did it. We always assumed that people were doing the best they could, based upon what they knew and were able to do at that point in time.

Criticizing the work, and not the person is an important rule that I learnt doing reviews and inspections. It creates an atmosphere where people can give feedback, and where receivers will be open for feedback. It also helps to do retrospectives and find the Root Causes of problems, and take actions to prevent similar problems from happening in the future. Assuming that people are doing the best job they can is again based upon the Retrospectives Prime Directive.

Conclusions

These golden rules are something that my team members have learned in the project, and are still using in their current work. For them it is a way to collaborate effectively and efficiently in a team. Your rules will (and should) be different, depending on your needs and the situation at hand. But my expectation is that you can re-use from the principles that we have used to define our rules: The Agile Manifesto, EVO, Open Space Technology, Solution Focused, and Retrospectives.

This article was originally published by Ben Linders in his blog post Golden Rules for Agile Process Improvement.

About Ben Linders

Ben Linders is an Independent Consultant in Agile, Lean, Quality and Continuous Improvement, based in The Netherlands. Author of Getting Value out of Agile Retrospectives, Waardevolle Agile Retrospectives & What Drives Quality. As an adviser, coach and trainer he helps organizations by deploying effective software development and management practices. He focuses on continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Ben is an active member of networks on Agile, Lean and Quality, and a frequent speaker and writer. He shares his experience in a bilingual blog (Dutch and English), as an editor for Agile at InfoQ and as an expert on TechTarget. Follow him on twitter: @BenLinders

View all posts by Ben Linders →