[Back] [Return to Main Page]
We, the editors, feel that among the first documents to be made available should be a general "philosophical" treatise regarding PrjPlanner as an Agile project management tool.

Update months later: Of course, no philosophy is ever completed nor complete -- or so we like to justify that this document is incomplete.

We realize that there are many tools available, among the most popular seem to be: VersionOne, Rally Software, ScrumWorks, and XPlanner. The editors, at great personal expense and to your great personal benefit, have watched any flash tours available or otherwise reviewed introductory material in order to assess the state of Agile project management software from the developer or first-level manager perspective.

Ok, slight digression and even some admissions follow. The editors are not high-powered managers, project leads, gurus, or otherwise part of any gangs. They (we?) are lowly developers, living within these bureaucracies, pestered to manage better, and continually asked our status and are "rolled-up" into project indicators which hardly help us to be more effective. As one of the editors was overheard saying: "Project management systems should be ones developers want to use to better organize their time. They should not be used as a tool for management to organize developer's time."

So, as far as the editors can tell, these Agile project management systems are not for us. They are in fact huge beasts! They are complicated (vs. complex! Remember your Zen.) They are, to us, the old time punch clock to record our hours worked. But we need a much more light-weight system. We need a system to take that quick email to "please make the help menu more blue" and make a task of it, track it, and finish it. Let us then take each one in turn.


According to the product overview it is a: Ok, then, let us see the tool. This is a "requirements planning & management" screen. Ugg: Busy, busy, busy. And here is an iteration planning screen. Ouch! VersionOne is not off to a "simple" or "intuitive" start, in our humble opinion.

But that is alright, these are high(er) level planning phases. Developers themselves are probably not working in these screens; they seem to be more for the product managers who dig that stuff. So what does the application have for developers? They have something called "My Home". (We note that in the tour, "My Home" is explicitly called out as the developer's interface into the system.) Your editors are flatly floored. 12 tabs! Really, 12 tabs. Currently we are viewing the summary for Andre Agile (3 stories, 11 tasks, etc.) And where is his progress indicated? A little green bar (among other green bars). And how does his progress break down to those 3 stories and 11 tasks? We can not tell. "My Home" does not seem to be a quick information radiator, nor provide for easy status updates.

In summary, your editors do not feel VersionOne is light-weight for developers and first-level managers. We think you will agree.

Rally Software

At first glance, Rally's solution seems equally as impressive as VersionOne. Their system is also meant to manage the a complete program, with many projects, with many iterations, etc. Once on the product page, we were given links to more detail, 2 screen shots, and a tour. The first screen shot covered release planning in the tool. We have to admit that after VersionOne, it seemed much less busy and it is. But it is relative. The next screen shot seemed to be their PROJECT mode, and tabs were back. We were viewing a dashboard for an iteration's status. But we just could not determine its status. Admitedly, a chart was covering a good portion of the middle of the image, but it was the burn down chart. Still, amongst us, we could not tell the iteration's progress or how complete and/or correct the iteration's task were.

So, before taking the tour, we clicked to the "Agile Project Management (Release Planning & Iteration Tracking)" portion of the product. Here we find sections for "Release Planning & Tracking" and "Iteration Planning & Real-Time Status". While we would sorely like to comment on the uselessness of the given screens for developers, we will confine ourselves to the final section: "Personal Workbenches". Rally asserts that these "workbenches" are a "light-weight environment" allowing developers to "increase[] their time spent coding and testing" instead of "managing tools and reporting status". Perfect! So, what do the screens look like? Attack of the tabs!! And notice that each tab has sub-screens. Estimate an average of 3 sub-screens per tab gives 15 total screens; each nice and busy. Come on! No way is this a "light-weight environment".

But, because your editors spared no personal pain, we boarded the tour for Rally. Meet your two new best friends: Lauren and Drew! They (self-described): "know and live Agile". According to Lauren, the "Iteration Status Dashboard" "unites project critical information into a single collabrative environment". Yea. Lauren says that everyone can see the project's status from the dashboard. Probably, but no one is going to -- certainly no developers. Drew informs us that Rally's "Home tab gives team members" a "low burden" way of "signalling their status to the team". And how do they do this? Yep, through effort spent and effort remaining updates. And we are going to have to diverge from what seems to be a consensus within the Agile community that effort (eg. burn-down) charts are useful -- for developers. Developers neither care if the trend line shows that the project will end on schedule nor derive any real knowledge of a project status. OMG!! Did they just say that developers do not care about their project's schedules?!? Pretty much. Agile developers are not interested in schedule because there is no scheduled "final" delivery. There is only iteration 1.0 two weeks after iteration 0.9.9. Why celebrate? Or another way, we celebrate every two weeks. Whichever, whatever. Agile developers enjoy the process; they enjoy their team and their customers. Agile developers are not looking for the big payoff at the end; one that somehow makes up for the misery of high ceremony centrally-planned methodologies. We want the daily gratification of test-driven development, paired programming, and iterative deployment. This is why effort charts are not desirable indicators to developers. And talk about making a developer feel like a cog in the machine! Effort tracking and trending is nothing more than high-tech time-cards. It is both impersonal -- hence antithetical to Agile -- and useless for developers. This is exactly what Rally's "Team Status Dashboard" does, as explained by Drew. He tells us "Team Status Dashboard" "easily balance the workload for the current iteration" "plan intelligently based on team capacity" "easily ensuring that team members are not over or under committed within the current iteration" "" "" ""




SourceForge.net Logo
[Back] [Return to Main Page]