User>Driven

As I mentioned previously, we are investigating Agile principles at ATG. We're doing a pilot with one project now and planning for another, larger one. I thought others might be interested in the issues we're working through as we experiment with Scrum. The first issue I want to cover is about just getting started.

Many of the problems we are grappling with seem to stem from trying to plan an Agile effort within a more traditional development organization. At my company, for example, projects can last for many months and doc and QA usually join a project already in progress and stay with a project after feature work is done. And unlike most developers, doc and QA folks (especially doc) are often split among several projects at once. So while some team members are ready to start daily scrums, it has been hard to include these disciplines. Our first pilot began scrumming with only the developers and a program manager turned scrum master. The doc person has since joined but is still splitting her time between two projects.

There is a general feeling of wanting to do Scrum "right" with this next pilot, so we've decided to wait until doc and QA can at least be part of the project kickoff where the team is supposed to review requirements and decide which features they can take on in the first sprint. Even then, commitments to other projects will mean the first few sprints in that project will have to consist of tasks not requiring doc or QA, things like tech spec writing and UI design.

At first I was uncertain about this approach. I thought one of the key principles of Scrum was that all disciplines were represented and that features were supposed to be really "done" at the end of a sprint - done as in shippable - which would, of course, require they be tested and documented. Some smart folks at Cyrus Innovation told us, though, that at least in their approach to Agile, it was more about commitments and checking progress on a regular basis than about "completing" features in each sprint.

What you put on your product backlog (the prioritized list of work for the team) doesn't have to be limited to features. The list can include anything the team needs to accomplish to meet the goals of the product. And that can begin with designs and specs. It can also begin with only part of the team represented, it seems, though we do plan to fold all disciplines in as soon as we can.

I'm still not sure how I feel about this, but it seems in resolving the tension between two principles, one sometimes has to take precendence over the other. I will revisit this issue as we move forward with the project and let you all know how we do. 

Next time I will try to talk about scheduling sprints and releases for an Agile project in a traditional organization.