Adopting Agile isn't the Point
Join the DZone community and get the full member experience.Join For Free
Discover how to increase change awareness, code quality, and maintainability through straightforward code reviews, with a simple, lightweight workflow, brought to you in partnership with JetBrains.
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.