Scrum helps: Faster projects

In these “Scrum helps” posts I want to share how Scrum helped my projects. In this first post in a series of 3: How can Scrum help you to deliver results faster.

Lately I had to brainstorm on how to fast track our development. We had had external coaching and I gave it quite some thought. For you Scrum Gurus out there; perhaps I’m stating the obvious, but putting these principles firm and open really helped us getting on the right track. We started off on the right foot, but kind of lost some basic principles. I put focus on 3 principles to gain speed:

1. Extreme iterative development
2. Small teams
3. Clear goals

 

1. Extreme iterative development

The difference between iterative and incremental can be illustrated with 2 pictures how a painting is made [credits to Jeff Patton]:

Incremental: build one piece to perfection, then start with the next (painting by numbers)

Iterative: start rough and constantly refine it

Scrum is ideally a mix of both: you iteratively work on different parts of the system. But as putting things in extremes is a good way to make your point; we need to work extremely iterative. Also if this means that after a sprint we deliver a product increment that is not shippable at all. A good approach is to first build a walking skeleton (as Alistair Cockburn calls it); a version of the software that is working, but cut out to the bone. It validates, however, the idea and architecture and can be proofed by stakeholders. This saves time and limits the loss of rework in the case we need to.

You can say that we have to recognize that rework is part of the project, and if so, we best provision for it in our development approach.

2. Small teams

We should work in a small team that should work in a comfortable isolation. Many decisions influence the project and the software solution. However, this should be kept away from the team. Setting short term goals helps to keep on course while business decisions keep on coming and change the critical path to a deployable system.

 3. Clear goals

Hello captain obvious! 🙂 It doesn’t really matter whether we work in agile development streams or in short projects, we need very clear goals. Good goals are of course unambiguous, but also high level and to be achieved in short term.

• High level goals are better because it leaves room for creativity so that the team can fill in the requirements in a way they see best fit. For instance, use a standard library which diverts a bit from the original requirements, but adds value very fast and cheap. This creativity may not yield a “perfect” result as drafted at project start, but greatly enhances speed.
• Short term goals are better because:
  a) They can be grasped by all team members: smaller goals have a human size
  b) They are real enough to have an every-day meaning (every team member understands that if you don’t deliver for 2 weeks in a 1 month project you have a pretty big problem)

Now, having more small separate projects, there is a danger that the parts don’t fit each other.
Obviously, to fit into the bigger picture we need a decent product roadmap to connect all the dots. Also very important is a Big Hairy Audacious Goal; a strategic business statement to focus an organization. A nice example of a BHAG is Amazon’s:

Every book, ever printed, in any language, all available in less than 60 seconds.

This really helps everybody in the team, from PO to programmer, to make the right decisions in every day’s work. We need such a goal for the program, but as well for each sprint (or milestone if you like). A one-liner that focuses everybody, yet leaves enough room for creativity so that team members can use their expert knowledge to be smart and fast.

 

Hopes this helps. If you agree, or have your doubts, please drop a comment.