Work breakdown structure exercise

Today, I was invited to a WBS exercise given by a colleague. One of the absolutely best things about TUI Nordic’s project management department is that we all are eager to learn from each other. We are very different as project managers, persons and our experiences are very different. So, we keep a close culture of listening, learning and sharing. J is an excellent project manager, and I would feel really confident in him succeeding in big, complex projects. I feel I really have so much to learn from this guy. And today, I was again given the opportunity. J is project manager for a project. I’m not really involved but was invited to an WBS exercise. For him, it was a chance to get some new input since he’s new to agile software development, for me it was an opportunity to see how this really can work.

For you who’ve never done this type of exercise, you try to identify the different goals which need to be met to reach an objective. And then you divide the goals into smaller tasks and go on doing this until you have a picture of which tasks are needed. For agile people, this sounds like a story writing seminar, and this is exactly what it was. The goals are like epics and the different tasks are the user stories. We didn’t use the format of a user story but that are details. Instead of using story cards, J used post its and put these on the wall to show the structure. And since the post its weren’t big, there were not room for too much details. So, in other words, you get the shortness of a story. I loved the session, J is a skilled leader and used his two hours well. After this session I think we have a good idea of what needs to be done.

One interesting note was that in the middle of the session, I said we needed a Deployment objective. And then we needed a Maintainance objective. And suddenly the number of tasks exploded. Deploying a big e-com solution is something you need to plan for. You perhaps does not need an actual plan (in Project) but you need to plan for deployment. Make sure that the acceptance environment is available, that we have testers, that operations are ready, user and help desk informed. Etcetera. Etcetera.

Building the stuff is the easy part.

Good exercise for teams moving into agile

I was discussing how to introduce new teams with SirAj yesterday, and then I remembered a rather interesting team activity for new scrum teams. This can be used before or after a scrum or agile presentation.

You divide a whiteboard into four columns (or better still, if you have four whiteboards like on the picture):

1. Why do they want to start using agile methods?
2. What do think will improve?
3. What will not be affected (but is still a problem)?
4. What will become worse?

And then you ask the team to put on notes how they think their project will change when moving into agile. After this exercise, all expectations can be discussed and perhaps misunderstandings can be cleared.

The results from this exercise can then be discussed after a couple of months to see if the same picture remains.