For a typical small agile team of five or so people, managing ongoing work is often just a matter of arranging...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
index cards on a convenient table. These cards may represent stories or tasks or defects or any number of other activities for which the team is responsible. As the team grows, they may trade in the index cards for colored sticky notes on a large whiteboard. But at a certain size, such mechanical means of managing ongoing work becomes unwieldy, and more sophisticated tools are required. This is even more important when the agile team has remote members, people who are not in a position to see or touch the physical objects that represent the work.
Flexibility in Agile workflow management
Agile workflow management tools go by a number of names. They may be called collaboration tools, or possibly project management tools, or application lifecycle management (ALM) tools. I know of one distributed agile team that uses a highly-customized wiki to manage their work. Regardless of how they are represented, such tools allow large agile teams to manage their work in whatever way the team sees fit. The one thing that all of these tools have in common is that they are all highly configurable. This is extremely important; one of the key aspects of agile working is that the development process must be flexible enough to respond to ongoing feedback from the team.
An agile team does many kinds of work simultaneously. At any given time, an agile team may be engaged in ongoing work with creating stories, creating tasks, coding software for stories, reviewing code, reviewing stories, testing code, deploying environments or monitoring the production environment. Every team is different, so the kinds of work to be managed vary widely from team to team.
Of course, with physical cards or sticky notes, it is a fairly easy thing to change a workflow or to work in a new way. Using a software tool to manage such work poses several risks. For one thing, the nature of a software user interface makes it difficult to delineate grey areas, such as when code might be being developed and reviewed simultaneously, or when a story might be partially coded but is being tested during the ongoing coding effort. The greater risk is that without conscientious management, such tools can make it easier to create information silos, where only the product owners interact with the ongoing stories, only the developers interact with the finished stories, or only the testers act with the completed coding tasks.
The importance of transparency
There are two important practices to prevent confusion about grey areas and to prevent information silos in the ongoing work.
For the sake of discussion, let us call each bit of work for the agile team a "card." In the agile software management tool itself, the card may be a colored square, or a link to a web page, a tag on a wiki page, or some other abstract representation. The representation of the work is itself not important.
What is important is that every card be available to every member of the team equally. Everyone on the team should be able to see each bit of work at all times, along with the ongoing status of that work. One of the great advantages of agile working is that everyone on the team can and does give feedback at every stage of development. Testers should be able to comment on stories in progress, just as system administrators should be able review code in progress. Even though a card may be assigned to a particular person or to a particular group, it is critically important that everyone on the team have full access to every aspect of the work of the whole team.
Break down silos by practicing a “whole team” approach
The complementary concern is that the work not be exclusively assigned to particular silos of activity. At first glance, these agile management tools tend to imply that stories in progress are solely the responsibility of product owners, that stories in the development queue are solely the responsibility of developers. The team's workflow needs to be more expansive than that, though. Here are two examples:
One example is that a tester may look at a card in the development queue and realize that what is being coded does not match the description of the story. Even though the card is not in the "testing" queue, the tester should be in a position to move the card from the "in development" queue to the "story in progress" queue, with an appropriate comment such that the development staff and the product owners become aware of the issue immediately. Note that this action by the tester does not interrupt the flow of work; this action of moving the card back in the queue simply provides one more piece of critical information to complete the story correctly. The ongoing conversation among the team itself does not change.
For another example, I know of one team that distinguishes between defects found in the testing of an ongoing story and defects found in code already released. On this team, only testers typically (although not always) report "story problems" that are linked to particular cards in the team's ongoing work. But on this team, problems with the code in general are typically reported by everyone on the team as they are discovered.
Large agile teams and distributed agile teams are becoming more and more common. The tools to manage the work of such teams are becoming more and more sophisticated. But it is up to the team itself to manage their own workflow in these tools in the most agile way possible.