Manage the agile team with XPlanner

Scope, design, build, test, deliver, apologize. These are the oft trodden steps of a traditional engineering methodology when applied to the mercurial world of software projects. As a software developer you’re probably well acquainted with that “final” system requirement that seems to duck and weave like a prize fighter. Perhaps you’ve toiled on a development project only to emerge months (or years) later to face a customer who seems profoundly disappointed that its real needs haven’t been met. Perhaps your peers are at the point where a meticulous long range development plan placed before them instills a sense of impending doom. Bottom line—your team is ready to go with agile development, but has your traditional team management tool been hardwired for traditional team management?

The agile methodologies may be lightweight, but they are highly disciplined. Any tool that supports you in planning and tracking rapid deliveries with intimate customer collaboration can make a valuable addition to your arsenal. The good news is that several such tools are now available to the agile team. This article details a real-world experience in managing an agile development team using one of this new breed of tools, the open source XPlanner.

XPlanner is a Java Web application designed to support team management according to the extreme programming methodology (XP). However, we have found this tool to be flexible enough to provide valuable support for other mainstream agile approaches (e.g., Scrum) in the heat of project delivery. Although unsophisticated, XPlanner provides a handy tool to support your team whether you are experienced with, or just launching into, the rewarding world of agile software development.

Traditional vs. agile team management tools

Traditional team management tools (such as Microsoft’s Project) are based upon work breakdown structures that look far into a project’s future. Planned allocation of resources and a careful eye on variance to baseline are used to manage the “critical path” to final delivery. The application of such tools implies substantial upfront planning efforts, rigid task dependencies, and a stable base of requirements. Significant changes to scope or requirements are likely to necessitate significant revisions to the model. Thus, these traditional tools are most appropriate when planning a journey from A to B, assuming little variation in course. In contrast, agile projects are geared to expect change, making no assumption that B is even to be the final destination.

In understanding the culture of the agile project, it is useful to consider the tenets of agile development as espoused by the authors of the Agile Manifesto:

• “Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation

• Responding to change over following a plan”

  (Kent Beck et al., 2001)

Thus, agile projects explicitly abandon long-term planning in favor of intimate stakeholder engagement, clear focus on high value features, and releasing usable software early and often. The underlying goal is to simply and effectively deliver value in the face of constant change. For a planning and tracking tool to be valuable in this context, it must be congruous with these values.

Project planning and tracking with XPlanner

XPlanner is an agile project management software tool available under the GNU Lesser General Public License (making it “free, as in beer,” in open source lingo). The package deploys as a Web application, which allows your team members and project stakeholders to get on board by using their favorite Web browsers. Once configured, you will be able to plan and track various aspects of your agile project’s delivery via a simple Web interface.

Crucially, from the agile perspective, project participants are able to directly collaborate by contributing their information into the common project repository. This collaboration can involve customers describing project requirements in the form of user stories, which developers then use to detail and track the tasks required to make these stories a reality.

In addition to supporting this level of customer collaboration, XPlanner provides other handy features that support the agile approach. These include features such as a simple mechanism for defining project iterations; an intuitive interface for individuals estimating and tracking effort; and charts for publishing team metrics. XPlanner is discussed here as it was deployed to support the delivery of an electronic commerce and workflow system consisting of several stakeholder groups and a team of seven developers.

Downloading and installing

XPlanner is a pure Java application that may be deployed within any J2SE 1.4 development environment equipped with Apache Ant and a suitable servlet engine. We chose Apache Tomcat as the servlet engine; however, any engine compatible with Servlet 2.3 (or a more recent version) should do. XPlanner ships as a file archive (zip or tar.gz) which you must unpack and build prior to deploying and using the tool.

