Ah, those requirements!

---

We may not know much about the requirements; our backlog may be slight; but we do know this about that:

1st requirements paradox:

• Requirements must be stable for reliable results
• However, the requirements always change

2nd requirements paradox:

• We don't want requirements to change
• However,  because  requirements  change  ....  is  a known risk, we try to provoke requirements change as early as possible

So writes Niels Malotaux in an interesting 16 page paper describing his version of Agile, titled: "Evolutionary Project Management Methods: how to deliver quality on time in software development and system engineering projects".

Here's what Malotaux calls "Magic Words"

'

•   Focus
Developers tend to be easily distracted by many im-
portant or interesting things. Some things may even
really  be  important,  however,  not  at  this  moment.

•   Priority
Defining  priorities  and  only  working  on  the  highest
priorities guides us to doing the most important things
first.

•   Synchronise [sic]
Every  project  interfaces  with  the  world  outside  the
project.  Active  synchronisation [sic]  is  needed  to  make
sure that planned dates can be kept.

•   Why
This  word  forces  us  to  define  the  reason  why  we
should do something, allowing us to check whether it
is the right thing to do.

•   Dates are sacred
In most projects, dates are fluid. Sacred dates means
that if you agree on a date, you stick to your word.

•   Done
To make estimation, planning and tracking possible,
we must finish tasks completely. Not 100% finished is
not done. This is to overcome the “If 90% is done we
continue with the other 90%” syndrome.\

•   Bug, debug 
A bug is a small creature, autonomously creeping into
your  product,  causing  trouble,  and  you  cannot  do
anything about it. Wrong. People make mistakes and
thus  cause  defects.  The  words  bug  and  debug  are
dirty words and should be erased from our dictionary.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Trinity (of estimation)

---

I've often quoted this estimation trinity:

"Estimation,  planning  and  tracking  are  an  inseparable trinity. If you don't do one of them, you don't need the other two."

• If you don't estimate, you cannot plan and there is nothing to track. • If you do not plan, estimation and tracking is useless. • If you do not track, why should you estimate or plan?

Niels Malotaux

Said another way: if you don't care enough to plan your destination, and track your progress getting there, then any road will do, since anywhere will do.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Project Management the Agile Way

It's almost here! "It" is my new book, "Project Management the Agile Way...Makng it work in the enterprise", most likely in Amazon by January 2010 if everything continues on the path with the publisher-Gods.

In this book, I expound on my top-five for agile, and actually blow it out to 12 major themes, from a quick overview of 4 agile methodologies, through a business case, test strategy, and eventually ending with benefit capture.

You know, on this last point, the NPV of the typical agile project is better than the traditional plan-driven methodology, at least for a few periods where the early deliveries start earning benefits early.

If you work in a business environment where the executives need to be persuaded to do projects, and a business case becomes a contract for performance, this may be the book for you. This is about agile in a business situation where projects may not be a core competency, but simply a means to an end.

I hope you enjoy the read as much as enjoyed the write!

Are you on LinkedIn? Share this article with your network by clicking on the link.

Agile Earned Value--Part I

There's a common misperception that agile and earned value don't mix: that earned value is too heavy and anti-agle.  Not so! Agile projects earn value by delivering product incrementally, periodically, affordably, and according to the priority of the customer.


If the customer is not satisfied, he may not want to pay for our efforts. If the customer is not successful, he may not be able to pay. If he is not more successful than he already was, why should he pay?

Niels Malotaux
EVO Consulting Project Manager

The agile rule for earned value:

Each release is a value earning; without a go-live to production, there is no earned value.

In project terms, earned value means planning for an outcome and then achieving it, applying only the intended resources. When the project is completed and expectations are met, the entire value is earned—all requirements are rendered in production and equated to benefits.

Agile methods change the bookkeeping a bit, but by Agile Principle 1, delivering value is at the top of the list:

Our highest priority is to satisfy the customer

through early and continuous delivery of valuable software.

Are you on LinkedIn? Share this article with your network by clicking on the link.

What is this thing called Agile?

I've been working on a book about agile project management for enterprise projects. My publisher just gave me a title! "Project Management the Agile Way -- Making It Work in the Enterprise". Look for it in January, 2010.

Until then, the article below is a petty good introduction to some of the top-level ideas. You can down load "What is this Thing Called Agile" from my library at slideshare.com

There are some other materials there you may find interesting. Let me know!

Click here to share this article with your network on LinkedIn!