Product Manager versus Quality Engineering Lead

Our concept of agile has a Product Manager (PM) representing the customer. The PM is also active in defining the features needed per release train and in generally working close with the team to define stories and the iteration-by-iteration flow. This thinking embraces Steven Wheelwright’s (http://www.hbs.edu/faculty/swheelwright/index.html) model of the heavyweight product leader and seems necessary ensure we have a train payload that makes market sense. It does present a challenge when combined with the separate notion of a closely-coupled but independent software quality engineering (SQE) team. Each development team (4 to 10 people) generally has two or more engineers charged with the responsibility of ensuring all the features of the train, new and previously developed, have, and continue to have, high quality. This is usually done several different forms of testing with the SQE engineers laying down strategy and developing the tests.

A lead for each train represents the quality side for all product decisions and in specifying work for other SQE engineers attached to the team. These leads hold a fairly powerful position since they can hold up a release if not comfortable with the state of the quality as reflected by test results, defect load, and general readiness of several factors/artifacts. Operating within a strict development timeboxes and having a multi-year history of generally not missing a release (and doing up to 11 a year), the decision to hold up a train release, of course, would be a big decision. Using a sports metaphor, the train goes into a Quality Overtime and means the release takes a day-by-day slip until the lead is ready to sign off. During this time, all members of the team, including all development engineers, report to the lead to ensure the Overtime has the necessary resources. This is consistent with our thinking that all dev engineers report to quality during hardening that may occur before release.

While the heavyweight empowerment for the PM is necessary it can also be a point of conflict if the PM drifts a bit and starts to specify what the SQE engineers’ storycards and tasks. This generally arises from a PM being pushy in wanting to ensure that defects are found as soon as features are completed. We generally meet this situation by reminding the PM that the SQE team has a history of keeping up. So it becomes a bit of reset and enforcement in roles.

There is at least one other, and more complex, reason for this arising. The Lead SQE is generally focused on functional testing necessary to show/ensure feature quality. Other testing, though, may be driven by market needs apparent only to the PM. These may include security testing, stress testing, unique configuration testing apart from standard, and forms of conformance testing. While these are all doable, a PM popping these needs on a SQE team already driven to meet functional quality checks can result in a bit of a breakdown.

Some have observed that this situation is tough on the SQE lead and the gravity is for the SQE to sign-up for more than can be accomplished. A better situation, sometimes requiring management attention from the SQE side to ensure “table balancing” is for the PM to state the market needs and then to come to an agreement of testing and when it might occur: Day 1 before release, Day 2 immediately following release, or Day 3 on customer request. Done early in a train, this type of agreement, sometimes called negotiated quality, is the best situation since the SQE Lead can work to include the additional testing beyond the normal functional test work.

We recently had to work our way through a negotiated quality situation. My default assumption has always been that the SQE Lead is empowered to handle the negotiation from the quality side. Management in Moscow pointed out that that is not always the case as many engineers are good at engineering but not equipped to be good in arriving at a win-win solution. This gets even more so, when the PM is at company headquarters and the SQE Lead is offshore. It probably means that the SQE Site Lead, responsible for ensuring quality activities at the offshore site work well, must now participate in the heavy lifting of getting agreement to the needs. Done right, the SQE Lead for the respective project will participate and become better at negotiation.

An improvement beyond this is to provide training for everyone on negotiation with the emphasis of getting to win-win. I have done this at a previous company and it was helpful in empowering the Leads, giving them approaches and in reducing their being “whipped around” to the PM’s view, but it was not an overnight win. It was, thought, a starting point that did lead to success with lots of re-enforcing the roles by management. It’s important to keep in mind that software development, and especially with agile, is sometimes more about people than technology.