Agile Zone is brought to you in partnership with:

Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 128 posts at DZone. You can read more from them at their website. View Full User Profile

Adopting Agile isn't the Point

12.11.2009
| 1979 views |
  • submit to reddit
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.

When we allowed ourselves to define our work in terms of our activities, we risked losing focus on the desired outcomes of the project.

At 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.
Published at DZone with permission of Mike Cottmeyer, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)