teams

One of the biggest management myths is, “I must treat everyone the same way.” Nothing could be further from the truth. Everyone has different goals for their career, and those change over the course of a career.

The saying “beauty is in the eye of the beholder” rings true whether you’re staring at a centuries-old painting, listening to a busker’s music reflect off the tiles in a subway station, or testing software. It’s one thing to evaluate quality, but how do we evaluate how we evaluate quality?

How many times have you seen this in your projects: You need something specific done such as a new database, or a specific user interface designed, or you need a release engineer, or a user interface designer, or a part of the system tested and the normal person who does that work is not available? What happens on your project? Does it wait until The Expert is available?

In this case study of a distributed agile team, the developers were in Cambridge, MA, the product owners were in San Francisco, the testers were in Bangalore, and the project manager was always flying somewhere, because the project manager was shared among several projects. The developers knew about timeboxed iterations, so they used timeboxes. Senior management had made the decision to fire all the local testers and buy cheaper tester time over the developers’ objections and move the testing to Bangalore.