Free Project Management Software

As many of you know, velocity is a valuable agile metric that allows teams to gauge how much work they can accomplish in a single cadence. Since agile asks that teams estimate the effort required to complete a story rather than the time it will take, teams assign effort estimates to stories, i.e. abstracted valuations which can be expressed as t-shirt sizes, “headaches,” or any other measure agreed upon by the time.

Over at InfoQ, Chris Sims reports on the notion of “good velocity,” inspired by a question Buddha Buck posed to the XP list serve: For a team of about seven, doing two-week sprints, what range of velocity would be considered ‘good’? Amazingly, Buck identifies a ‘bad’ range, explaining that a velocity of eight or less probably means a team isn’t breaking its stories down into small enough chunks.

Now, if a team’s velocity is determined by estimations, using a scale agreed upon by the team doing the estimating, how can an outsider evaluate if the team’s velocity is “good” or “bad”? Certainly, if a team’s velocity increases over time, demonstrating ongoing performance improvements, that’s good. If a team simply gets worse at working together over time, reflected in a waning velocity, then that would be clearly bad. But the notion of a standard or an acceptable range is ludicrous. Velocity is useful for the teams estimating their work—they understand what a “Small” story looks like versus an “Extra-large” one. And depending on how they choose to estimate their stories, a velocity of eight might actually be a hyper-performing team.

So, to summarize, what’s actually important with velocity is whether a team’s velocity increases or decreases. There’s no standard for performance, since there’s no standard of measurement. But a team that does more every sprint should certainly be considered to be within a “good” velocity range.

It seems that agile and Scrum are just continuing to gain popularity and visibility. Now, Inc. Magazine has a success story on how one company’s agile transformation has them behaving more like a start-up, i.e. using small teams to work more collaboratively and responding more nimbly to emerging developments. According to the article, as Chicago-based Total Attorneys grew from a start-up of four to a company of more than 100, the maker of CRM software for law firms decided to implement a more formalized development strategy. They turned to waterfall. But soon, they realized that the development process had become so fragmented that coders handling different aspects of development (i.e. design versus testing) never saw one another and morale started tanking. Also, CEO Ed Scanlan explained, “We had more than a hundred employees, but we were getting a lot less done than when it was just me and three other people.”

Scanlan’s reaction was to implement agile management practices. He divided his employees into small groups of roughly five or six people per team; re-imagined the floor plan so that all employees sat together for convenient collaboration; and mandated a daily Scrum meeting, when team members can report to one another. Because the team harnessed agile’s iterative and incremental approach to development, it was, significantly, able to shorten deadlines and deliver software more rapidly.

While I like to see case studies of how companies have used agile techniques to improve their own processes, there are a number of sticking points in this story. Namely, it sounds like Total Attorneys have applied a “Frankenstein” approach to agile—they’ve pulled their favorite bits from a number of frameworks and methods and built a monster out of them. Granted, this is a populist publication that is effectively introducing readers to the concept of agile project management, so we can’t realistically expect the reporter to engage the nuances of agile the way we would here on this blog, where we’re all well-versed in Scrum, XP, and so on.

How does this article strike you? Is it another victory for agile in the media? Or is it represented in a harmful way?