Rather than rely on large handoffs between specialties, high-performing Scrum teams learn to do a little bit of everything all the time during a sprint. To do this effectively, teams must make three changes: shift from writing about requirements to talking about them, reduce the size of handoffs and make them more frequently, and pay more attention to the size of the product backlog items that they bring into their sprints.
This article explains methods to build a team that will embrace "required work" and deliver robust software in a predictable fashion. It proposes a measure that helps calculate the throughput of an agile team by comparing work committed to work actually done.
What makes a team agile? Is it in the way it plans projects or how it engineers its products? In this article, Steve Berczuk explains how agile code and technical practices can help a team stay agile across the product lifecycle.
Many new products being developed require the contribution of artists and other such "creatives," but artists often view the creative process as an organic thing that cannot be analyzed, dissected, or reduced to a set of defined practices without killing it. This article explores barriers such as these to the introduction of agile methods and how these barriers can be overcome.
In part one of our Learning for Agile Testers series, we addressed general "thinking" skills that go beyond technical competence and how learning these enhances the value you contribute. In part two, we discuss some specific technical skills that benefit testers and how to acquire them.
Analysts determine what needs to be created. Programmers create it. Testers find the holes in the work of both. That's one way to do it, but all three can collaborate to do these things better, and more easily, too.
Most software needs to be "maintainable" and have high "internal quality." But what does that mean in practical terms? Code smells form a vocabulary for discussing code quality and how well suited code might be to change. The smells also provide good indications as to what to refactor and how.