In this blog, I make a case for what I think is the next step in the evolution of Agile project management. The focus of project management used to be based on managing Tasks that people perform to deliver a piece of software. Agile project management shifted focus to managing the delivery of Features. I believe that the time is ripe for the Agile community to take the next step: move towards Value driven project management.
Read more →

In my experience as a Scrum trainer and coach, I have seen too many Scrum teams that fail to do what Scrum was invented for: Inspect and Adapt.

Do the following statements describe the situation of your team?
– Little is done about problems discussed in Retrospectives.
– Sprint Reviews have no impact on what is build in subsequent sprints.

If so, you may be interested to read my article on the Scrum Alliance website: Effective Retrospectives & Reviews.

In my previous blog, I talked about when to estimate user stories so that a Product Owner can do release planning based on velocity and relative estimates. This time, I will discuss another topic that I see many Scrum teams struggle with: how to implement improvements based on what is discussed in retrospectives.

Many Scrum teams have a hard time to continuously improve themselves. In retrospectives, problems and possible improvements are discussed. Then nothing happens. In later retrospectives, the same problems are discussed without noticeable changes. Retrospectives like this are a waste of time. Even worse, missing out on the opportunity to continuously improve is a big waste in itself. The velocity of such teams and the quality of their deliverables will almost certainly get better if they find ways to act on improvements that are identified in retrospectives.
Read more →

One of the biggest strengths of Scrum is that it is a framework instead of a detailed methodology such as RUP. In Scrum, concepts are described that make essential aspects of projects fall into place in a very powerful way. One does not need a Process Engineer to tailor Scrum before it can be applied successfully. However, because there are many things that Scrum does not describe in detail, there is plenty of room left to mess things up 🙂

In this blog, I discuss on how to facilitate the estimation of Product Backlog items so that the Product Owner can do release planning.
Read more →

In many Scrum projects, user stories that are Done at the end of a sprint have not yet been put into production. In other words, production is often not part of the Definition of Done. There can be several reasons for this. Examples are:

• additional acceptance or integration testing is needed that can not (yet) be done within the sprint;
• user stories have dependencies on hardware of software from an external party that is not yet available;
• minimal marketable features are bigger than what can be produced in one sprint.

Read more →

Last week I co-organized an nlscrum event with a very special guest: Jeff Sutherland. After rushing with him from the airport to our Xebia office, Jeff gave a very inspiring presentation.

Read more →

Ever since I read Mike Cohn’s book Agile Estimating and Planning, it has been a great help in doing Agile projects. One of the ideas that I like very much is to estimate user stories on a product backlog in an abstract measure: story points. Story point estimates only need to be correct relative to each other. Having such estimates allow you to monitor velocity: how many story points can be done in an iteration. Based on velocity and an estimated product backlog, decisions about scope, schedule and budget can be made and continuously refined a very informed way.

The most common way to estimate user stories on a product backlog is by doing a planning poker session. However, in my experience it is pretty hard for a team to do this effectively for a big list of user stories. Therefore I tried out another approach.
Read more →

When working with Maven 2 and FitNesse, it is desirable to use the Maven classpath in FitNesse. The FitNesse Maven plugin can do this for running tests in a build, but not for using FitNesse interactively.
Read more →

Recently I wrote a blog about the way that we do distributed Agile projects. Martin van Vliet and I have also published an article on InfoQ about one of them. So if you want to know more about one of our bigger distributed Agile projects, here it is: Case study: Distributed Scrum Project for Dutch Railways.

I have been a Scrum Master on one of our distributed Agile projects for about a year. I would like to tell you about how we do such projects and share some of my experiences. If you are having a bad time with offshore software development, try not to get too jealous because we are having a great time at it 🙂
Read more →