Creating a mindmap specification

In one of my projects, one of the lead developers asked me for a flow chart, describing the things we’re building. Far from the scrum product backlog, yes, but I decided to give it a try.

I downloaded XMind, a free software with a PRO version with really useful functions, but since I’m just testing the concept as a product owner, I decided to test the free version.

The result, many hours later, is a number of connected flow charts which all looks something like this:

I started with setting up the basic flow chart, and identified the main steps. All these main steps were given their own page in the workflow workbook and then I started drilling down. I looked at all steps and identified which functions I wanted to be available from that step and if there were any special scenarios. To help me out, I have the work from our user interface designer, so all I had to do was translate his work into this flowchart and identify these special scenarios. Well, “all I had to do” is perhaps to simplify the task. I will not hide that it was hard and sometimes gruesome work. For each step I covered, I identified more special cases which I need to find solutions for.

But after a while I got to really like this approach. I focused on one step at the time. Took a good look at that step and tried to think about if I’d really seen all the ways to which one could come to that step and I tried so see which steps were possible from there. The nice little note functionality made it possible to add all those special scenarios and questions.

In a couple of hours I had documented all those discussions we’d had in the project group and I would say that what we have is a number of user stories, but in another format. I can better see the links between stories, and it’s easier to track what the story applies to, without having to write too many X:s under “As a X” if I’d used the user story format.

Also, the diagram does something that user story cards don’t: it puts the story in a context. Yes, a user story does say why we do the story, but it does not show what happens next and what we take for granted has happened before.

So, what about the output? There is a HTML export function which exports not only the image but also the comments and pictures.

WHat about the next step? the next step is to see if the developers like it or not. And if they do, we have to find a way to build using this. But the first step is to see if this is the way to go. What do you think?

Business value of the boring stuff

This weekend, our vacuum cleaner broke down. We both looked devastated on the thing. Not so much for the money (which of course is boring to spend) but for the knowledge that we now would have to spend a lot of time buying a new one.

First, I tried to make an educated, good decision and scanned different communities and sites for the most recommended and best value. But I soon lost interest and found myself surfing on more interesting stuff. That is most things in the universe. I tried looking at one of those cleaning robots but realized that with two floors, one dog and a boy into Lego, this would probably cause more time spent than our gain.

So, I just gave up and went to the store. I went to one of those malls where are multiple stores to choose from, but realized when I got there that it wasn’t worth my time shopping around. So, I picked a store and went inside.

There are an silly amount of options out there, folks. One brand can have five or six different models in your average store. People went around there, testing the things. I just stared. How could I possibly choose?

And then I nearly fell into the trap that most product owners do when they prioritize. They think that something is boring so they go for the cheapest option out there. I almost picked the cheapest one when I realized, Hey, I hate cleaning. Why should I have the worst possible tool when I do the stuff I hate the most? Won’t that make me hate it even more?

The same goes for product owners. They probably don’t think upgrades, logging, error handling and installation features are the stuff of their dreams, so they try to get this as cheap as possible. And then they complain when bugs go unnoticed for months. When regression testing is a hassle, when upgrades takes forever and roll back is not possible.

I didn’t pick the most expensive vacuum cleaners. I took one in the upper level without a bag. I don’t like shopping those bags either. Since I don’t even know the model I’m using, I’m stuck trying to find that just to know that the specific bags are not available then. And they cost a lot of money. With a Golden Retriever you tend to spend a lot of bags.

Well at home, I found that the new thingy made it easier to clean at home. And having a remote in the handle is really a good thing. The dog hair is handled much better and one of the rugs are clean for the first time in five years. Well, I thought it was kind of clean before but now I know.

And one thing more, skipping the bag means that I can see all the stuff I vacuum. No more hiding of dirt. And that is also important in software development. Never hide your garbage for your in house staff. Better that they know about it and help with the cleaning.

Are you planning a project or just drawing a Gantt chart?

I guess the main reason for most project managers to use Microsoft Project is drawing the traditional Gantt chart. It’s kind of obvious, since the Gantt chart view is the default view of the program. This view is also confirmed by the default fields that are visible. A task is in Microsoft Project described by over a hundred fields but only eight of these are visible using the default settings.

If you just start up a default session of Microsoft Project and don’t change any setting, this is how you define a Task:

· Name (Text)

· Duration (Days)

· Start (Date & time, even if only the date is visible)

· Finish (Date & time, even if only the date is visible)

· Predecessors (Numbers – ID of tasks which the task directly depends on)

· Resource Names (Names of Resources)

If you open one of the templates provided by Microsoft, they all look something like this:

There are all these tasks where one leads to the other and where the assignment is already done. You’re supposed to enter the Duration (in Days).

What is important is to understand what Duration is and what it’s not. In agile methodologies such as scrum, when defining tasks during sprint, you estimate how much work a task should result in. In other words; how many man hours it is estimated that a task will result in. This attribute is in Microsoft Project referred to as Work. And that is not the same as Duration. You cannot even see Work with the default settings. Work is what you get when you add resources to a task. But why is this? I believe that it all comes back to what I assume is the basic use for Microsoft Project; drawing the Gantt chart.

The Gantt chart is made up of all these blue bars, all connected to each other and leading to the end of the project. So the assumption of the Gantt chart is that if you make a Gantt chart, you can calculate when the project should be completed. That sounds great! Just what my stakeholders want.

