What if humans can make all their working patterns positive?
Full of engaging stories and real-world examples. The project management method known as SCRUM may be the most widely deployed productivity tool among high-tech companies. If you’ve read the book, this extended summary will help you implement SCRUM.
More information
English: Scrum – The Art of Doing Twice the Work in Half the Time
Author: Jeff Sutherland
Click on:
https://amzn.to/2W5TQn6
Dutch: Scrum – Tweemaal zoveel doen in de helft van de tijd
Click on:
https://www.managementboek.nl/boek/9789491845376/
scrum-jeff-sutherland?affiliate=1910
By far the most projects have been planned and executed by using the waterfall-method.This method is been on Gantt charts which means: lay out every single step in a project in detail. Every milestone. Every delivery date. And cascade each piece of the project down to the next, like a waterfall. Henry Gant invented his famous charts around 1910They were first used in World War I by General William Crozier. However, for project management in the 21st century, they are always wrong. If one step delays, all the other steps thereafter, have a delay. What happens if more steps delay? More time is required and more money and normally it doesn’t deliver anything.
SCRUM is a different approach. It is the only proven way for complex projects. It delivers more stuff with higher quality, lower cost and is done with fewer people. SCRUM embraces uncertainty and creativity. It transforms a project into a learning process, enabling teams to assess both what they’ve created, and just as important, how they created it. Clinging to the old way in the 21st century, of command and control and rigid predictability, will bring only failure. In the meantime the competition that is willing to change, leaves you in the dust.
1. Think and act in cycles
“Inspect, (Demo) and Adapt” cycle
At its root, SCRUM is based on a simple idea: whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually what people want?
Important is “Demos”: Driving towards a demonstrable product on a periodic basis. So teams have to demonstrate periodically what they’ve accomplished. What has to be corrected becomes visible in early each stage of an project. So it’s a way of “failing fast, you can fix early and be successful.” And question whether there are any ways to improve what you’re doing and how you’re doing what you’re doing, any ways of doing it better and faster, and what might be keeping you from doing that.
Plan, Do, Check, Act
Don’t guess. Plan what you’re going to do in short cycles and 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 improvements. Make all the information and measurements of how activities are done, transparent for all the team-members.
Observe, Orient, Decide, Act
Observe: Is clearly seeing the situation as it unfolds.
Orient: reflects not only how you see the world and your place in it, but what world you are capable of seeing.
Decision: The combination of observation and orientation leads to decision which leads to action.
Then the loop begins again with observation of the results of your action and those of your opponents – or, in the business world, Observation of the reaction of the market place. This sets up a constant feedback cycle that accelerates innovation and adaptation and enables the product owner to measure how much value is delivered.
Cycle into ‘ Shu Ha Ri’
SCRUM, like aikido, or, heck, like the tango, is something you can really only learn by doing. Your body, your mind and your spirit become aligned through constant practice and improvement. In the martial arts you learn a concept called Shu Ha Ri, which points to different levels of mastery.
- In the Shu state, you know all the rules and forms. You repeat them, like the steps in a dance, so your body absorbs them. You don’t deviate at all.
- In the Ha state, once you’ve mastered the forms, you can make innovations. Put an extra swing in your steps down the dance floor.
- In the Ri state you’re able to discard the forms, you’ve truly mastered the practice and you’re able to be creative in an unhindered way.
SCRUM is a lot like that. First learn all the rules and the forms, once you’ve mastered them, make innovations. Finally, in a heightened state of mastery, discarded the forms and just be – with all the learnings internalized and decisions made almost unconsciously.
2. Toyota, SCRUM & Agile
Agile & SRUM
The term “Agile” dates back to a 2001 conclave where 17 leading experts in software development wrote up what has become known as the “Agile Manifesto.” It declared the following values:
- People over processes.
- Products that actually work over documenting what that product is supposed to do.
- Collaborating with customers over negotiating with them.
- Responding to change over following a plan.
One of the SCRUM is the framework Jeff Sutherland built to put those values in practice. It has strong relations with Taiichi Ohno’s Toyota Production system. One of the ideas Ohno introduced, was the concept of “flow”. That is production should flow swiftly and calmly throughout the process, and, he said, and of management’s key tasks is to identify and remove impediments of that flow. Everything that stands in the way is waste.
Three different types of waste
Ohno talked about three different types of waste. He used the Japanese words:
- Muri, waste through unreasonableness.
- Mura, waste through inconsistency.
- Muda, waste through outcomes.
Plan, Do, Check, Act: Plan means avoid Muri, Do means avoid Mura, Check means to avoid Muda. Act means the will, motivation and determination to do all that.
Ask this question:
- How do you see if/what do you notice when you’re really getting rid of waste?
Acceleration
In terms of a “project as learning process” it is also necessary to learn from impediments that slows a team down. What you really should want to do is to accelerate teams – not by working longer hours but by working better and smarter. So teams have to figure out the things that slow them down, and each cycle, each Sprint, they try to get rid of them.
Working too hard makes more work
Working more than 40 hours shows that quality and speed slow down. More hours means lesser output. So do something else during the weekend.
Do one thing at a time
Keep in mind: “People (we) don’t multitask because they’re good at it. They do it because they are more distracted.” If you have five projects, a full 75 percent of your work goes nowhere. Three quarters of your day is flushed down the toilet. People can really only think about one thing at a time. Concentrate fully on one thing at a time. Some research has actually been done that shows that multitasking not only wastes your time but makes you more stupid. In experiments, the mean IQ scores of subjects dropped by more than ten points when in distracting environments. Half done isn’t done at all.
Do it right the first time
In a Toyota plant when a problem shows up on the line, every worker has the ability to stop the whole line. When it happens, everyone swarms around where the line stopped – not to yell at the guy for stopping the line, but to fix whatever problem is there. They don’t want any cars coming out the other end with things that have to be fixed. They fix the problem once, and it is solved forever. If they don’t, that same defect goes into hundreds of vehicles. In software development, if a bug was addressed on the day it was created, it would take an hour to fix; three weeks later, it would take twenty four hours.
3. A SCRUM-team
Self-organizing
A SCRUM-team has to be self-organizing and being able to make their own decisions. All the skills needed for the project have to be within the team (cross functional) and located in one room. One team to get the job done. An important question team-members have to discuss and feel is: “What team are you on?” then a team starts to align and synchronize, it can seem magical.
Note: In terms of the size of a team, once a team grows larger than eight, it takes dramatically longer to get things done. The rule of thumb is seven. The team members do not use titles. More important is your expertise and how you contribute to what has to be finished. Titles are specialized status markers. Be known for what you do, not how you’re referred to.
“Pigs and chickens”
There is an old joke in the SCRUM community. A pig and a chicken are walking down the road, and the chicken says. “Hey, Pig, I was thinking we should open a restaurant.” “What should we call it?” asks the pig. “How about ‘Ham and Eggs’?” “No thanks,” says the pig. “I’d be committed, but you’d only be involved!” The idea in SCRUM is that the ‘pigs” are the ones who are totally committed to the project and are responsible for its outcome. The “chickens” are the people who are informed over its progress, the stakeholders. Don’t get “chickens” in your SCRUM team. They always know better, but won’t do a lot.
Role 1 in a SCRUM-team: A Scrum Master
He or she will facilitate all the meetings, make sure there was transparency, and, most important, help the team to discover what was getting in their way. It is the SCRUM master’s job to guide the team towards continuous improvements – to ask with regularity, “How can we do what we do better?” Ideally, at the end of each iteration (cycle), each Sprint, a team has to look closely to itself – at its interactions, practices, and processes –and as two questions:
- What can we change about how we work?
- What is our biggest sticking point?
Keep in mind. Instead of blaming the system, go for positive behavior, by focusing on working together and getting things done. ( For Dutch readers, see also this summary of John Miller’s book ‘Personal Accountability’: http://www.managementissues.com/
index.php/ontwikkelingstools/
77-ontwikkelingstools/
202-personal-accountability-de-vraag-achter-de-vraag )
Role 2 in a SCRUM-team: The product owner
The Product owner decides what the work should be. He/she is accountable for the (added) value of the product and is the backlog owner, what’s on it, and, most important, what order it’s in. However he/she doesn’t have a formal status ‘as a manager’. He has to persuade, cajole and demonstrate, believed and trusted, that his way is the right way. He also:
- Needs to be knowledgeable about the domain.
- Has to be empowered to make decisions.
- Has to be available to the team, to explain what needs to be done and why. The team members rely on the product owner for the “vision”, and also market intelligence on what’s important.
- Needs to be accountable for value. In business context what matters is revenue. A product owner can be “measured” per “point” of effort. The key is to look for what slices actually hold value. Enough value that you can get real feedback on them and react in real time (see observe, orient, decide, act).
- Has the ability to adjust on the fly in a constant changing world.
- Knows the art of practice of rapid proto typing.
- Thinks and acts in “first things first” in orders that are always “in flux”.
- Know to think in, and apply, the 20-80 rule in terms of added value. Improve every time by just focusing in every development cycle on the 20% that creates the most added value. By doing that he knows how to deliver real value as fast as possible. For finding out, the product owner puts incremental releases in front of customers quickly.
3. The Sprint
Time boxes
Sprints are what often called “time boxes.” They’re of a set duration. You don/t do a one-week Sprint and then a three-week Sprint. You have to be consistent. You want to establish a work rhythm where people know how much they can get done in a set period of time. Often that quantity surprises them. One critical element of an individual Sprint, though, is that once a team commits to what they’re going to accomplish, the tasks are locked in. Nothing else can be added by anyone outside the team.
There are no tasks; there are only stories
How many times at work have you been given a job where you don’t understand the reason you’re doing it? Better is to write a short story about that job yourself. Make it small enough to estimate it. What is the result? Image it. How are you going to This stories are the ones that a team can wrap its head around. A short story needs to meet the INVEST criteria:
- Independent:
The story must be actionable and “completable” on its own. It should be inherently dependent on another story. Negotiable: Until it’s actually being done, it needs to be able to be rewritten. Allowance for change is built in. - Valuable:
It actually delivers value to a customer or user or stakeholder. - Estimable:
You have to be able to size it. - Small:
That story needs to be small enough to be able to estimate and plan for easily. If it is too big, rewrite it or break it down into smaller stories. - Testable: The story must have a test it is supposed to pass in order to be complete. Write the test before you do the story.
Sprint planning
Sprints are always a fixed length of time that is less than a month. Answer these questions:
- What can we accomplish at this Sprint?
- Are the stories ready?
- Can they be done by the end of its iteration?
- Can we then demo them to the customer and show real value?
Look also to the velocity. Ask questions as:
- What is keeping us and you from going faster?
- What is keeping us and you from accelerated?
- Is there anything we can do differently to speed things up?
- Can we offload some backlog items? Is there stuff other teams can do better?
- Can we not do somethings?
Question everything!
Make everything visible: use a SCRUM board
One element of SCRUM that often is a prelude to achieving autonomy, is transparency. The idea is that there should be no hidden agendas, no secret cabal, nothing behind the curtain. All SCRUM meetings are open for everyone in the organization and make a SCRUM-board. The SCRUM-board is a bunch of sticky notes on a white board: to do, in progress, done.
|
Name Project Team: Awesome! |
|||
|
Backlog |
To do |
In progress |
Done |
|
User story 1 |
|
|
|
|
User story 2 |
|
|
|
|
User story 3 |
|
|
|
|
User story 4 |
|
|
|
|
……….. |
|
|
|
Plan fantasy, not reality
Don’t make detailed Gantt chards. Don’t spend months of effort making the sort of detailed plans that seem plausible. Don’t fall in love with your plan. It’s almost certainly wrong. Keep in mind: “The map is not the territory.” Plan Sprints.
Daily Stand-Up
The project team can gather every day. The Scrum Masters, the person in charge of running the process, asks each team member three questions.
- What did you do yesterday to help the team finish the Sprint?
- What will you do today to help the team finish the Sprint?
- What obstacles are getting in the way?
Team-member Questions to be asked after each cycle/sprint and before starting the next one:
- What did you do since the last time we talked?
- What are you going to do before we talk again?
- And what is getting in your way?
Happiness: address the team’s mental and emotional state
If you ask team members when they were happiest, when they experienced true joy, they’ll tell you it was those moments of trial – of pushing their bodies, minds and spirits to the limit. That’s when they were happiest, when they experienced true joy. So the journey itself was the joy. In bureaucracies we are not rewarded for enjoying the journey itself but for the successful completion of a journey. However, people are not happy because they are successful. They are successful because they are happy! Even just a little bit of happiness leads to markedly better outcomes. So at the end of each Sprint, each person on the team answers just a few questions:
- On a scale from 1 to 5, how do you feel about your role in the organization?
- On the same scale, how do you feel about the role as a whole?
- Why do you feel that way?
- What one thing would make you happier in the next Sprint? (What would make you happier?)
- How do you know that thing is realized?
- Search for KAIZEN.
Steps in a SCRUM project set up
- Pick a Product Owner
- Pick a Team
- Pick a Scrum Master
- Create a Prioritize a Product Backlog
- Refine and Estimate the Product Backlog. Do not estimate in hours but in terms of “size”. Give point value to each item using only Fibonnaci numbers: 1, 2, 3, 5, 8, 13, 21, etc.
- Sprint Planning: The first of the SCRUM-meetings.
- Make work visible. Use a SCRUM board and/or happiness index.
- Daily Stand-up or Daily SCRUM The SCRUM-master asks these three questions:
- What did you do yesterday to help the team finish the Sprint?
- What will you do today to help the team finish the Sprint?
- What obstacles are getting in the way?
- Sprint Review or Sprint Demo. This is the meeting where the team shows what they have accomplished during the Sprint. Anyone can come, not only the Product Owner and SCRUM-master, and the team, but stakeholders, management, customers, whoever. The team should only demo what meets the definition of done.
- Sprint Retrospective After the team has shown what they’ve accomplished during the last Sprint, they sit down and think about:
- What went right?
- What could have gone better, and can be made better in the next Sprint?
- What is the improvement in the process that they, as a team, can implement right away?
- What earlier improvements had as an effect on velocity.
- Immediate start the next Sprint Cycle
Max Herold, PhD
May, 2019
