The objective of the objective

Before I start a story writing seminar, I think it’s important that the participants know what is the purpose of the project and what is not the purpose of the project. I’ve never heard about a project where there is no deadline and money is not the issue. You must always focus on the right stuff to get the project to become a success.

So, what is a successful project? Well, I guess if it’s a project which meets the objectives. And to meet the objectives you need to complete the tasks which leads to forfilling that objective and you must probably try to spend as little time as possible on tasks which does not lead to the objective.

It is one thing to have someone tell you what the objective is. It’s a little better if you’re shown some kind of picture, but what ever the form; if an objective is just broadcasted to you, you might know it. But is it yours?

Mike Cohn has some interesting exercises for forming a project objective, but until today I hadn’t really grasped why I really found it so important that the team participate in these exercises and that you don’t simply tell the guys why we’re spending all this money.

When I presented the exercise, one of the guys frankly spoke out and asked why they were forming the objective and why the business folks didn’t do this. How were they supposed to know.

A very good question.

But when he said that it became so clear to me that what I really wanted was to know what they believed and thought. Everyone has their own picture and if they don’t tell what they think and believe, we cannot debate their idea.

So, out the window went the exercise and I simply asked everyone what they believed and thought. We listed all this input and then based on that we formed a simple Moore’s product vision for the project.

We then went back to the list and marked which items were mandatory to meet the objective and how they helped.

When we during the upcoming exercises formed user stories, we could really lean on those decisions. Both what was included and what was not.

One of the hardest tasks when you’re hosting a workshop is when people question your exercises. But if they cannot understand why they are used, you should probably not use just that one on that occasion. You should instead know what you wanted with the exercise and think if there is some other way you can reach that goal.

But the best thing is how much you learn about an exercise if they don’t go as planned. I’m even more confident in the relevance of a project objective, but the reason for formulating one in a story writing seminar must be clarified to the group.

Measuring productivity

You get what you measure

So true, so true. These famous words from Mary Poppendieck point at an important objective of anyone interested in their work.

But there is a risk to these words. Because you can be lead to believe that you can measure everything you want.

I want my son to love me. So, following Mary’s words I should probably measure his love. This should ensure me success in getting his love.

Sounds goofy? Well, to most sane people this sounds crazy. I cannot take out a chart and plot my son’s love for me.

But how about productivity? In the agile community I’ve read a couple of discussions about if you can use velocity to measure productivity. I don’t like this idea much. I use velocity for predictions and my priority. Story point estimates are in my world a relative value of size, and if I start measuring how many dots they complete every month, they are not sure to start making their estimates bigger. I still don’t measure productivity but I’ve also lost my chance of predicting my upcoming deliveries.

So, how do I measure productivity of the developers on my team? Well, I measure it by how happy my users and stakeholders Do they feel that the investment was worth it. But, but, you might say: that is too vague! And I say that just this is what matters. If the customer is happy about the investment. Can they make the money they hade anticipated or save the cost they were counting on.

And frankly, I have a hard time finding a good measurement of productivity. I can just look back at my role; project manager. What is a productive project manager? Is it the one who makes the most Gantt chart bars? Or holds the longest steering groups? How does a project manager know if he’s been productive a day? For me it’s a feeling. Some days I can have had this ten minutes meeting which clarified a lot of stuff which will save us a lot of coding time or make us reach our goals. But a numeric calculation, I don’t know.

It was perhaps easier when I was a test leader. And yet not. A productive tester does not find a lot of bugs, he prevents them from occurring in the first place. And how do you measure that? Yes, you can measure the decline in bugs, but how do you know if a specific tester was the reason.

So, to summarize; I wouldn’t feel productive as a project manager if I was asked to measure the productivity of team members.

TFS 2010 for us product owners

I’m currently using a lot of Microsoft Project to keep my distributed stakeholders updated since the scrum dashboard just works for the current sprint and the 2008 web access isn’t very… accessible.  The stakeholders can’t get the overview they need. So, I spend time on separate Microsoft Project files with the long term plans (as described in a previous post) and I keep the product backlog in TFS.

So, I was just thrilled by the images on BHarry’s blog, describing the new features for us non programmers. Finally, I can really invite my stakeholders to keep themselves updated on the level they need.

The dashboard looks awesome! Here are two examples:

For me as a product owner, I of course long for the hierarchical work items:

If I still want to show Gantt charts, I can (if all goes well) use the upgraded Project Integration, since it conserves the hierarchy. This is the main reason I don’t use the integration today.

I’m also very curious about the Sprint planning functions

So, what more can I say: JUST BRING IT ON!

Project Management – the root of technical debt?

I’m currently labeled Project Manager. According to Wikipedia, that is defined as:

A project manager is a professional in the field of project management. Project managers can have the responsibility of the planning, execution, and closing of any project, typically relating to construction industry, architecture, computer networking, telecommunications or software development.

If you read that definition, you can see that the project manager is responsible for the project. The guardian of the project. Responsible for the project being finished on time, on budget and with the right features.

Many companies are conducting their development in project management style. When introducing a new big feature to the IT environment, a project is formed and a project manager assigned. So far, so good. The introduction of project management is often a huge step forward for organisations previously just using ad hoc system development, but there are also big risks to be taken into consideration. It’s not for nothing that the agile software development movement has risen. Projects are over budget, late and include the wrong features. But even if we overcome those problems, there is still other problems with project management and that is project management guard the project, not the complete system environment. In the definition it does not say that one should look at the whole system of an organisation. And the same picture can also be found in the literature I’ve covered in my class in project management. You could bring it down to the following: make sure YOUR project is successful.

So, what does this mean. This is an example I’ve seen to often. A project is started and when the time is running out, it becomes clear that a current feature can not remain as it is when the project is completed and has to be remade. The project manager thinks this is not part of the project and refuse to include the changes on his budget, since that feature has nothing to do with his project. So, the other feature just stops working or a poor developer makes a quick fix, which works poorly.

Another example can be that a project is carried out and a new process is introduced. This can be automated, but this is more expensive. The project manager does not want this on his budget so the process is manual. Then a new project is introduced and the same process is to be used. Since the first project uses the manual process, the project manager thinks this is ok in this case too. The operations (for they are all too often the ones to carry out the manual step) starts complaining that this takes too much time and that there are room for so many errors. But the project manager thinks that automating that process should not fall on his budget.

Yet another example is when time is running out, the developers fight hard to meet the deadline. So, bugs are introduced and technical debt is built through the using of in the long run poor quick fixes. The project is completed, the final report is written. But then after a month or two, the incidents start to build up. The project was successful in itself, but the effects on the whole was a failure.

This is not acceptable. Perhaps these stories are not as common as I believe, but I keep hearing them all the time. Project management can be the root of sub optimizing and there are few tools within the project management field to cope with these questions.

If you boil these issues down, I see them as technical debt. You are harming the system as a whole to make sure a new feature is working. And this is OK if all the other systems are useless or worth less. But we all know that this is not the case. The project manager might think so, but…

I have some statements I would like to add to the role of a project manager. I’m fully aware that this can make the title misguided, but I think the issues are more important than the title.

• We consider the deployment environment is to be considered as holy ground.
  A project manager should tread carefully on the deployment environment and guard it like it was sacred. We guard the environment to make it safer whenever this is possible
   
• We don’t cause harm to current functionality
  We don’t introduce code which is worse than the one which was there! We don’t make things worse for operations!

I’ll probably get back to this subject, if I’m not killed as a traitor by some other project manager.