Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Saturday, June 23, 2007

Latest Carnival of the Agilists is up

The latest Carnival of the Agilists is up.

If you haven't seen of these before, it's a collection of links to essays, blog entries and resources on various topics from some of the best minds in the Agile software development community.

The editor rotates, so there's always a fresh perspective on what's worth reading.

Labels: ,

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Thursday, June 07, 2007

The High Cost of Management Indecision

Rob Walling writes about the high cost of management indecision on software projects.

Essentially, the argument is that even wrong decisions allow developers to keep momentum and push a project forward. The cost of reworking areas winds up being less than the cost of delaying, doing nothing, or switching to other tasks. Here's an excerpt about the cost for a team of 10 developers:

If we decide not to make any decisions we lose 10 times $822, for a total of $8,220 per week. Let me say that again: blanket indecision loses $8,220 per week; making decisions (including bad ones) loses $1,680 per week. That's a difference of $6,540 per week.

It's actually a pretty powerful argument for doing everything possible to lower the perceived cost of making a decision for managers or customers. Perceived cost is that fear-driven idea that if you make a certain decision, you'll be stuck with the results forever if it doesn't work out, due to the high cost of changing it.

This is exactly the problem that Agile methods were designed to solve. By reducing the perceived cost, we encourage our customers to make more timely decisions, learn from them, and adjust as needed without incurring high costs.

Of course, this doesn't necessarily apply to technical decision making. "Should I use a database or direct file storage?" is a question that doesn't need a final answer right now. The right question for technical decision points is "How can I encapsulate that?" That lets developers move forward while keeping the cost of future change low.

If it truly does cost more to delay management decisions, wouldn't it be wonderfully freeing to start making some?

Even if you don't have all the possible information you'd like?

Even if you could be wrong?

Labels: ,

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Wednesday, June 06, 2007

Scrum Reference Card

Ran across a useful (and free) quick reference PDF for the Scrum Agile method for managing software projects.

Scrum has really gained some momentum over the last few years, perhaps in part from the now ubiqiutous certification program (Certified Scrum Master). It's a deceptively simple framework for Agile project management, consisting mainly of a few rules around creating a product backlog, priotizing work into 30 day "sprints" or less, daily meetings or "scrums", self-organizing teams, and the key: inspecting and adapting continually to improve based on real-world feedback.

Anyway, here's the link, courtesty of Contrado in Australia:

Scrum Reference Card PDF

Labels: , ,

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams