Delivering Business Value
19 October 2017
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
At the heart of Agile is delivery of business value. Search for its real meaning has become a sort of Agile Holy Grail. Yet when you step far enough back from any of our software development practices, we still seem, at the end of the day, to operate for the most part in the zone of simply “delivering features the customer likes.” Stopping there and maintaining that mindset is, of course, that is one way to play the game.
But if we want to broaden our horizons, push our sphere of responsibility out further, and become trusted team members in more organic organizations, we do need to look further. The astonishing possibility is that there may be one very simple step that teams and organizations can take to do so.
We’re talking about impact mapping.
A good practice is for business managers or product owners, as a usual part of an initiative, to sort out the leading and lagging indicators that they will track to see if their business objectives have been met. Methods like impact mapping can help with doing this. The core idea isn’t new. It’s even part of older requirements engineering disciplines, under names like “success measures.” It was just never much practiced in my experience.
What would be new, at least in many organizations, would be to share these indicators with the development and delivery team as a standard part of the process. Make value management a complete end-to-end process involving everyone. Allow the development team the opportunity to understand and assume some ownership as well in achieving the actual business value sought by the organization. This approach could apply regardless of whether the product had to do with software.
With that the picture starts to look more complete. It also is a step toward iterating rapidly on observed results and pivoting when needed.
To be honest, it also resolves a little bothersome thought about Agile that has sometimes nagged at the back of my mind. In the zeal to flatten organizations and become highly cross-functional, I sometimes sniff a tiny motivation to “finally get out from under the wings of the business” and to seize the opportunity to take the lead role in steering the business. The fact is that there are great business leaders. They exist. Just by broadening our role in the game, as systems people, by the simple step just described, our ability to help the business endeavor achieve high goals improves dramatically. With that comes joint satisfaction. It also makes gaps in that leadership more transparent, providing the opportunity for them to be addressed, and the opportunity for well-intended business people to evolve to better ways of working, right along with us.
I would love your thoughts on this. We have in hand theory and methods to operate rapidly adapting, outcome-driven development as a de facto element of any Agile process. It’s already being done. Let’s learn and get better at it.
Current rating: 3 (1 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.