A key element of any Agile process is the "input queue" - variously called "product backlog" in Scrum, "story cards" in Extreme Programming and "feature list" in Feature-Driven Development. It seems easy enough, right? What could be simpler than making a wish-list? But it's not quite so simple, and in fact it's critically important to manage the quality of this queue, and to have a regular cycle for managing it. Failure to do so can result in uneven flow of work, delivery of misunderstood features, half-finished work, or micro-management. All of these dysfunctions reduce the effectiveness gains that Agile teams typically experience.
New teams trying to turn an existing project plan into a feature list immediately run into a problem: the list must be filled with customer-valued features, and the project plan is full of technical tasks like: complete requirements, upgrade to Oracle 10i, implement webservices framework, integration testing. These activities have been, until now, invisible to the customer - and herein lies the "transparency" shift inherent in Agile. Technical tasks are always needed - but Agile teams must justify working on them in terms of a customer-valued feature. So, the first time a feature is requested which must pass through the webservices layer, the team will explain to the customer that the cost of developing this feature requires {list of technical work here}, and the customer must agree to spend their cash on these activities before they can be undertaken.
This has a couple of effects:
- developers must learn to explain their work in terms of customer value - developers learn to understand the customer's point of view
- customers will understand that they are paying for more than just "that button on the webpage" - customers learn to respect the effort and skill of developers
- if the customer doesn't feel the cost is justified, they and the team can sometimes brainstorm a "lite" version that is more suitable, so the team can spend their effort on more valuable features.
- customers and developers are now aligned toward exactly the same goal - customer value. Alignment reduces friction and enables effectiveness.
The feature list is, in fact, a customer-owned artifact, and so should not be filled with technical tasks which, in isolation, produce no customer-valued working software. Management of Agile projects is focused on this feature list, and tasks generally remain the domain of the team itself, as they self-organize to do the work.
Tasks always do need to be done - they are how the value gets delivered. But if a team is working well together, management generally knows not to interrupt and leave them to it, and if the team is not working well together, Agile leaders coach the team to identify and resolve their own problems, always with the goal of increasing value produced. An Agile leader who would mandate or even track team-level tasks would typically be seen as micromanaging.
Jon Kern, one of the 17 creators of the Agile Manifesto, and reputedly "a fanatic about ensuring software development efforts deliver business value," blogged last week on Just what is a feature?
This spurred David Anderson, author of Agile Management for Software Engineering, to talk about his view that sometimes it actually is worthwhile to manage technical tasks as features in Manage Value Creation not Effort Expended. His entry used ideas from the Theory of Constraints to back the unusual position that some kinds of tasks are worth managing.