The individual bars in the Gantt chart have a length and a place in time. The length is the attribute Duration, and therefore it makes sense to have the attribute Duration clearly visible and editable. And to place the bar in time you can use two methods, you can either link them together or you can place them on a specific date. The linking information is saved in the field Predecessors and you can specify a date by changing the Start or Finish Columns.

The final touch to the Gantt chart is the displaying of the resources names and that is stored in the field Resource Names.

So, there you have it; the columns in the default view of Microsoft Project are the ones which you need to draw the Gantt chart.

But does this mean that you can calculate the finish date of the project based on this? Well I think that experience talks against this. Just the fact that you cannot see the assumed workload makes the planning blind. And as I’ve previously discussed; since the focus factor is 100%, no holidays are in the system and the slack is 0, we all know that this is an illusion. Looking at the Gantt chart, I see the similarity with stairways and you get the feeling that all tasks are individual steps on the stairways. You just have to walk down that and you’re done. You can just check of the steps as you fly by them. Right.

Another problem with having the Gantt chart as the objective of your planning is what you want to do with that Gantt chart. Yes, you want that planned end date but you also want to show the chart to your steering group. And then you need to print it or take a screen copy and enter it into your PowerPoint presentation. Let’s see what happens when we open one of the templates:

But hey, I can’t see all those bars, and I cannot see all those rows! But then I need to collapse the heading tasks and change the timescale:

But then I’m missing out on my nice blue bars and it looks strange. So, to keep my project nice and clean, it’s better to keep the number of tasks down. Also, linking in the Chart view is a pain if you cannot see all the tasks at the same time.

And here, we also see a conflict with agile values. In most agile methodologies, you want to keep the tasks as small as possible to enable more accurate estimates. But this clutter up the Gantt chart, making it hard to read and linking becomes complicated.

Finally, we have another problem with having the Gantt chart drawing as the objective of our planning. The product backlog does not fit into this scenario. A product backlog is a prioritized list of requirements but this does not mean that the product backlog items are interlinked. So you cannot link them in the Gantt chart. But if you don’t link them, you don’t get your Gantt chart.

Next time you start Microsoft Project, ready to create the plan for you next project, keep your objectives clear; is your goal drawing a dreamy Gantt chart or do you have higher goals?

I’ve on this blog posted a tutorial on using Microsoft Project as a planning tool. I cannot say it’s easy but neither is planning. Thinking that you’ve planned your project just because you have a Gantt chart to show your steering group is a first step towards a challenged project.

There can only be one product owner – reply on harvesting developer intelligence

I got a very interesting reply on my latest blog post concerning the harvesting of the passion of the developers. Kevin E. Schlabach rightly pointed out that you could misinterpret my suggestion to leave some time for developer’s own initiatives and ideas.

So, just to make it clear; product owners can, if they think that the developers have great ideas, keep this in mind and when scheduling deliveries, leave some slack so if a developer comes up with a great idea, you as a product owner can choose to prioritize this. As Kevin points to, this is not up to the developer to decide. He can come with suggestions just like stakeholders, but just like everyone else, he cannot decide on priorities.

I’ve also been in situations where developers have thought up an idea and just started working on that instead of the stuff that needed to be done. To be frank, I’ve had some serious problems with this and finally had to take very drastic steps to end this, so I know that this is an important and serious problem. Serious, since other stuff isn’t being done, and dangerous since cheating in a team in contagious. It spreads to the other developers.

When you instead harvest the developer’s ideas you place them on the backlog like everything else. But I do like to make the guys happy sometimes and push up something on the priority list if it’s a really good idea and something which is truly valuable to the customer. But as a product owner, I am responsible, and it’s my decision to take.

Thanks, Kevin, for pointing to the risks for misunderstanding of my point of view. Keep the comments coming! I’m agile in point of view.

Don’t forget to harvest the passion of the developers

Most of the software developers I’ve worked with want to solve the problems of the users. Many are real professionals with the attitude of a craftsman. Many are innovative about different solutions. And most of them love to write code.

If you take a developer who wants to solve problems, is a craftsman, innovative and loves to write code you are sure to hear loads of good ideas of what he could do, if he only was given the opportunity.

Many times, his suggestions are not highest on the priority list from the business people. And then you run into the situations when his stuff is never done. Yes, I know that there are other stakeholders who’s ideas never becomes a reality too, but this guy stands there with his hands deep into the code every day, thinking about those things he could do, given that he get the opportunity.

So, you should leave some room for that in your plan. For example, if you’re using scrum or another iteration based method, let the guys pick one thing if they are successful in a sprint.

If you’re doing kanban, you can be a little bit more spontaneous. The other day, one of the developers came up with a great idea. I could see the passion in his eyes. He really wanted to do it. And I could hear that he’d given the thought a lot of thinking (this proved to be correctly later). Since we’re in a situation where the next stuff on the list cannot be completed due to lacking resources of a specific competence, I was considering what we should do next. So, why not? So, I said to him to go ahead. Given that the stuff in progress is done, this will be next.

I think we’ll get so much more code/function/quality out of this than we would have if the stuff had been done with someone who didn’t think this was his stuff, someone who wasn’t thrilled about the idea. And this joy about his work will probably continue after his work with this is done. Just because now it’s done.

But besides from sometimes prioritizing the stuff the developers have passion for, one can also help developers becoming more passionate about all the other stuff. And that is best done (I think) by including them in discussions, requirements and story writing.