Team Foundations

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 →

The Product Backlog Hinders Value Creation – Part 3

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.
Continue reading →

The Product Backlog Hinders Value Creation – Part 2

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

Flawed Value ProcessThe 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.

Continue reading →

The Product Backlog Hinders Value Creation – Part 1

(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.

Continue reading →

Leaving and Joining

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.

Continue reading →

Crafting a Passionate Presentation

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 Customer’s Agile Manifesto

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.

The Manifesto for Agile Software DevelopmentTo 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 →

CFO’s Case for Frequent Releases – Part 2

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.

Continue reading →

CFO’s Case for Frequent Releases – Part 1

You may have heard or read that frequent releases can improve project economics and ROI (return on investment). Here’s the math.

Continue reading →

Agile development isn’t there yet

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. Continue reading →