A mandatory configuration step is involved as you need to set up your favorite database to be used as the repository for project information. As XPlanner uses the Hibernate object/relational persistence layer for database interaction, you have the option to use any Hibernate-supported database for your project repository. The bundled option is the lightweight Java database Hypersonic (now called HSQLDB); however, we used Oracle 9i as our repository database. To configure this database, we had to edit the file xplanner.properties by uncommenting the already defined Oracle properties. We also needed to modify the build.xml file to incorporate the Oracle thin database driver. Once configured, you may build your XPlanner deployment. This involves executing Ant to produce a deployable Web archive (WAR) as follows:

 ant install.db.schema
ant build.war

Deploy the resulting Web archive file (xplanner.war) to your servlet engine of choice and then browse to URL http://your-server:your-port/xplanner/ (using default user “sysadmin” and password “admin”) to inspect the results!

Integrating with your ecosystem

Most development environments already contain a bug-tracking system, collaboration forums, security systems, standards repositories, etc. Although useful as a standalone tool, XPlanner’s value can be enhanced via its simple and powerful integration features. XPlanner includes, for example, the ability to support rendering of developer speak in a description field, such as bug:1001 as a link to http://mybugzilla/show_bug.cgi?uid=1001. This can be done by simply adding twiki.scheme.bug=http://mybugzilla/show_bug.cgi?id= to the xplanner.properties file. This same technique can be used for other Web-based tools such as viewcvs (xplanner.properties shows some other examples). XPlanner also features an advanced wiki formatter (not used on our project) that allows automatic linking to wiki entries. More information on XPlanner extensions can be found in Resources.

In most organizations, invariably, some form of LDAP (lightweight directory access protocol)-compatible directory server provides a centralized repository of user security accounts. For example, within the organization sponsoring our project, an old-fashioned but functional LDAP server served this purpose (Microsoft’s Active Directory also largely supports the LDAP protocol). It was refreshing to find XPlanner’s simple XPlannerLoginModule easy to integrate with LDAP. This involved updating xplanner.properties as follows:

 
-> Comment out default security
#xplanner.security.login.module=com.technoetic.xplanner.security.XPlannerLoginModule
-> Uncomment and edit the LDAP entries from...
xplanner.security.login.module=com.technoetic.xplanner.security.jndi.JNDILoginModule
-> ...to:
xplanner.security.login.option.roleSearch=(uniqueMember={0})
-> Add user search entries
xplanner.security.login.option.userBase=ou=people,o=person
-> And blank out values for
xplanner.security.login.option.userPattern=
xplanner.security.login.option.userPassword=

With a quick rebuild and deploy, XPlanner authentication security was fully integrated. The only drawback was that usernames still needed to be explicitly added into XPlanner, but at least password and group membership hassles became the corporate helpdesk’s problem.

Team, meet XPlanner

XPlanner views a project according to iterations, user stories, and tasks. As prescribed by the Agile paradigm, any XPlanner-managed project is planned and tracked according to a successive series of iterations. Each iteration consists of a start date, an end date, and a collection of user stories to be engineered from story to reality within that timeframe.

A user story is the chief conceptual tool used in agile development to communicate customer needs to software developers. Once a user story is assigned to a current iteration (as part of release-planning via XPlanner), the developer seeks further details for each story by collaborating with the user (hopefully face-to-face). This step’s outcome is a detailed series of development tasks, each of which the developer registers in XPlanner against the relevant user story.

We chose our e-commerce workflow project to run with monthly iterations, each consisting of around 10 stories, with 10 to 15 tasks assigned to each story.

Harvesting user stories

Each user story for a project iteration should be a short and outcome-focused description of a user experience as told in the first person (e.g., “I then search based on color…”). This experience is penned by a user who is envisioning the ideal future product in action, so you might think of a user story as positive visualization for software! The goal of each visualization is to provide enough information for a software developer to estimate the effort required to make that story a reality.

