Which practices do you use in your way of work?

Practices are action tools to deliberately get a certain result. Each practice has been developed to improve a specific goal or mitigate a risk/problem. Using practices to improve a specific goal is very helpful, example are: Behavior Driven Development helps to understand what to build, Impact mapping to understand why you build the feature, Test Driven Development to built it right.

How come that still many teams don’t search for practices they want to experiment with? 

Most teams look for improvements in retrospectives. In such meetings, the improvement is the meeting result, which implies the team knows the practice already and understand how we can apply it. 

There are three drivers why teams don’t search for practices.

  • Teams don’t get triggered to search for a new practice 
  • Teams don’t know when to use which practice.
  • Teams don’t know that there are more practices.

To address the last two drivers we created a workshop. In this workshop, the team creates an overview of practices they use on a canvas. The starting point is the practices the team already uses. We group the team’s practices into output, outcome and impact-oriented. This grouping is done to make it easier to map. Each group, we map onto the Product Practice Canvas to identify which practices the team uses. 

The Product Practices Canvas is divided into 5 areas with its focus. Practices can be mapped into the following areas:  

  • IMAGINE IT => An idea is generated and translated into a business case to pick up by a team and consist of a clear why.
  • BUILD IT(create) => The team builds the product increment to fulfil the business case (the how).
  • RUN IT (collect)=> the team can maintain its product and makes sure it performs on production.
  • (IM)PROVE IT (insight)=> here the business case (the why) will be answered with results, do we prove the business case and do we need to improve it.
  • PROCESS => Practices that are part of the team’s current way of working?

After mapping your practices onto the canvas areas, the team has a view of which practices are used in a certain area. Which results often in lots of practices in the BUILD IT area and only a view in IMAGINE IT. Examples from the BUILD IT area are: Pair Programming, BDD, Specification by Example, code review, etc. With the IMAGINE IT area, we see a few like Story Mapping and User Stories. 

By mapping used practices on the canvas, the team learns what practices are used to deliver the product. 

The next step is to identify an area to improve and search for practices. A useful way is to look, what is slowing down the team. Examples can be: issues with the build quality or the team find it difficult to develop the right product? For the build quality practices in BUILD_IT or IMAGINE IT can be looked into. Do we need more insights into our quality in production? Do we need more tests? Do we need monitoring? Etc. 

For most teams it is difficult to suggest new practices, therefore, we have created an inspiration deck of 50 cards with a brief explanation that will help teams to decide how and if this practice can serve them. The workshop ends when the team finds one or more practices they understand and find safe to try in their team.

Below you find a real example of the workshop.