We have been using Scrum for 6 months now and I am still struggling with the concepts. Perhaps my biggest problem right now is the weird and counter-productive approach to estimation and breakdown.
When we identify a story, my fellow software engineers and I tend to think about how we would implement it, in order to estimate it. We do some pretty engineering heavy work, things like dynamic pricing engines, extreme low latency caching layers over our search sub-system etc. So often how we would go about implementing something tends to heavily influence how long it might take.
But our Scrum Master insists that we estimate the What not the How. So we are not allowed to think about how we would do it when we size it.
Once estimated we then do a ten minute breakdown of the work, breaking it into bite size How’s. So in the end we do need to talk about the How after all.
The problem is that later on, once I’ve started the user story, after 3 hours of contemplation I realise there is a better way of doing it that our 10 minute group think didn’t see (what a shock). But now I’m totally screwing up the sprint as it’s a completely different solution that will take more time, err I mean points (what are points again?).
So WTF basically, I just don’t get it.
Susan: This is a common problem that Scrum newbies have. Basically you still haven’t learned how to think as a Team. Designing software as a group yields better results every time, delivering more value to your business.
Quiet contemplation is terrible for creativity and original thinking! You have to change the mindset and start thinking together as a team. They say that first impressions are usually the best and in my experience the first 10 minutes of group think for implementing a story are the best.
Scrum is great for introverts and brings them out of their shells so they can finally collaborate in team environments and actually contribute value! It’s common for engineers to retreat to their desks and attempt to think up ideas by themselves, but you need to resist that urge. Can working in a team be scary, of course! But push through it and give team working and team creativity a chance.
Dear reader, Susan here. Thanks to Graham for his question today. This is so common, and heart breaking to see these poor engineers during their first attempts at team work. For many, even veterans, it is their first foray into real team working and collaboration. But in today’s hyper-competive market, organisations can’t afford to pamper their engineer’s desire for quiet solo work. A hyper-competitive market requires hyper-collaboration and Scrum delivers that through a fixed and tightly controlled process of meetings and tickets. Organisations finally have visibility of what their engineers are doing and engineers are finally learning to work in teams. It’s a win, win combination.
If you have growing pains or trouble embracing Scrum please submit your questions to Susan by email email@example.com