Free Project Management Software

With the floundering economy weighing on everyone’s minds (including my own), I came across an interesting piece on InfoQ (http://www.infoq.com/news/2009/01/agile-layoffs) by Mark Levison that actually takes a look at how one Scrum team reacted to the effects of the recession. In this case, Adrian Carr shares how layoffs left his team with only four members and no dedicated Product Owner, while he played the ScrumMaster role on a part-time basis. According to Levison, his first pass at revising the framework for his circumstances looked like this:

• Keep just the parts of Scrum that make sense in a smaller group: daily standups, short sprints, reviews, retrospectives, visible project burndowns.
• Everybody on the team takes on some of the Product Owner role meeting with stakeholders, end-users etc, but Adrian will maintain the product backlog and make final decisions etc.
• Eliminate waste.
• Keep things as simple as possible.
• Take credit for story points only for features deployed to production, the expectation is that this will force the team to create smaller more manageable features. This should lead to a reduction in cycle time and provide more feedback.
• Work in very small batches of work – only two to three items at a time.
• Focus on delivering the highest value items first.
• Know who the software is being developed for. Know their names, their roles and why they the things they do.
• Watch for external factors that slow the team down and hammer away at them.

Over at InfoQ, they provide expert opinions from three Scrum practitioners. Robin Dymond worries about the lack of a Product Owner; Mary Poppendieck argues that, in a case like this, a clearly defined, common goal is more important than a Product Owner; and Ron Jeffries fears that, without a Product Owner to serve as a go-between for the development team and the business unit, a lack of clear communication could hamper the project.

There’s no question that a situation like this makes practicing Scrum very, very hard, if not impossible. It might require a full-scale reorganization of employees into normal-sized, functioning Scrum teams. Or it might require, as Adrian suggests, that the remaining individuals share the roles.

How would you have responded to this challenge? Have any of you been forced to make these hard decisions due to layoffs? I’d love to hear how some of you are coping with this in the comments section.

For many Scrum teams, “work” is what’s documented in the Backlog. If you’re like me, you can’t help but hear agile guru Jeff Sutherland’s famous remark that, “If it’s not in the backlog, it doesn’t exist” in your mind. But that’s not quite true. Even Scrum teams have work they should commit to as repeatable, maintenance-oriented tasks that occurs each and every sprint. One of the most important of these activities is backlog grooming. Ken Schwaber recommends that teams devote five percent of their time each week to this activity (about two hours per week). In spite of this mandate from the top, many Scrum team members continue to resist. The perception is that any work that deviates from one’s primary job function is extraneous . So software developers, for example, often hold fast to the idea that their time should be only spent writing code.

But here’s the thing: It’s all work. The work a team does each sprint to ensure that it can hit the ground running on its next set of sprint goals is no less essential to the team’s sustained performance. Even if it forces a developer to stop coding for two hours each week, what that “downtime” enables outweighs whatever code could have been written in the same amount of time. In short, this activity is like a pit stop for a racecar: A brief preparatory break that enables the team to keep going at full speed.

If team members are still reluctant to acknowledge grooming as part of their regular workload, then I’d suggest creating a repeatable story that can build this maintenance into the backlog each sprint.