If you believe in the concept of the tipping point, the migration to agile software development has tipped: according to the latest report on Agile Development Tools by Forrester Research, 56% of the survey respondents use agile or iterative development methods, in contrast to the 13% who profess to using a waterfall approach (the remainder use no formal methodology). These statistics illustrate that agile has gone from a radical, fringe technique to the dominant methodology since the Agile Manifesto was first published back in 2001.
One of the central tenets of the Agile Manifesto is the statement that “We value processes and tools, but we value individuals and interactions more.” Like many of the bold statements that make up the manifesto, this phrase has been misinterpreted to mean that agile developers must reject tools and automation of the development process, and that the use of any tool to assist in tracking progress or managing tasks, other than a packet of sticky notes affixed to the wall, automatically brands a team as “un-agile.”
Like the extreme interpretation of the comments in the Agile Manifesto regarding documentation, which has led to the myth that agile developers aren’t allowed to use pens or paper, this extreme interpretation misses the point. When agile developers decide how much documentation to write, or what sorts of tools to apply, the guiding principle is the same: What’s the “barely sufficient” solution that fulfills the functional need without adding unnecessary process and without sacrificing the ideals of simplicity and flow that guide agile development?
The tools define the project
It’s also important to remember that, for many development teams, as well as their clients and managers, the tools define the project. When I manage projects as a contract PM, my clients often want to see the work breakdown structure, or project plan, usually constructed in Microsoft Project, to demonstrate to them that I’ve thought through the tasks required to deliver the project results. They look for the Gantt chart to see the effort defined against a timeline, and they expect to see written change control documents when the scope evolves. For many managers, the most difficult element of migrating to agile is acclimating to new techniques for planning work, tracking progress, and integrating changes into the project scope. Often, the client’s attitude is “I don’t care what you developers do in your ‘war room’; be as agile as you want in your development activities, but you still need to show me a project plan and a Gantt chart to reassure me that you’re on track.”
The distinction between operational and experimental projects
In addition, it’s important to refer to the agile concepts of experimentation and uniqueness. As Jim Highsmith repeatedly reminds us, agile development is, at its core, focused on fitting the process to the type of project at hand. Operational projects that incorporate existing project plans and produce repetitive results, like the building of the 20th semiconductor fabrication plant, probably don’t require or benefit from agile methods; the development of a new silicon chip design does.
This distinction between operational and experimental projects is key. When we build software or products in an experimental mode, the actual coding or development can’t be automated or “tooled”; only human beings can go through the iterative, speculative process of trying out ideas, accepting or rejecting them, and following their thread to the next unique idea. That’s not to say, however, that every element of the agile development process is unique. Every project sill requires design, testing, integration, and monitoring, and these common elements can be automated, and in fact are being automated by vendors eager to produce the corollary of Microsoft Project for the agile world.
Automation in agile development
In fact, contrary to the myth that agile teams reject tools, agile development calls out for automation due to some of its inherent characteristics. Because stories or features are often decomposed into tasks, and frequently parsed out to different team members for development, the ability to keep the entire team informed on the progress against task and feature development is critical. In distributed teams, this obviously becomes even more important. Frequent testing and integration also drives the need for current information that is easily accessed by team members, so they can understand the status of all elements of the product at any moment. As we discussed earlier, during the migration to agile, managers are often disconcerted by the change in status reporting tools; new tools that can reassure them that they can still keep their finger on the pulse of development are key reassurance factors that go a long way towards easing the transition.
Speed and agility are factors
Both speed and agility also cry out for new tools. In an agile project, in which features, sequences, and tasks can change rapidly, and items can be added or subtracted from the scope daily (or even hourly), the old Gantt-chart-on-the-wall technique won’t work, unless you want to assign someone to put it up and tear it down hourly. Tools that allow for frequent transitions in the plan, and that can instantly indicate what the team has learned about what will or won’t work, are required.
Agile tools
As I noted in a previous TechRepublic column, Scrum and other agile practitioners use different techniques for tracking and reporting than traditional developers. The Product and Sprint Backlog, the Burndown Chart, the Change Report or Delta Table, and other tracking and monitoring tools are obvious candidates for automation; many vendors, from IBM and HP to newer entrants such as CollabNet, Rally Software, and VersionOne, are producing products that offer these capabilities, and more. CollabNet, for example, has a suite of tools that spans the gamut, from its free ScrumWorks Basic package (which offers the foundational capabilities to track and manage a product backlog) to its TeamForge product (which presents a complete team development environment designed for large-scale, distributed development efforts).
Conclusion
This article is not intended as a review of these tools, but instead to discuss the agile drivers and concepts that create the need for new project management tools in the first place. Forrester, in the report noted above, does a great job of evaluating the many vendor offerings in this space and guiding readers through the selection process. Many of these vendors offer free trial versions, or limited-time trials of their complete packages.
Agile teams need to discard the myths that fool us into believing that we must either adapt the old tools or use only whiteboards and Post-it notes to control our project efforts. The agile tool space is populated with mature, capable tools that can make the work of agile development more efficient and visible, without violating the fundamental tenets of agility.
No comments:
Post a Comment