I left a comment in a LinkedIn group that people seemed to like so I'm putting it in a blog now.
The discussion was about testing time getting squeezed by the sponsor and PM as extension of that in many (non-agile) projects and what the Test Managers responsibilities are.
If you ask the team to prepare a cake for twelve but only buy ingredients for six you only have a few options. Either you reduce the number of people. Or everyone get's a slimmer piece. Or someone goes out and buys more ingredients. I'll let you work out the infamous Project Management Triangle for yourself..
And yes, there are more options like extending the dough with other materials, fake more cake by making it shallower but with a bigger diameter, etc which would be options that a clever and motivated team may come up with.
My point though is that it's not the Test Manager who takes on sole responsibility when the customer doesn't like the cake. If you shorten preparation time you'll find some lumps at the end, no question about it.
Quality of the software is a team effort with the sponsor / owner and by extension the PM setting the boundaries. It is up to the Test / Dev Manager to then speak up and describe what the practical effects of these boundaries are but that's where it ends.
With a good team a lot can be done to find out what it is that is really required and how to get there. And hey, at the end there may be cake for everyone involved.
Long ago, we used to phrase it another way: "Good, cheap, quick: Pick any any two out of three." Without the deep discussion between the waterfall test manager and project manager, one of the three legs of the stool would inevitably be forgotten - resulting in a sudden crash at the end. Aaaah, now I know why they called it waterfall! :)
ReplyDeleteThis is an interesting comparison. In waterfall, the discussion would center on holding quality (scope) constant. Then, it boils down to estimating and tracking the schedule based on a sane level of effort from the team. (That is until scope creep inevitably rears it's ugly head.)
The advantage of agile (little "a") projects, is that they generally hold schedule constant (e.g. in sprints). The discussion is naturally shifted to estimating and tracking scope for each sprint. Scope creep is then addressed as a part of the more frequent planning sessions.
Nice thought provoking topic!