Agile

Delivering Bad News Early

I was listening to a Controlling Chaos podcast today, and heard this:

Project Team to Executive: “When should we tell you if we have bad news?”
Executive (dumbfounded of a little): “Well, right away of course!”
Project team (Excellent – thanks for giving us permission)

Yes, I think we all realize that it is important to deliver bad news as soon as possible. And the technique above can be useful to gain permission to deliver it early and allow you to understand and negotiate what ‘bad news’ means. Bad news can be found on all projects regardless of methodology – resource changes, customers who aren’t sure what they want, budget risk, schedule risk, etc. The sooner we can identify the bad news and deal with it, the better.

For bad news related to the budget, how do your teams know when you will be over budget or schedule? Traditional project management methodologies use “Earned Value” to measure project progress against a budget. What frustrates me about this method is that until your team has delivered value through working code, your actual earned value is… zero. If requirements or design is complete, what value is that to the business? Does it verify what % complete the project is? Does it verify your estimates? Does it ensure that the business is getting what they asked for? How useful is it to measure the “Earned Value” on a traditional project until that project is complete?

This is my favourite thing about agile. Once your backlog is complete, estimated using relative estimating, and your first iteration is complete with working code you can calculate your initial velocity and compare it to the budget and schedule. After your second, third and future iterations you refine your velocity and with it your cost and schedule. You have delivered value through working and implemented code and you can calculate actual Earned Value based on what you have delivered vs what is remaining in the backlog. In this way, you can verify your project process early and report budget and schedule issues to your executive or sponsor early and more accurately.

Of course, this depends on short iterations, a backlog of user stories based on the INVEST model that is relatively complete, and working to ‘done’. More on these at a later date.

Re-posted from http://winnipegagilist.blogspot.com

About WinnipegAgilist

Steve Rogalsky - An agilist and team member at Protegra with a passion for agile and lean principles and practices. Green bar addict, agile player/coach, teacher, dad, husband. Email: steve.rogalsky at protegra dot com

Discussion

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: