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.

Now and then I might share other thoughts as well. I’ll blog mostly in English, maybe sometimes in Norwegian.

My agile story: I worked in Funcom as a producer (combined project manager and game designer) when I got interested in project management as a profession and started reading books. I had just finished a book about the Capability Maturity Model (CMM) in 1999, and my occasionally inflexible brain thought “Well, this kind of makes sense, in a way. But do we get to do any actual work?”

Then I read the white book – Extreme Programming Explained (1st edition) – and my brain loosened up and I thought “Yes, this will work! It makes sense and we get to do actual work!”

It still took me a couple of years and a change of employers before I finally got to try agile on a project. In the meantime I got to be quite a theoretical expert – I knew everything. That first project, though, made me realize that while agile is simple as a concept, it’s hard to make it actually work.

Now, several agile projects later, I hope to engage and help others succeed with agile. In the meantime, I’ve encountered several challenges with agile that aren’t addressed that much in the literature, and that I’ll also try to address. More about that in later blogs, though.

Today I work as a senior project manager at Steria in Oslo, Norway. Steria is very supportive of my agile interests, and several other of Norway’s agile enthusiasts work here, too – amongst them Johannes Brodwall, who has a very good and thought-provoking blog.

Again, welcome – hope you’ll pop by from time to time!