XPlanner catalogs your project’s collection of user stories, while recording a customer, tracker, priority, and effort estimate against each one. The chief difficulty we often find is the harvesting of high-quality user stories from the minds of system users. This was certainly the case for our project, as it was a significant paradigm shift from the rigid section/subsection requirements the users were accustomed to. However, the ability to use XPlanner to manage stories such that they could be easily seen and updated by stakeholders, and to be quickly traded in and out of a given iteration, certainly helped. One nice, if not functional, feature of XPlanner is the authentic feel it gives a user story, displaying each on screen as a look-alike 3-by-5 index card, as shown in Figure 1.

Estimate and record effort

Agile development prescribes that developers undertake their own goal setting, which involves analyzing a user story and defining the technical tasks required to realize that story. A developer should be free to add additional tasks or modify existing tasks as further story details become available. XPlanner supports this flexibility by providing developers with full access for defining and editing a task. Each task can be assigned a type, such as debt, feature, or defect, to characterize the kind of work being done (debt, for example, is a task for cleaning technical “cruft” left in the system from a previous iteration). Tasks are also specified with a disposition (planned or unplanned), the accepting developer, a work description, and an estimate of the number of ideal hours required to conquer that task.

XPlanner makes it easy for a developer to record how much work has been invested in a given task or to update the original effort estimate (the original is still stored). Note that effort estimates, as mentioned, should be specified in ideal hours. An ideal hour is an hour in which the developer experiences absolutely no interruptions.

Developers should also record the number of ideal hours they invest against a given task. If you encourage your developers to honestly record ideal hours (by not demanding to know where the time is going), you will be able to extract some useful metrics from XPlanner (discussed below). We found, for example, that, on our project, an ideal hour took about 1.4 elapsed hours to achieve. This information can then be used to provide refined estimation for subsequent iterations—which helps to keep the team’s promises and the customer’s expectations in the same ballpark.

Metrics and planning for the next iteration

You’re midway through an iteration and the boss wants to know “how we’re looking.” A well-worn response to this question is “We’re about 80 percent of the way there.” Of course, that last 20 percent always seems to take vastly longer than it should—the last 20 percent being the software equivalent of the dull vegetables at dinner that you were leaving until last.

To avoid this tendency for “80/20 optimism” in your project, you’ll benefit from having honest project metrics on hand. A metric is a measurement of some aspect of your project. A project progress metric is a particular measure specifically intended to track how far you’ve come and how far you have to go. A common progress metric in the agile world is the burn-down chart (see Figure 2), which is a graphical metric pioneered by the Scrum methodology. The basic burn-down chart plots hours of effort remaining versus time. The effect is to immediately convey important trends in your progress that will illustrate, for example, how achievable the deadline is looking. XPlanner is able to produce such a chart on demand for your iterations.

Trick for the wary

One of the common issues surrounding iteration planning is the handling of story overrun. Stories initially estimated and scheduled into an iteration are often found to be too expensive (in terms of effort) to be achievable in the current iteration. The team may entertain the idea of extending the iteration time frame; however, this breaks a core agile principle and, in fact, seems to break XPlanner’s charts.

A more appropriate solution (suggested on the XPlanner site itself) is to move the story into a future “pseudo-iteration,” which serves as a holding pen for planned but unscheduled stories. The story can then be easily relocated into a current iteration as priorities demand.

Quick, the boss is coming!

If you happen to work in a progressive environment, then, chances are, your boss will get on board with whatever tool your team fancies. However some more conventional organizations will want clear justification for any new software that appears on the radar. So here are our favorite benefits of the XPlanner tool in the context of agile team management:

• It’s free
• It’s simple to install and use
• It’s Web-based (stakeholders can view your progress using a Web browser from the other side of the world)
• It quickly gets everyone involved in team management—empowering users and developers alike.

If your boss prefers to invest in something with a price tag and a warranty of sorts, then you may wish to investigate commercial options such as Rally, TargetProcess, or VersionOne, to name but a few. For us, XPlanner proved to be so effective and lightweight that we didn’t feel the need to move to a showroom model. Of course, if worse comes to worse, the handy “Export to Microsoft Project” feature in XPlanner will prove invaluable for those last minute Gantt chart meetings.