We’re implementing Scrum as a process framework for the development of our projects. We’re iteratively implementing it, sprint for sprint. Therefore, this is not a post on how we do Scrum, rather it is a post on why we’re implementing it.
Reason #null: It’s agile
It’s so fundamental that I’m not going to justify this with a real number, even. It gets a null. We rarely have a complete picture of where we are going when starting a project or a product. Thus, we need an agile approach that supports making discoveries while underway that can, and will, be included in the continuous planning process of the project. We’ve always had an agile approach, but Scrum seems to complement and improve our own more intuitive approach.
Reason #1 : It’s a framework
That sounds ambiguous, but nevertheless, it’s of the most vital importance for our choice. Admitting that the process of creating great software is an intellectual process, you don’t want a full-fledged (big M) Methodology to govern and control you, just as little as you’d want that if you are trying to be a great novelist (another intellectual undertaking). You want to provide room for, and focus on, the day-to-day contributions and decisions from the development team, not the general approach solutions governed by a Methodology. We want a light-weight framework of simple rules for inducing our great potential as software designers and developers. We are so naive to assume that every employee wants to do their best, and that any rules, processes and frameworks that exists should be there to help them perform at the peak of their potential, rather than see to it that they do their work as they should. We believe the values and processes of Scrum supports this approach.
Reason #2 : Power to the people.
Day-to-day decisions — this is where the magic happens. Scrum realizes and supports this. During the sprint the developers are empowered, and they are able to do their jobs with minimal outside interference. The communication within the team is continuous as daily “Scrums” (short status meetings with no reporting, max. 15 min. regardless of team size) ensure that everyone is clear on daily objectives and progress, with minimal overhead.
Reason #3: Natural selection
Before every sprint (month long development cycles), new priorities are applied to the functionality wish-list (the product backlog) by the product owner. Only the tasks that will create the most value for the business objectives for the software will be put into the next sprint. When the sprint is full, no more tasks are added. This ensures a few vital properties of the project. 1) Natural selection. Low-value functionality in the wish-list will sink to the bottom and into the black hole. This is good, as no coders wants to code low-value functionality, and no product owners wants to pay for it, at least not before having the more important functionality working really well. 2) Just before the sprint, we can use the experience from previous sprints to do better estimation and we know more about the project, so we’ll plan better too.
Reason #4: Done
Scrum emphasizes the value of Done, with a capital D. During “The Demo” at the end of each sprint, no functionality that is “almost done” is given any attention. The goal is to get to Done (potentially ready for production) on all tasks committed to in the sprint. Thus, Scrum applies a focus on doing one thing right before doing four things half-assed. We value this as fundamental and as an imperative attribute of great software development.
Reason #5: Continuous improvement
The retrospect provides a great opportunity for self-improvement. We talk about what went good, and we talk about what can be improved. There should always be something to improve. We pick the most important improvement suggestions, and put them into the next sprint backlog to improve it during the next sprint. Not all improvement suggestions are acted on, but just having heard them sometimes makes all the difference. Scrum provides a placeholder for this activity which we cherish as one of the most important ones for being able to continuously improve the way we work.
This list does not cover all the reasons for going to Scrum, and we are definitively not Scrum Masters, yet. However, these are some of the discoveries we’ve already made. I will make an effort to extent and improve this list as we gain more experience in Scrum.