I spent the first ten or so years of my career living in data centers.
I was a network guy... built a lot of servers... installed a lot of
operating systems. Before I made the jump into project management, my
specialty was email systems... Lotus Notes in particular. The first
couple of projects I ever officially managed were things like server
upgrades and hardware refreshes. Sometimes we were doing upgrades just
to stay current with the latest release... but most of the time, our
stakeholders were investing money to get some new capability that was
valuable to the business.
Usually I'd have a few guys on the
team working with me. One of my pet peeves was when someone on our team
would talk about our 'server upgrade project'. From their point of
view... we were upgrading servers. From the business' point of view, we
were investing in extra storage space so they could store more email
messages or have more room for application data. Calling our project
the 'server upgrade project' described what we were doing, but it
didn't adequately describe the value we were delivering to the
business. It's a subtle but meaningful difference.
allowed ourselves to define our work in terms of our activities, we
risked losing focus on the desired outcomes of the project.
the end of the day, the business didn't care if we added hard drives,
upgraded memory, or installed a new OS... they cared about the value
that those activities would give them, and how that value would impact
their ability to conduct business. They cared about the return on their
investment... not how we got that return. I think there is a parallel
here to how we think about our agile transformation projects. Are we
adopting agile or are we getting feedback so we can build better
products? Are we adopting agile or are we trying to get incremental
revenue from our software development investment?
The goal is
not to have Scrummasters and Product Owners. The goal is not to have
cross-functional co-located teams. The goal is not continuous
integration or pair programming or TDD. Those things are the stuff we
do to get the desired business outcomes... those things are strategies
that we believe will deliver the business value our organizations are
investing to receive. Our challenge is not to mistake the proposed
solution with the desired outcomes. There are LOTS of people that have
Scrummasters and Product Owners that are not rapidly reducing risk...
not getting fast feedback... not delivering incremental value... and
not building an integrated end-to-end product.
Maybe this is
just semantics... but I believe when we put all our focus HOW we think
we are going to solve the problem... it is easy to lose sight of WHAT
we were really trying to accomplish. It's easy to start focusing on
upgrading hard drives rather than the business outcomes those hard
drives were purchased to deliver. Our goal is to stay brutally focused
on business outcomes and choose strategies that we think will deliver
those outcomes. We have to constantly inspect and adapt and be willing
to change when we are not getting the outcomes we hoped for.
Because, at the end of the day... adopting agile was never really the point.