Product Managers often forget that they can make or break a project. If your team is using Scrum that is even more true, because Product Managers are (or should be) involved regularly in the planning of the work with the team. Either as Product Manager or in the role of Product Owner.
It is therefore very important to carefully craft the messages that the Product Manager gives the team. It took me a while to understand this simple message, and this is my story.
As a Product Manager I was eager to give the team direction and clarity on the goals for the product. I communicated regularly with the team with more information on the market, the product, the customers and generic feedback on the direction they were taking.
Eager to achieve the goals we had set for ourselves the team was churning new features at a very good pace. Then the bomb hit. Every time we were supposed to go to production we faced major hurdles. The Retrospectives did not point to anything that could cause the quality problems we had, so I went on an investigation. Why was deployment to production so hard to this team that was delivering features at such a good pace (uncommon for other teams at that time)?
As a Product Manager I had to forget about what I wanted and had to concentrate on finding the root-cause for the problem. I interviewed the developers but nothing I found would explain the situation. The team was testing regularly in their environments and they were practicing Scrum "by the book".
It was then that it hit me. Having a conversation about the development process with one of the developers I understood that they were neglecting their unit and integration tests, which in turn led them to have a long feedback cycle for integration (some days only, but still too long).
After I heard that, it was fairly easy to trace the deployment problems to the lack of automated, fast-cycle integration testing. In their eagerness to deliver more features the developers would be developing up to the last day and would not have time to do the integration testing for those last changes. In turn, that led to many problems when it came to deploy.
Through that conversation I realized that the problem the team had was that they were being implicitly rewarded for delivering more features every time I praised them about the new feature they delivered. However, they were not being rewarded for building the unit and integration tests that would prevent the quality problems.
The end result was that quality-sustaining practices were being neglected. Having understood that, I changed my communication with the team. From that time on I started asking them if they had the integration and unit tests for every feature they delivered and started giving them praise for delivering tested features, not just any feature.
Before this happened to me I was not aware of how strong an influence the Product Manager's message can have on team behavior. "They are the engineers" - I thought - "they should know what they need to do". It's not that simple!
Photo credit: pcalcado @ FlickrLabels: product manager, quality, release, retrospectives, testing
