6 Months In: Our Scrum Experiences

We’ve been scrumming for about 6 months. It’s been great fun, and it’s about time for a recap. This post covers the benefits and challenges discovered so far. Also, we offer some warnings to anyone currently considering to adopt scrum.

3 Benefits

Team communication has improved. There’s less of the “I’ll go off do this and you’ll go off and do that and we’ll talk later, sometime”, and team members suddenly discovering they’ve drifted apart. Daily scrums keeps us aligned. These micro meetings will often lead to some form of micro coordination or resolution of a micro dependency, and everybody stays well informed on the right level of abstraction. It makes it all just a bit more organic.

Asking good questions is at the heart of good communication. Scrum’s questions has shown to foster good dialogue, be it in daily scrums, retrospects, demos or during sprint planning.

Improved focus. We care more for what we’re doing today, and worry less about what we’re doing tomorrow. Scrum has helped us lay out the details for the next 30 days. Beyond that time limit, Scrum protects us from entropy by requiring coarser story details. You might think of it as if Scrum has told us to :

“Focus on solving today’s most important problems today, and nothing else. Repeat this tomorrow for tomorrow’s problems. Tomorrow we’ll have a simpler solution for tomorrow’s problem and we’ll focus on them then.”

This is harder than it sounds, but the benefits of this approach is priceless.

Simplifications. Scrum has brought us a concise vocabulary. Scrum has provided simpler building blocks. It has simple requirements and few, simple and effective procedures. Being a manager of Scrum teams feels like being a house-builder building a foundation with Leca-blocks instead of the more loose and wet clay and strangely shaped stones we’ve been used to. Any time you are able to do simplifications, it usually ends up leveraging something unexpected.

3 Challenges

Estimation was hard during the first few sprints. The two most common mistakes were that we created to big tasks, and that tasks thus were intangible and tended to overlap. The result was that the burn-down graph tended to flatten for a few days, or even weeks, before a cascade of “done’s” came rolling in. This lead to little or no measurable day to day progress, which weakened communication and made the sprint less understandable. We have become quite good at this now.

Unplanned tasks. A highly volatile and unstable project will have a lot of unplanned tasks during a sprint. Planning 30 days without considering this, poses a challenge. We’ve started to try to measure the “plannability” of a project and to plan with a buffer for any “unplannability”. This buffer is merely a task which has an estimated of, say, 20 hours of work for hunting down and fixing bugs that are unknown during sprint planning. Whenever a bug report comes in, we know that the sprint does not need to be invalidated or re-planned even if bug count gets higher than expected.

Focus. Being used to the normal state of entropy of more ad-hoc planning approaches, we’ve developed a habit of jumping back and forth between projects and tasks to ensure that we’re maintaining an overview and a little progress everywhere. This isn’t required, nor is it even remotely desirable, to have good progress and overview in Scrum. Scrum shows us that such an activity is wasted time and energy, as multitasking usually is.

You could say that we’re still building the confidence to let go of the controls, focusing on one thing at a time and bringing it all the way home. This old habit of “everything almost done so that I’m able to respond to sudden deadlines”, has lead to some of our sprints suffering the “90% done syndrome”. You know, where you do just enough everywhere, so that when a real need arises, you’ll be able to assemble the last pieces in a hurry to make a deadline. Scrum Demo becomes a little embarrassing using this approach (you’re only allowed to demonstrate functionality that is 100% done, and potentially ready for production.

Thus, Scrum makes an effort to inform us that “the only valuable states are 0% and 100%”. The great part is that Scrum has really revealed to us the endless advantages in keeping this focus all the way until that 100% mark is reached. We still have some effectiveness to gain from trusting this more, and focus on one thing at a time until done.

2 Warnings and One Advice

It’s hard. So pay attention and make sure you have someone devoted to understanding the process and it’s benefit. Scrum isn’t by any means a silver bullet. There are no silver bullets, and Scrum requires attention and nurturing to work, as any benificial relationship does.

It’s even harder when under duress. It’s normal for humans to revert to old habits when stressed. Realize and prevent this. It’s through rough times that success of change show it’s true face.

Use the retrospect for all it’s worth. Ask open honest questions about how you’ve been doing and evaluate with an open mind. The longer the list we’ve had under the “What can be done better next time?” the more progress we are experiencing. Aim for finding everything that can be improved, and addressing something every time.

Our Hopes

As we noted during our first assessment of Scrum, Scrum is a simplified set of the most effective practices, and not more. As far as software engineering goes, Scrum says little about day-to-day principles and practices. We still regard this as one of it’s strengths. Scrum has helped us increase effectiveness of project management and communication, all while being small and simple enough for us to manage the transition well.

We’ll now have to look for opportunities to put our newly freed capacity to work on improving our day-to-day practices.


Scrum is no silver bullet, but with the right care Scrum has ended up improving communication and focus, and it has simplified and decreased project overhead. The benefits has far outweighed any challenges, and we are now hoping to take the discussion to the next level, while continuing to improve and refine our Scrum process. Scrum itself helps us maintain this process of continuous improvement.

I write and write about Scrum, but you should not let this intimidate you. Remember, as I’ve mentioned before, that where Scrum rationale and analysis can cover post after post, book after book for years on end, the process description itself remains small, simple and quite manageable.

Stay tuned to see where we’ll go to next.