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

Recently I gave a talk on the ScrumDayEurope 2014 conference. The talk was about how you can use game principles in combination with evidence based management (EBM) in your agile adoption. One of the hard points in evidence based management is that people tend to ignore evidence when that evidence clashes with their believes or observations [0].

Near the end of the talk I presented Richard Hackman’s thought experiment to discuss how hard evidence based management is. You can see the thought experiment below:

“Think for a moment about one of the finest teams you have every seen–one that performed superbly, that operated increasingly well over time, and whose members came away from the group experience wiser and more skilled than they were before. Next, think about a different group, one that failed to achieve its purposes, that deteriorated in performance capability over time, and whose members found the group experience far more frustrating than fulfilling. In your view, what is most responsible for the difference between these two teams?”

source: http://www.apa.org/science/about/psa/2004/06/hackman.aspx

So, what do you think what is most responsible?

All of the approx. 50 people in the room argued that leadership or coach capabilities and traits are responsible for having a high performing team or a poor performing team. The people argued that a high performing team is a result of good leadership. The answer is understandable, because most of the popular articles we read say exactly that. Stronger even, we seem to experience it in our day-to-day work. A good leader, Scrum Master or agile coach can really make a difference on a team. Well, when we look at the evidence it is hard to find studies that suggest a cause and effect relationship going from a leadership style and leader’s traits to great team results [1]. Professor J. R. Hackman says that the reason it is hard to find is maybe because it does not exist[2]. On the other hand, there is evidence that seems to point in the opposite direction. The studies suggest that great teams will bring about great leaders and not vice versa. The often-incorrect linking of a team’s performance to the leader’s style or traits is called the “leader attribution error”.

The available evidence about motivation was also a real eye-opener for me. Recently a client of mine called me up and wanted to discuss one of her teams. Her team seemed not motivated in improving; the teams said something a long the line of “we are doing great and there is no need to change anything…” The team was clearly inside a happy bubble [3]. She asked me “how can I motivate my team?”. Unfortunately I had to answer that she couldn’t motivate her team. The reason is probably not about her or about her team lead. Changing the team lead for example would probably be a futile action because people can only motivate themselves [4]. The desire to do something cannot be imposed [5]. What you can do is align personal goals with organizational goals by using the employee’s own need for fulfillment as the motivator.

The evidence seems to be there, but it is hard to accept that a leader’s traits and style has little influence on a team’s performance. Maybe even harder is accepting that you cannot motivate people directly, especially after watching Al Pacino’s motivational speech in the movie ‘Any Given Sunday’ [6] 

To me this evidence is freaky and hard to accept, but what can we do?

Just like when adopting agile principles and techniques for improving your business, the thing you can do is to create the conditions necessary for great team performance and great leaders to emerge. (There are numerous models you can use for that.) In order to avoid adopting the wrong thing, you could collect evidence about results and act based on that evidence. A way to do that is to use EBM and face the truth about what works and what doesn’t in your organisation.

References

[0] Evidence Based Management, J. Pfeffer & R. Sutton. Harvard Business Review.

[1] Leading Teams, J.R. Hackman – 2002

[2] What makes for a great team http://www.apa.org/science/about/psa/2004/06/hackman.aspx

[3] Scrum Pattern: Beyond the Happy Bubble. https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/beyond-the-happy-bubble.)

[4] The human side of Enterprise, D. Mc Gregor – 2006

[5] Punished by Rewards, A. Kohn – 1999

[6] Al Pacino motivational speech, https://www.youtube.com/watch?v=_b7bgtu2O4E