Today I experienced a very interesting sprint review / planning. We had a lot on our minds and a lot was put on the table. Fortunately, it was done in a very constructive way that decreased the tension that had been building up during the last weeks. But this also had the effect of driving me right back to reviewing some of the agile principles that we had voluntarily been ignoring until now. The point of the discussion was “teamwork” and specially “what to do when somebody in the team needs help?”.
At the very begining of our agile transition, we followed the planning principle as close as possible. We were estimating stories using an online planning poker tool (our team is distributed between Germany and Slovakia), we picked up exactly the amount of story points that we had reached during the previous sprint as a target for the planning and left all the cards open (but prioritized) for anyone to pick during the sprint.
1. Side effect of a strong ownership
After a while, we realized that our team composition, availability and experience was producing a very high variation of the workload and thus the velocity could not be stable between two sprints. The main effect of this was to make us unable to estimate if the workload planned for a sprint was achievable or not. In order to cope with this, we decided to assign most the cards to some people so that they can guess the feasibility ; at least until we got the root cause of the team velocity’s variation adressed. And it worked fairly well, we ended up with fewer cards open at the end of the sprints ; sometime even close to none.
But this unfortunately had the nasty side effect of producing a sense of “ownership” on the tasks. If it is pretty easy for someone to leave something aside if it is general, it comes to be way harder once it has your name on it. Instead of a mutually beneficial tool, “helping your colleagues” became a double sided blade which can put you offtracks with your tasks if your colleagues are “knowledge black holes” like newbies typically are… nasty side effect… really…
2. Guesstimates talks
Estimating stories with an online tool produces an awful overhead and does not necessarily results in us concentrating on the real deal: discussing the inconsistencies in guesstimates that often mean that something is not understood. We lacked in consistency here and switched back to doing ad-hoc guesstimating way too fast.
Unfortunately, there was a side effect here as well. Not using a tool where you are forced to give your estimate before you can see your colleague’s, we achieved a consensus way faster than we should have. Thus we sometimes avoided having the difficult conversations that would have inherently emerged from surprisingly low/high guestimates. Doing so, we tended to letting things unsaid with people not realizing that they did not understand something.
Final words
I must say I now understand better the purpose of those two ideas carried on by Scrum that are the “planning poker” and the “collective-ownership”… but I guess it was a lesson I had to learn from the bitter end first. I now have 10 days to prepare myself for the next sprint planning and think about some other points that emerged in my mind but are not “mature” yet like the “length of the planning session”…
[...] [Agile] Two SCRUM lessons bitterly learned [...]