As you probably know, I’m an agile guy – as a practitioner, enthusiast and project manager. I’m also a certified PMP (Project Management Professional) – or a “real project manager”, as one of my agile friends jokingly remarked. I’ve been an agile enthusiast for far longer than I’ve been a PMP, by the way.
I’m not going into the “is agile compatible with PMBOK” debate now (it mostly is). My interest is in creating maximum value with the software projects I’m involved in, regardless of methodology, framework or whatever you want to call it.
And frankly, “real project management” as defined by PMBOK (Project Management Body of Knowledge) is not impressive with regards to value creation. Let’s take a look.
As you may know, I left Steria and joined Statkraft June 1st this year. One of the things that I looked forward to in Statkraft, was the opportunity to work long-term with the same team. How good can we become? How much fun can we have? How enjoyable can we make life both for our customers and for ourselves?
So, just before I started my summer holiday (which I’m in the middle of now), I worked with the other project manager in my department to set up a series of workshops on Team Foundations, each workshop with its own theme. This is what we came up with. Continue reading
In part 2 we looked at how an improved value process can rectify the shortcomings of a Product Backlog / User Story oriented standard agile approach. The main component was introducing two levels of quantified goals; Stakeholder Goals and Product Goals and evaluate ideas and real implementations against those goals, particularly the Product Goals.
Now, it’s time for some specific, although simplified, examples. Imagine a clothes shop that also sells through their web site.
So, let’s summarize where we are so far.
The value process in agile software development projects is flawed, and the Product Backlog is at the center of it. It normally goes something like this:
Flawed Value Process
The customer has some challenges, and starts a project to address them. The project’s goals are formulated – and goals are value statements, explicitly saying what the valuable results of the project should be.
Based on the goals, the customer starts working on the Product Backlog, with its user stories. The user stories, as we saw in part one, are means to reach the projects goals, or ends. In this process, the customer assumes that the user stories she writes are necessary to reach the goals. But there’s no real checking if that assumption is true, if the successful implementation of those user stories does indeed bring the customer closer to the goals.
So this step is basically a one-way process. The goals do not change as a result of creating the Product Backlog, and alternative means (e.g. a different set of user stories) are not considered in any serious way.
(I did a lightning talk with this title at XP2010 in Trondheim, Norway, and thought I’d do a write-up of it as well. This is part 1.)
Ok, we all want to create value with your software projects. Using agile methodologies is a great way of accomplishing that. But as I’ve gained experience with agile methodologies, I’ve surprisingly found that the Product Backlog is actually hindering us from developing the most valuable software. It’s hugely superior to the standard requirements documents of the Dark Ages, but still – when it comes to creating maximum customer value, the Product Backlog is a hindrance.
I think there are three problems with it.
So, today is my last day at Steria Norway. It’s been a great three-and-a-half years here, and Steria is without competition the best place I’ve worked so far – even considering the one year or so when I was self-employed (no kidding). I’d like to highlight a few factors that have contributed to my enjoyment these years.
Posted in Other
Today something clicked for me. I’m working on my lightning talk for XP 2010, entitled The Product Backlog Hinders Value Creation. I typically do from six to twelve “real” presentations a year, and I want to be good at presenting.
So the thing that clicked is this:
The most important things for a good presentation is that the presenter is seen as honest and passionate about his subject. The best way to accomplish this, is to actually be honest and talk about something that I’m passionate about (imagine that!). This is nothing new, I think.
Previously, though, in my attempts at creating good presentations, I’ve focused on building a logical, un-attackable line of argumentation that naturally and un-attackably leads to my conclusion.
But there’s nothing personal in logic! No personal honesty, no passion or any other emotion in it! I’m not even sure I can tack honesty and engagement on top of a logical presentation. Even though I’ve mostly been passionate about the subject I’m presenting, my presentations have been so rational that the passion simply wasn’t let out to play.
Furthermore, Continue reading
The agile manifesto (www.agilemanifesto.org) was created by a group of very bright and experienced people. However, these people all came from the supplier side of software development, something that’s evident already in the third of the four value statements:
Customer collaboration over contract negotiation
– implicitly saying that “we” are not the customers.
To reap the largest benefits of agile philosophies, the customer side of projects also need to work in an agile manner. This involves more than providing the developer teams with a Product Owner. The customer side of a project doesn’t only have to work with the developers, but also their own organization and other stakeholders. Most importantly, the customer side of a project has to figure out what goals the product should reach in order to create real value to the stakeholders.
So, I wonder, what would the agile manifesto have looked like if it was created by customers instead of suppliers?
Here’s my take. Continue reading
In Part 1 of this series, I showed how frequent releases and prioritizing features increased the value of a project. In this Part 2 we’ll see what happens when things don’t go exactly according to plan.
Posted in Agile, value
Tagged Agile, value
You may have heard or read that frequent releases can improve project economics and ROI (return on investment). Here’s the math.
Posted in Agile, value
Tagged Agile, value