Not enough cake for everyone?

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.

The discussion and learning about "it" is more important than the definition of "it".

On one of the LinkedIn Groups, Steve Green, who I value a lot both for his experience in exploratory testing as well as a person argued against the use of exit criteria as they are almost meaningless in his experience.

I agree but meaningless doesn't mean useless. Let's say that:

The discussion and learning about "it" is more important than the definition of "it".

While in many cases exit criteria are sacrificed to get a project out of the door I think that it would be a mistake to dismiss them. By trying to write down exit criteria and discussion within the team a lot can be learned about the way software is developed within a given company. When one struggles to come up with an exit criteria that may point to one or several problems.
Are stakeholders not clear? Are decisions made ad hoc? Is planning or estimating a problem?

A discussion about what exit criteria may be realistic and which ones aren't including the reasoning behind it will unearth a lot of important information for the project.

You may end up without exit criteria after all and that's OK. But the important bit is that information was gained and learning happened.

Of course "it" could be anything. Exit Criteria; a bug; a process; a workflow; an approach; a standard. As long as there's learning we have gained something that cannot be taken away.