Short video introduction to my sessions at Agile Eastern Europe 2010

In about 3 weeks I'll be flying to Kiev and meeting some of the best Agilists in the planet. But it won't be just fun and games for me. I'm already stressing about my sessions.

Check out the video introduction of my sessions at Agile Eastern Europe and, while you are at it why not book your flights and hotel and joining us there?

See you at Agile Eastern Europe in Kiev!

Introduction to my sessions at Agile Eastern Europe 2010 from Vasco Duarte on Vimeo.

Why do we keep on giving up any control over our project? It would be so easy to keep it...

I get very often shocked by the comments that I hear from supposedly very smart people. Today was no exception. I heard the following comment:

There is content we don't want to timebox, therefore there's no need to link it to any timeline...

-- Quote from someone that has direct responsibility over scope in a project (my emphasis)

This quote betrays a complete misunderstanding of the dynamics of software development, and a complete (albeit unintentional) ignorance of the market forces we need to deal with.

Here's my point: by scope-boxing a particular Feature what we are doing is effectively giving up control of it's size. Once the team is given the Feature they will work on it until it is "perfect", that means we don't have a clue when it will be done and therefore the schedule for that feature is completely unpredictable! Yes, sure we will stop development on it at some point, but will it happen before it is too late?

The advantage of timeboxing the content for a Feature (Feature must fit in a Sprint) is that we have a clear deadline at which point we evaluate if the feature is ready to go to the market! Without this constraint the team is left "alone" to decide when the feature is ready. But the team is the wrong actor to decide when a feature is ready! The product owner should be doing that work based on market intelligence, user knowledge, etc.

By scope boxing (as opposed to timeboxing) our features we are effectively giving up control of our projects!

Why is it so hard to understand this point? Where is my reasoning missing clarity?

Can you help?

Photo credit: danielygo @ flickr

User Stories are representations of a conversation, not a list of requirements!

Great post by Martin Fowler about a hidden aspect of the User Story flow within a team. 

Many times I see teams that expect the Product Owner to behave just like a Requirements manager did in the past. Come up with the content, put it in the tool and stay out of the way! That's wrong!

In this article Fowler calls our attention to a key aspect of Agile SW development: the fact that it is a constantly ongoing conversation between the team (that implements) and the person/people that hold the product's vision (typically: product owner):

This notion of product owners coming up with DecreedStories is a profound misunderstanding of the way agile development should work. When we were brainstorming names at Snowbird, I remember Kent suggesting "conversational". This emphasized the fact that the heart of our thinking was of an on-going conversation between customers and developers about how a development project should proceed.

Photo credit: jakuza @ flick