Test automation can turn into a real pain in the neck if a designated team is in charge of it or if the automators work on it as a separate project. In this article, Lisa Crispin seconds Bob Jones’s recent call for whole-team test automation and elaborates on the dangers of relegating test automation to an isolated project rather than integrating it into the overall software development process.
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.
This is a product development organization with developers in Italy, testers in India, more developers in New York, product owners and project managers in California.
This organization first tried iterations, but the team could never get to done. The problem was that the stories were too large. Normally I suggest smaller iterations, but one of the developers suggested they move to kanban.
In this second part of a two-part series, Mario Moreira explores the back-end disciplines of a lifecycle that establishes an ALM framework centering on customer value. If your organization has adopted agile and you are looking at building your ALM framework, consider an infrastructure and tooling that will help you establish and build customer value throughout the lifecycle.
Examine the common sources of errors in product development activities. By being aware of the things we can change in our environments, we can reach our goal of preventing errors. Then, a number of techniques can be employed in order to help teams work towards a zero-defect goal.
Too many managers believe in the myth of 100% utilization—the belief that every single technical person must be fully utilized every single minute of every single day. The problem with this myth is that there is no time for innovation, no time for serendipitous thinking, no time for exploration, and it often leads to a less successful organization.