Home > Agile, Leadership > The objective of the objective

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.

  1. 2009/09/07 at 10:29 pm

    I have always started with some kind of vision statement for the project. In fact I encourage the business to do the same thing. A simple statement of what the business expects to gain from the project is critical to measuring success. In the same way the IT objectives are critical to knowing what direction to proceed, and knowing when you are done. Closely examining assumptions and exclusions are also vital in knowing just what is in the project and what is not.

    This is not rocket science. Disciplined teams (should) have been doing this all along. When in the transition to agile did we forget basic software engineering principles?

    John

    • Anna Forss
      2009/09/08 at 6:05 pm

      I also have that and for me it is so important to have a clear objective. I can live without a Gantt chart or a detailed spec, but not having a commander’s intent for the project. How can you prioritize?

  1. No trackbacks yet.

Leave a reply to John Hebley Cancel reply