Many people confuse the agile values and principles with the practices that support those principles. Scrum, for instance, consists of a set of practices that have proven themselves to support the agile values and practices. This confusion often leads to judgments that one group or another is 'not really doing agile' because they are not following all the prescribed practices or have modified them in some way. (I've written about my irritation about such judgments before: here and here, for instance).
My policy is: as long as your team understands the agile principle(s) that a practice supports and also understands and accepts the impacts of your deviation from the standard practice, then you're still agile.
In many cases, teams have to adapt agile practices in order to deal with institutional constraints that are outside their sphere of influence. One such constraint at Borland is that all of our enterprise testing (e.g., performance, scalability, integration, localization) is done by our Enterprise Quality Center (EQC) in Singapore--a long way from our scrum teams in Europe and the US.
When I started on Borland's first agile team (in Austin, TX), we had to figure out how to get the enterprise testing done effectively, and done in as agile a fashion as possible. I call the model that we came up with the 'no-more-than-one-sprint-behind' model.
Here's how our product development teams deliver code. Our scrum teams practice 2 or 3-week sprints, with two or three releases each year. Many of our scrum teams deliver code to customers at the end of each sprint--but always just for acceptance testing, not for enterprise deployment. Only releases are designated for enterprise deployment. Also, the last sprint of each release cycle is a wrap-up sprint with little or no new code development beyond bug fixes.
Given these practices, we decided to have two definitions of 'done'. At the end of each sprint, each story is accepted as functionally complete--coded, documented and functionally tested. Enterprise readiness testing is then performed the following sprint. So, at the end of the following sprint--at the latest--the stories from the previous sprint are accepted as enterprise-ready. And since no new stories are completed in the last sprint before a release, this gives the enterprise test team time to catch up.
Some of our scrum teams have gone well beyond (or below?) the one-sprint-behind model. They hand off new stories for enterprise testing as soon as they're done and get the enterprise testing completed well before the end of the following sprint.
The institutional constraint of having enterprise testing done on the other side of the world requires significant compromises to several agile principles, most notably, The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. But our scrum teams continually try to keep the principles in mind and to understand the cost of their compromises. Given the constraint, most of our scrum teams--and the company as a whole--have been satisfied with the results of the enterprise readiness testing.
In another post, I'll share some of the details of how we manage the enterprise testing work in our sprints.
Comments