Sutherland co-founded the Scrum methodology as an implementation of ‘Agile’, in the mid-1990s. The premise is straight forward enough: end the corporate inertia, bafflegab, seances, endless meetings, hand-offs and water-fall based time delays, and actually produce something. The main benefit of Scrum-Agile is that cross-functional teams work together in the same room to achieve concrete and measurable objectives. Scrum is really an implementation of SMART objectives – Simple, Measurable, Achievable, Realistic, Time-bound. Instead of having huge projects or complex tasks, Scrum breaks down the work into smaller projects achieved within 2-4 weeks of work. Productivity can increase in the order of many hundreds of per-cent.
Not everything in Scrumland is butterflies and orange sunsets of course. But compared to the way most people, groups and firms actually work, it is an infinitely superior way to approach projects – be they in IT or outside of technology. Scrum is a cultural change. An attitude. A dedication to quality with velocity. A system of responsibility. A small team with specific targets who cannot fail. Scrum simply enhances and elevates work, skills and even the self-esteem of the team members.
Scrum has only 3 actors.
- Cross functional team member of a group of no more than 9 people (less is more).
- Scrum Master, who can be technical but whose main role is to help the team figure out how to do the work better.
- Product Owner. Typically marketing, sales or someone who knows what the client actually wants. Not a conehead. A person who comprehends non-technical deliverables and necessary functionality. This person owns the product and owns what is called the Backlog, or what the team is working on to build the product.
Unlike traditional methods who do not have an active Product Owner, within Scrum this role must deliver feedback to the team from the customer after each and every Sprint. A sprint is a body of work that lasts 2 – 4 weeks maximum, dedicated to producing a discrete requirement. The Backlog is the list of work to be done during the sprint.
The first thing you need to do when you’re implementing Scrum is to create a Backlog. It can be hundreds of items long, or contain only the few things that you need to figure out first. Of course, you need a clear idea of what you want at the end of the work. It could be a product, a service, a tool, a widget. It matters not. The end result is clearly defined. The Backlog will provide the work-tasks to build it.
This leads to Sutherland’s view on Velocity or speed of work. Scrum should make your development at least 2x faster than normal waterfall methods. Every team should know exactly how much work they can get done in each Sprint. And they should know how much they can improve that velocity by working smarter and removing barriers that are slowing them down. Velocity × Time = Delivery. Once you know how fast you’re going, you’ll know how soon you’ll get there. The team should constantly remove obstacles, look to increase speed and output and realise that 100% improvement in output and time, during a project is pretty standard for Scrum.
Some key points from this book that Sutherland makes and emphasises would include:
1 ) Scrum works by setting sequential goals that must be completed in a fixed length of time. Many firms using Scrum have two-week cycles, with the understanding that, at the end of each cycle, there would be a finished increment of product. That meant they’d have something working, something that could be shown to anyone who cared to look but certainly the stakeholders and, optimally, the people who’d actually be using the thing.
2 ) Real time feedback during the sprints. Given the daily meetings and client interaction and review we can see how well we are doing. Is the group headed in the right direction? Is what they’re planning to do next really what they should be doing, given what they’ve discovered during that cycle? In Scrum we call these cycles “Sprints.” At the beginning of each cycle there is a meeting to plan the Sprint. The team decides how much work they think they can accomplish during the next two weeks.
3 ) Team work. The team knows how much work is involved. The team will take the work items off that prioritized list of things that need to be done and often just write them out on sticky notes and put them on the wall. The team decides how many of those work items they can get done during this Sprint.
4 ) Constant reviews. At the end of the Sprint, the team comes together and shows what they’ve accomplished during the time they’ve collaborated. They look at how many of those sticky notes they actually got done. Did they bring too many into the Sprint and not finish them all? Did they not bring enough? What’s important here is that they begin to have a baseline sense of how fast they can go—their velocity.
5 ) Demo often. The most powerful part of Scrum in many ways is showing the client a demo every 2 weeks at least. Scrum is not about the developers. It’s about the customers and stakeholders. They need to see evidence of progress.
6 ) Culture. Observe, Orient, Decide, Act. Know where you are, assess your options, make a decision, and act! Look Outward for Answers. Complex adaptive systems follow a few simple rules, which they learn from their environment. Great Teams are cross-functional, autonomous, and empowered, with a transcendent purpose. Don’t Guess. Plan, Do, Check, Act. Plan what you’re going to do. Do it. Check whether it did what you wanted. Act on that and change how you’re doing things. Repeat in regular cycles, and, by doing so, achieve continuous improvement.
7) Work smart. Make a graph. The y-axis is productivity, and the x-axis is hours of work. The peak of productivity actually falls at a little less than forty hours a week. Teams are individual and unique. Each has its own pace and rhythm. Forcing them into cookie-cutter processes is a recipe for disaster.
