Monday, June 2, 2008

Let them Fail...

I was requested to visit a scrum team that needed some extra help with their planning. That was my personal lesson about letting team to fail in order to learn from their experience.

I joined the teams planning as chicken (= not allowed to speak). Their ScrumMaster asked me to collect some notes and then after the planning to give the feedback about their way of executing the planning session. My first note was that their Product Owner was not present in the meeting. However they had done some preparations and they got prioritized backlog so they started by pulling the stories from it. The stories were not in story format and they were overly complicated as they contained tons of technical details. I noted that these stories must be something their Product Owner has not understood as even I had hard time grasping them (with my 10+ years experience in software development).

After some time the whiteboard was quite full of stories. I thought that these guys must be hyper-productive already though I had some doubt about it. I asked their ScrumMaster what is their current velocity. I could read the confusion from his face as he asked me back "what do you mean by velocity?". Instead of going trough scrum terminology I just calculated their average velocity over last 7 sprints or so. Their average velocity was around 45 story points but their current sprint contained stories that totaled over 150 story points! Obviously the team was about to overcommit.

I raised the fact of overcommitment to the team and challenged them to think it as "lying to Product Owner as he makes business decisions based on the given information". They protested by saying that "we need to show that we are at least trying to make it happen - we are about to have release soon and we must have these features in it". I told them that it is not the teams responsibility to think even about release schedule. Rather the team just gives the effort estimates and Product Owner comes up with release plan. Actually the team had been (micro)commanded & controlled for last few years so they had hard time understanding the self-organization and empowerment that is involved in scrum.

I also asked them if their Product Owner understands the stories. They told me that Product Owner had not even seen the stories! I asked how they have come up with them in first place and they told that Product Owner had given them an epic story (BIG story) and they had asked what does it mean... Product Owner told them to figure it out what it means and thus they had done one sprint with spike "figure it out" and then done second sprint with their own stories that were results of "figuring it out". I realised that their Product Owner was not doing his job and basically the team was responsible also for the ownership. They did not have transparency towards the business side (stakeholders, Product Owner...) and therefore they also felt responsible for release planning.

I told the team that it is their responsibility to not to commit unrealistic schedule but they still did. Finally I had to let them fail - they overcommitted and ... failed ... and hopefully learned the lesson.


Unknown said...

I would be interested to hear if they did in fact learn the lesson. I have seen this happen several times with teams, but it is difficult to overcome the mindset of "you must do everything the business wants", and I am not sure that a team would learn the lesson from one experience like this. I'm trying to find a way to help teams learn this as they continue to fail and miss their sprint commitment.

Marko Taipale said...


Thanks for the comment!

I happen to talk a lot to my teacher wife about teaching, learning, motivating people to learn etc. Current conclusion from those discussions is that you can only facilitate learning but you cannot force learning to happen.

That is also what happened with the case. The PO left the company so I cannot tell if he learned anything from this. Some, but not all team members "got it" and are currently members of Scrum teams not having this problem anymore.

The team members were from various cultures and I think that had big impact on the outcomes. Certain cultures are simply respecting authority much more than others and that might have be part of the issue also in this case.

One thing to try (if you yet have not) is to set up a pretty tight Work-In-Progress limit to your team and measuring the cycle times for items. In long term you can tell how long items take to go trough the system and empirically limit the overcommitment.

Unknown said...

I wonder how useful "letting them fail is". It's probably *more* useful than letting your words fall on deaf ears, but I've seen teams make the same mistakes over and over and over again.

It's a tough problem. Wish I knew the solution :)

Marko Taipale said...


Ofc it is not very useful if you let them fail on the same issue IN THE SAME WAY twice (~= stop learning). I think it is ok to fail multiple time on same problem but by experimenting different solution.

So.. my conclusion is that learning is the key. Do whatever to facilitate learning.