About when I stopped worrying and embraced Engineering!

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 @ Flickr

2 thoughts on “About when I stopped worrying and embraced Engineering!

  1. Vasco, good story, sad story and so real! I have same kind of experiences in my organization. What matters is that The Release must be done on time and with the agreed content. When The Release is out (late of course due the integration and quality problems) no one never asks from developers: “Great job that you managed to implement all required features but how did you do it? Can we release next version too (on time)? Did you write your code so that it is maintainable?” And so on.

    Next releases are then harder to deploy when then comes a day when someone says that “we cannot add easily anymore new features or make changes so I propose that we redesign/rewrite it” and story goes on.

    Where is the sw development craftsmanship/professionalism that Uncle Bob demands too? Why product manager has to ask team to write unit and other tests? Or use CI? It cannot be only lack of competence or skills.

    Your story raised following questions:
    – Has team defined DoD?
    – ScrumMaster role is important in this kind of “cases”, or what do you think?
    – Any idea why they did not find this problem in their retrospective meetings?

Comments are closed.