This site will remain active so you can come back and read posts you’ve enjoyed in the past. But we invite you to join us at http://blog.versionone.com for current posts.
If you're a subscriber, you can update your RSS feed here.
Thanks…and we’ll see you at our new blog!
A
few years back when I was still doing hands-on project management
work... I used to teach internal classes on iterative and incremental
product development. Officially... we were teaching a very light-weight
instantiation of the Rational Unified Process. Unofficially... we were
teaching agile values and principles within more of an Agile Unified
Process framework.
The audience was always full of hard core
waterfall folks... developers... testers... business analysts...
project managers... one of the main things we'd try to talk about was
the idea of frequent delivery of working software. I'd explain that
charters and market requirements documents and detailed design
specifications were not what provided value to our customers... all our
customers really cared about was the working software.
Inevitably...
someone from the audience would raise their hand and ask the question:
Are you telling me that these detailed requirements documents... the
ones I spend months and months creating... are not valuable? Are you
telling me that the only one delivering value on the team were the
developers?
I'd have to carefully explain that while those
things were valuable... to the extent that they enabled
communication... to the extent that they helped people understand...
they were not the value that our customer's expected. If we had to kill
the project 3 months in... would you rather have a detailed
specification or an increment of potentially shippable code?
The potentially shippable code is always going to win.
The
same idea holds for organizations with multi-part... multi-step value
streams... organizations where it takes the activities of several teams
working in coordination to deliver value back to the business. Even the
smallest organizations... organizations with the simplest value
streams... are going to need sales and marketing and support to deliver
a viable product to market. Software doesn't usually sell all by itself.
More
complex businesses... businesses with more complex value streams... are
going to need not only sales and marketing and support... but also the
ability to integrate the outcomes of many feature teams and component
teams to get a product into the hands of their end-users. Does it do us
any good to invest in one part of the value stream if the other parts
are falling behind? Value is only created when all the parts are
integrated into one cohesive whole.
So... when one part of the
delivery organization gets too far ahead of the other parts of the
delivery organization.... be it by writing all the requirements up
front... or by building out one part of the component architecture too
far ahead of all the others... it is easy to start confusing valuable activities with real value delivered into the product.
It is especially easy when all that activity results in great team
velocity and real working... albeit incomplete... software.
Okay
guys... if you are going to be anywhere near Charlotte, North Carolina
next week... you have to find your way to the first East Coast Agilepalooza!
We have a lined up a great group of speakers for the event... Jeff
Sutherland... David Hussman... Guy Beaver... Joe Little... and yep...
yours truly... Mike Cottmeyer.
