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
Labels: agile, product owner, project management, requirements management, scope, scope management, timeboxing
RSS link
1 Comments:
Hi Vasco,
Thanks for posting your thoughts on the problems around deciding how long a feature should take. I have been thinking about this a lot and have had lots of discussions with the developers on my team (I'm the Project Manager).
I'm curious:
* Why do you think a team will work on a feature until it is "perfect". * Why do you think you need to constrain the team and avoid them being left along to decide when a feature is ready?
I'd say the following:
* Why wouldn't the team want to deliver it to production as early as possible in order to get customer value?
* Why can't the developers know what is required to release the feature to production before they start work on it? From my point of view if you want people to do a good job, give them a good job to do. For software developers this means I try and make sure they understand the purpose of a feature (from a customer perspective) and the minimum functionality needed before they start the work. Therefore, they are not "left alone" but can be trusted to use these criteria to measure/evaluate themselves whether the feature is ready for production or not.
On my team we don't estimate (unless it is required). We do release to production every 10 days. I've asked my team a lot "What would you say to the idea that without an estimate around the work you're more likely to spend too long on it?" The key responses have been:
1. We want to ship software which helps our users. We want to do the smallest thing that works and release it at the next available release.
2. It comes down to a matter of trust. You can see what we deliver to production every 10 days. If you think we're 'gold plating' the features then we should have a chat to make sure we're clearer.
To me the Tayloristic separation of decision making from the work is a major cause of waste in software development. I see this in the separation of the Product Owner, as the expert who must maintain 'control' over the developers who must implement the work.
In my view the Product Owner should state their requirements up front (ideally in the form of a problem and the constraints, rather than a solution, a la Tom Gilb) rather than forcing the team to commit to timeboxes. If the Product Owner feels like the solution is not very valuable (and wants to minimize the time spent on it) then this should ideally be described as one of the constraints.
Thoughts?
Benjamin
By
Benjamin Mitchell, at May 03, 2010 11:28 PM
Post a Comment
<< Home