One of the difficulties I have encountered whilst trying to change the mindset of our development team is getting buy in for the concept of ‘Committing to backlog items’.
This is where the development team get together with the Product Manager(s) in a time boxed (8 hour) meeting (split into 2 sets of 4 hours, the first one to discuss requirements and the second one to discuss / agree what they will commit to doing in the 30 day Sprint).
I’ve been thinking about this a lot recently – I really want the guys to fully embrace SCRUM (and they want to also) but this particular concept is proving a difficult hurdle to overcome.
I think that the root of this is that the team had been working in a classic Waterfall methodology (and had been burnt a number of times on late delivery of features / releases).
The word commit seems to be the problem.
- Their current understanding / interpretation of commit is : “it must be done or we’re going to take heat over late delivery”.
- Whereas the agile understanding / interpretation of commit is : “we will do everything we reasonably can to deliver the feature / release”
It’s actually quite a big step / leap of faith if you have only been used to “it must be done by dd/mm/yy”. I like it’s going to require me forcing the issue so that we do one Sprint in this manner and then demonstrates to everyone that there is no blamestorming if we’re late or drop features
The reason (I suspect) that it works is that with SCRUM you get continual and accurate feedback from the daily Sprint meetings, so if things do go off track then it’s visible and corrective action can be taken earlier.