Practices are actions to deliberately get a certain result. Each practice has been developed to try to achieve a specific goal or mitigate a risk/problem, In software development, practices are used all the time. Some teams use Behavior Driven Development which helps to understand what to build, while others use Impact mapping to understand why you build the feature, and some use Test Driven Development to build the software right.
In my coaching I noticed most of the teams do not actively try out new practices. Most teams look for improvements in retrospectives where the suggested improvements are usually around their current practices. This implies the team knows the practice already. Trying out new practices is beneficial for these teams especially in practices areas the team does not consider.
There are three possible reasons why teams find it hard to adopt new 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 the available practices
To address these points we created a workshop. In this workshop, the team creates an overview of practices they currently use on the Product Practices Canvas. Then they uses that overview to assess where they are underinvested and can possibly adopt new practices to improve their performance.
The Product Practices Canvas is divided into 5 practice areas:
- IMAGINE IT => Practices that are used to generate product ideas or give insights for product ideas. It consists of a clear why.
- BUILD IT(create) => Practices to build the product increment to fulfil the business case (the how).
- RUN IT (collect)=> Practices to maintain the product and makes sure it performs on production.
- (IM)PROVE IT (insight)=> Practices to prove 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 work?
After mapping the current used practices onto the canvas areas, the team has a view of which practices are used in a certain area. Usually, the teams have a lot of practices in the BUILD IT area and only a view in the other areas. An example of these practices are, in the BUILD IT area: Pair Programming, BDD, Specification by Example, code review, etc. And in the IMAGINE IT area Story Mapping and User Stories.
The next step is to identify an area the team wants to improve and search for practices that can be applied. A useful way is to explore, what is slowing down the team.
For the teams to be inspired and have an overview of the popular practices that could be applied we have created a deck of 50 practice 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.
Examples what was discovered during this workshop were:
- The team found it difficult to develop the right product?
- The practice they started was Impact Mapping.
- A different team found out that they don’t have good insight into how satisfied the customers and stakeholders were?
- The practice they started was a Sprint Review with stakeholders and customers. They also started by adding logging to collect user statistics.
To order the product practices canvas for your team. visit http://productpracticescanvas.org