This blog post is mostly a translation of an article I had in the Norwegian issue of Computerworld april 2009.
Norway has embraced agile methodologies. Now we need to stop only evangelizing the positive effects, and start discussing – and solving – real challenges encountered in agile projects.
I think agile software development is a huge step in the right direction compared to traditional software development methodologies. However, agile development in its current form is not the end station. We can – and must – get even better. Anyone who has run an agile project has experienced problems and setbacks that aren’t normally addressed in a standard presentation of agile.
There are real challenges tied to agile methodologies, and all of us who preach agile, must dare to acknowledge and discuss that. That is important if we really want agile development to be a success, live up to its potential, and not become just another hype in history’s graveyard.
So, to get started, here are three of the challenges I’m contemplating nowadays.
Value, not Functionality
The first one is to deliver value. The first of the twelve principles of the Agile Manifesto relates to delivering valuable software early and continuously. We also like to say we deliver the most valuable parts first. This gives better cash flow and ROI, and is a great principle.
In practice, though, agile projects deliver functionality, not value. Most of the time we have no idea how much value this functionality has to the organization, or even if it would be economically smart not to develop it. We just leave it to the Product Owner or Customer to prioritize the functionality, and then we hope that it leads to us delivering the highest value first and maximize ROI. We may be right, we may be wrong – we don’t know, we just hope.
So, we need better methods of defining and measuring value. This is, by the way, the subject of my talk at this year’s JavaZone – the talk is entitled “How much value have you delivered lately?”.
Goals, not Requirements
The second challenge I’d like to mention, is that agile projects steer towards the Customer’s requirements, not the Customer’s goals. The well-known Product Backlog from Scrum is an example of this. We describe requirements as User Stories, put them into the Product Backlog, and then we measure progress as we finish off the Stories. We are willing to change the requirements and re-prioritize, much more than in serial projects, and that definitely helps the project succeed.
But – finishing off requirements is not the important thing. Reaching goals is. The requirements simply constitute a set of hypotheses for how one can reach the goals.
So, we need more focus on defining goals and steer towards them. I’d like to mention that Evo, created by Norway’s own Tom Gilb, is a well-tested alternative focusing on goal fulfillment.
Support the Customer
The third challenge I’d like to mention is that most of the difficult stuff is, especially in Scrum projects, pushed onto the Customer – the Product Owner. Not only is the stuff difficult, it’s coincidentally the stuff that, to a large degree, determines if the project is a success or not. Stuff like organizational buy-in, balancing different stakeholders and interests, determining when to release, prioritizing and determining what goes in and what doesn’t, etc. And yet we don’t say too much about how the Product Owner should manage all this stuff. A Product Owner is usually very competent in his domain – but that domain is usually not project management.
So while the development team is happily working their way through the sprint, protected from disturbance from the outside world, the Product Owner has to prioritize requirements, create buy-in, negotiate agreement, do all sorts of internal politics – while simultaneously providing the development team with all and any clarifications needed.
We’ve done significant progress in the way the development team works. Now we have to look up from the design, development and test processes. We have to start focusing on the Product Owner and the organization around her, and provide real support to the important role the Product Owner posesses.
The Point: Take Experience Seriously
Ok, so we need better ways of measuring value, stronger focus on goals and how to reach them, and improved support to the Product Owner and the organization surrounding her. Still, these are simply three challenges that I find important nowadays. Other people will have different priorities, based on their context and experience. My main point, however, is that we start discussing these real challenges that real people meet in real projects.
Until now, capable peoples specific challenges have too often been met with any variant of “But you’re not doing it right.” Especially if they’re not viewed as agile-savvy. But this kind of answer simply doesn’t help. And if agile software development is to be a real success, people need to find help also when they’re struggling, also when they’re “doing it wrong”. And, equally important: If we brush off the challenges people experience, we deprive ourselves of the opportunity to learn, to enhance and improve the agile methodologies – because we’re not taking feedback from actual experience seriously.
As one of the enthusiast who have worked to spread agile methodologies for nearly a decade, I’m very pleased that agile software development eventually has become accepted and embraced in mainstream Norwegian business. The marketing has done its job well; now we have to stop evangelizing and rather start working on the challenges.
Agile software development in its current form is a large step forwards, but it’s not the end of the journey. We have to keep improving, based on feedback.
That is the agile core in all its beautiful simplicity.