 Very
important to Agile projects but often overlooked is getting working
software done
regularly and frequently. The definition of working software may vary
slightly between projects, but not much. Working software
is fully integrated, tested, and ready to be
shipped to customers or deployed into production. That doesn't mean you
tried it a couple times and it ran without aborting. It means you
created unit tests, QA
tests, and actually looked at output to prove it works. It isn't as
difficult as you think. In fact some teams deploy new
software into production every single day.
When we were managing
our projects by activity
we needed a way to guard our progress. The people who finished an
activity like analysis might not participate in design or coding. So we
safe
guarded all progress by creating extensive documentation of what was
decided and what was done. We had people with authority sign the front
page to verify our efforts were going in the right direction.
An
Agile project has all activities going on all the time as needed. We
can't
use documents with signatures to guard our progress. Instead Agile
teams rely on automated tests and working software to safe guard
progress. We show working software to our customer/product owner often
and accept changes to ensure our efforts continue in the right
direction. You can't empower your team to find its own solution using
documents with signatures, you need the intense feedback that working
software provides.
|
Working
software is an Agile theme that affects everything you do. You will set
a project heartbeat,
but unless you produce working software each and
every iteration your
heart beat won't be meaningful. Honest
plans are only possible if you have honest
estimates based on done meaning finished and working. Iterative
planning adapts to changes, but good changes only come from customers
looking at, and trying out a working incremental version of the system.
A big part of your project
heartbeat is delivering working software into
production regularly and frequently.
Take
your iteration end
seriously. If you are using one week iterations it can be tempting to
just push unfinished work into the next iteration. If you find yourself
approaching iteration end with several unfinished stories the right
thing to do is get your team together and decide which stories could be
finished if you work together on them. Your project's velocity is a
measure of how much software you got working, not how much you promise
to have working next week.
When
we produce working software in small increments we are no longer locked
into a minimum cost to get return on investment (ROI). We don't need to
spend the entire budget (usually with overruns) to get something back
from our project. We can stop when ever we think we have done enough or
a higher priority projects comes along.
Measure
your progress honestly. If software is what you intend to deliver than
count |
|
