Adopting Agile Isn’t the Point
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.
Comments (6)
joshilewis
I completely agree with you here. I think too often these types of adoptions are a 'push': "ooohh, that looks shiny, let's try it". It's the same approach to patterns usage: "Oohh, I like Visitor Pattern, let's use it!".
Any adoption should be based on pull, and should address specific needs. The actual adoption should be scrutinised as to whether it is providing value. In the back of my head, I've been planning a blog post on 'adoption should be a pull' for a while. My blog is at http://joshilewis.wordpress.com.
I also have ideas such as doing 'TDD' for the adoption, i.e. stating exactly what we want to achieve with the adoption in our organisation, and being able to measure whether we've achieved that goal.
Daryl K
From your lips to God's ears, Mike.
We have to always be linked back to the business reasons, and we may find out that certain Agile practices, however hallowed, do not get us to that business goal.
As Timothy Lister said at APLN '06 "Adapt, don't adopt."
Robert Dempsey
Great post Mike. Agile adoption is all about obtaining business value. There are goals the organization has, and adopting Agile methods and principles is the means to that end. If everyone knows the goals it is much easier to chart the course. However the goals have to go first, otherwise it's implementing Agile for the sake of Agile.
Mike Cottmeyer
Josh, Daryl, and Robert. Thanks for the comments!
Scott Duncan
I certainly cannot disagree with what I believe is the intent of your post, i.e., that we focus, first, on trying to be clear about business value rather than the techniques for getting there. But I don't think the example, especially the business view as stated, really illustrates this.
Did you mean the statement of the business view to be a good example of business value. It sounds more like a request for solution from business. Should be assume someone did a real analysis of the issue(s) business was having and increasing server capacity was the solution decided upon (as opposed to another approach)
I am not convinced that "investing in extra storage space so they could store more email messages or have more room for application data" is a business value statement. If it is, then I do no see why the IT folks should not consider the project to be "increasing server storage capacity." I cannot see how that hurts if they understand that this is what needs to be done to meet the goal of business being able to store more emails or application data.
Overall, I'd have preferred an actual Agile-related example since that is the point of the post based on the title and much of the text.
Roger Titley
I totally agree that adopting agile is not an end-goal but a means to an end, namely business value.
However I believe that if agile is adopted as an overall culture in an organisation then it is a great way of driving out what will provide business value.
Agile is not just about developing code, it is a culture of continuous self improvement and such,can be adopted by a whole organisation including top management.