Why Scrum?


I have had many great conversations with people and their stance on Kanban, time boxed iterations, etc… Recently, the conversation has been more towards why we do time boxed iterations? Developers who are fantastic engineers and are practicing many of the models for great software delivery (CI, CD, TDD, etc…) say they should just release the feature when it is done, no need for time boxing.

First, I could not be happier when I hear developers talk like this, they get the fact that we want great software that can be delivered in a pipeline requiring little to no manual intervention. While this is a good thing, it is not necessarily a reason to say time boxes are not necessary. Scrum strives to impact the entire organization, not just the development team. It is not simply about creating user stories, using crafty sequences of numbers that indicate relative complexity and effort, doing sprints, reviews, and retrospectives. While that is the core of the framework, those are just the mechanisms to help understand our progress and expose the issues on how we can improve along the way.

Time-boxes (in my opinion) serve as a good cadence/rhythm that allow for us as a team to deal with all the issues that prevent us from doing better. We get to have some time to review the work we just did as a check-point that we are on the right track, we get to look back as a team and understand ways we can improve, and we get to plan the next iteration. We can focus on seeing what is next in priority, plan how we are going to attack it, and then do it. Outside of those processes is the ability to take all the things that are preventing us from doing better and we get to challenge and educate the organization of our struggles and what we can do to change.

It is not simply about the team (although that is where it usually starts, because that is where the work is happening). It’s about the team showing the organization why it can’t do better and then working to do better. Scrum states “start with a product backlog”, but doesn’t necessarily define or prescribe a way to do that, so let’s work at getting a better understanding of what our software should do and the problems it is suppose to solve. Scrum states “working software at the end of each sprint”, but it doesn’t prescribe a way to do that (by design), so let’s work on our engineering practices to ensure we can get a feature from UI-DB in a vertical slice of the feature all the way through our development environment (what does it take to make a text change in your system and deploy through the entire system to production?).

Scrum is a great framework to help guide you on the continuous improvement journey and deal with the risks, uncertainty, and complexity that exists in software development. Let’s embrace that and have a framework that can help us manage the risk, uncertainty, and complexity. It is very small and simple to understand, but is very hard to do. It takes behavior and discipline to want to do better and stick to that. It is a never ending journey, take the attitude that you celebrate the problems exposed and know there will always be problems, don’t let that get you down. Be an eternal optimist and fight through those for the better.


5 thoughts on “Why Scrum?

  1. Lance,

    Great post!

    I’m also a fan of the time box for 3 reasons.

    1. In the current workplace, especially in the business side of the house, people thrive on regularity in meeting schedules.

    You covered this well as “rhythm” and “cadence.”

    2. It completely encourages teamwork and “individuals and interactions” as the full team participates together in Sprint kickoff activities and Sprint/Time-box closure activities.

    In a flow model, you don’t get full team interaction in these events unless you’re doing true one piece continuous flow, and you can still do one piece continuous flow in a timeboxed model.

    3. It supports using empirical data and transparency to inspect and adapt.

    By fixing the time frame and the people involved, it makes it easier for us to see what works and what doesn’t work each time-box. With a flow model, unless you’re doing true one piece continuous flow, there are extra complexities in the data because the people and time frame change from flow item to flow item — this decreases transparency, and thus the ability to inspect and adapt. Besides, you can still do one piece continuous flow in a timeboxed model — you don’t need Kanban to do that.

    Standalone Kanban has some genius in it that I respect, enjoy and support, but I don’t see it as appropriate for complex work like software development.

  2. Exiting to read about teams that are continuously improving themselves! Use their positive energy to become even better. Great story, thanks for sharing!

  3. Lance,
    Kanban and time boxing are orthogonal concepts; complimentary and not mutually exclusive.

    Kanban tends to promotes single piece flow more effectively than time boxes alone and time boxes tend to convey a number of benefits not specifically prescribed in Kanban. To achieve these benefits, both require a degree of mastery and discipline.

    Arguments in favor of one tool over the other is a lot like arguing the benefits of a vice over a lathe. Both allow one to achieve certain goals provided the knowledge and skills to use them exist. For example, nothing about working in time boxes precludes releasing early; something else is going on there but it’s not a problem with Scrum. Nothing about Kanban precludes updating backlogs, batching up work, measuring work completed, setting goals etc. in a steady cadence.

    Nothing about either tool though guarantees that the complex work of software development is improved without the understanding and discipline required to make effective use of them.

    • Thanks Jay. I did not necessarily want to target Kanban in the article (that was just the word used when the conversation started). It was really about time-boxing (and most people believe the lack of time-boxing means Kanban). I’ll muster up another article at some point on the differences between the two (in my opinion). I totally agree that both are great tools, but I see a lot people jump from one framework to the next and can get distracted on the real goal, which is to solve your organizational problems.

      • > “I see a lot people jump from one framework to the next and can get distracted on the real goal, which is to solve your organizational problems.”

        Exactly Lance! I couldn’t agree more. The trick is to figure out how to educate and motivate leaders to pay more attention to changing aspects of the culture, structures, and priorities that limit the agility of their organizations. That’s one of the primary focuses of the Dallas Agile Leadership Network (http://www.meetup.com/Dallas-ALN/)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s