What if Scrum had no Rules?
•Download as PPTX, PDF•
1 like•1,001 views
What if Scrum had no rules? How would we define it? What if there were no Scrum? How would we create it? Scrum is based on successful patterns for product development. During this workshop, we will reflect and share the experiences from our own best projects, and look for patterns in those projects.
Recommended
More Related Content
Viewers also liked
Viewers also liked (18)
Similar to What if Scrum had no Rules?
Similar to What if Scrum had no Rules? (20)
More from Peter Stevens
More from Peter Stevens (20)
Recently uploaded
Recently uploaded (13)
What if Scrum had no Rules?
- 1. What if Scrum had no rules? Peter Stevens Agile Tour Bangalore November 8, 2014 Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0)
- 2. Imagine! It’s 1993 and you are Jeff Sutherland…
- 3. How do you identify successful patterns? Outliers
- 4. We can also use our own experience to identify outliers!
- 5. I believe agreements are stronger than rules
- 6. I believe agreements are stronger than rules Let’s explore great projects together 1. Tell & listen to stories of great projects 2. Identify those projects most worthy emulation 3. Identify the patterns in those projects Could we agree to do something similar?
- 7. Can we agree to respect the timebox?
- 8. Share your best experience… • Groups of 6 • Timebox 1:30 / person = 9 minutes total!
- 9. Remember that face! and Regroup!
- 10. Share your best experience… • Groups of 6 • Timebox 1:30 / person = 9 minutes total!
- 12. Find the project you’d most like to emulate!
- 13. Let’s hear the best projects! • The 3 most popular projects • 1:30 / per person
- 14. How many of you… Told the story of the project you are working on today?
- 15. Could you…? Agree with your colleagues to make this project your best project?
- 16. What would you be agreeing to?
- 17. What are the characteristics of these great projects? • How would you describe the purpose of the project? • How many people were involved? • What skills did they have? • How often did they produce something that worked? • What were the characteristics of the leadership? • How did people work together? • How would you describe the motivation of the people involved? • What factors enabled the motivation? • What was the relationship to the beneficiaries of your work (customers)?
- 18. Could you agree with your colleagues… To implement these patterns?
- 19. I believe If you implement these patterns you get something that looks a lot like Scrum
- 20. What are the patterns that Scrum implements?
- 21. Deliver regularly something that works
- 22. Inspect and adapt at regular intervals
- 23. A single voice speaks for the customer / user / stakeholders
- 24. A small, interdisciplinary team solves the problem
- 25. Great performance comes from continuous improvement
- 26. Management helps but stays out of the way
- 27. What if…? We consider Scrum as collection of working agreements?
- 28. Vote! • Agreements are more powerful than rules! • Vote to elevate the status of agreements in the Scrum Guide • http://tinyurl.com/ScrumAgreements
- 29. “Let’s make this project your best project!” • Peter Stevens – scrum-breakfast.com – saat-network.ch @peterstev peter@sierra-charlie.com
Editor's Notes
- At the Berlin Gathering, one of the sessions raised a provocative question: What if Scrum had no rules? How would we define Scrum? I have long believed that Scrum emphasizes the rules too much and that people do not like to follow rules. Furthermore, the widespread perception that Scrum practitioners obsess over following the rules has not been conducive to Scrum’s growth. There has to be a better way.
- In 1993, Jeff Sutherland recognized the need for better ways of organizing software developers. He looked at the usual suspects and did not find anything that resonated. As an academic, he next looked for research that might indicate a good solution. He found “The New, New Product Development Game” and this became the inspiration for Scrum.
- Jeff also found research which indicated that the best software teams – the 95th percentile – were 10 times more effective than the typical team. Jeff zeroed in on these projects. What made them so much better? Were they super genius developers with a natural advantage? No, the conditions enabled them to be productive. But looking at outliers, those teams with performance way better than the norm, he was able to identify the conditions that Scrum should create, so any team could be much more productive. So far, so good, but most people don’t change their behavior based on academic research.
- In 1993, I developed a software to manage centrally networks of UNIX workstations. Today, I would call it my first Scrum project. I demonstrated working functionality every week. My customer and I reviewed the results every week, and planned the next objectives of the following week. Every week, the software could do a bit more than the week before. When I needed something, my customer gave me what I needed. He protected me from distractions. Over the course of 4 months, I created a system a) could ultimately manage networks of over 200 Unix workstations, and b) became the basis of my career for the next 10 years. Only in the last few months, did I realize, that this was 1993! Exactly when Jeff was creating Scrum! If only I had written these patterns down!
- As a Scrum Trainer, I have travelled to many countries and experienced many cultures. Most of Europe, Russia, India, Vietnam and Texas are among the more exotic and diverse places I have visited. And while cultures are diverse, people are surprisingly similar. Fundamentally, they want the same things. Respect, Recognition, Challenging Interesting work, etc. In my courses, I always make working agreements with the group. It starts with a simple question: What agreements do we need to work together effectively? The results are almost always the same. We want to be punctual (to not waste time), we want to turn off cell phones and other devices (to avoid distractions and remain focused on the course), etc. Agreements are very powerful. You enter an agreement with others freely for you own (and their) benefit. You commit to uphold the agreement and you can demand that the other parties live up to the agreement. What if Scrum were defined as a set of working agreements?
- I’d like to explore that idea with you. First, I’d like us to look at our own great projects to find the projects most worth emulating. Then we’ll share the best projects with the entire group, and finally identify some of the patterns in these projects. If you identified great patterns together with your colleagues from your own experience, do you think you could agree with them to make your current project look more like your best projects? Before we answer that, let’s share our experiences…
- We are about to start group work. Since we are in a conference, timing is tight, and we are not allowed to go over. So can we agree to be respect the time-boxes? (Everyone nods) So lets agree on how to do it. (Here I explain the “One conversation” pattern – everyone holds their hand up and stops talking when the time-box is over. And we agree to do it).
- (Everyone tells the story of their best project to their table mates. I sound the gong every 90 seconds to help people keep track of time. After the last gong, I hold up my hand, every one else stops talking, those that don’t are shushed by their table mates. In a few seconds, we are ready to move forward.) Awesome! Did you see what I did? We made a simple agreement, everyone agreed to it, and now we are working together as a team! Would we have gotten the same performance if I held up my finger and said ‘stop talking’? Probably not.
- Remember who told the best story (besides your own) in your group. Now change tables to maximize the number of new faces in your group.
- Now tell the same story again.
- Now you have two great stories.
- Which one is the best story? The project you’d most like to emulate? You have two candidates. The best from the first round and from the second. Put your hand on the shoulder of the person who told that story. No, you can’t vote for yourself ;-)
- Let’s hear the stories from the three people who got the most votes.
- Typically between 0 to 10% of the participants answer yes to the question. Sometimes I see as high as 30%, in which case the additional 20% are all doing Scrum. (Today, about 30% told the story of their current project, and all but one were doing Scrum). If you’re not having you best project now, would you like this project to become your best project? (everybody nods). Of course you would! Who wouldn’t?
- Do think your colleagues would like to be doing their best projects too? (everybody is a bit puzzled).
- Wait a minute! What are we agreeing to? Let’s look at this in more detail…
- What patterns do you recognize from these great projects? Here are some questions you might want to ask. In groups of 2 or 3, discuss what stood out for you in these great stories you heard. We’ll take two minutes, then listen to the highlights from a few pairs.
- If you did this workshop with your colleagues, do you think you could agree with them to implement these great patterns from their own experience? It looks a lot more likely now, doesn’t it? Do you think you will face much resistance given that everyone agrees to it and wants to go there?
- … or if you implement Scrum, you are doing something get something very close to your own best experiences! Let’s look through the fundamental patterns of Scrum….
- Scrum says we have to have something potentially shippable, at least once per sprint.
- Scrum goes further, and says we have to inspect and adapt at regular intervals, which means that all activities – Sprint Planning & Review, Daily Scrum, Sprint Review and Retrospective are time-boxed.
- The Product Owner carries the vision and requests to the development team, and is a single point for decision making.
- A team of up up to 9 people, who have all the skills necessary to take a problem from idea to “done” work together to solve the problems formulated by the product owner. They have jurisdiction over how they solve problem and how much work they take on.
- Great athletes know that to get better, they need to improve a little bit, every day. The core principle of Scrum is “Inspect and Adapt”. Adapt means “change for the better.” So each activity in Scrum is an opportunity to improve. Scrum borrows from sports the notion of a coach, who protects, teaches and develops the team, so that they become capable of higher performance (and have more fun). Each sprint should produced an improved products, and an improved, happier team.
- Management provides leadership and vision, in the from of passion, energy, support, protection. When the team needs help, the leadership roles are expected to provide it. But when their help is not needed, they are expected to stay out of the way, so that their well-meaning intentions do not to turn into counter-productive micro-management.
- If Scrum were treated a set of working agreements, I believe we would have easier transformations. I believe working agreements are also the framework for enabling a team to improve beyond the basics of Scrum. If a change to your Scrum causes you to inspect and adapt more often, it is probably a good thing. If the change is the result of an agreement among the Scrum Team, or between the Scrum Team and its stakeholders, to become more effective, it is probably a good thing. Conversely, if the change is an accommodation to one party’s refusal to engage and make sensible agreements, it is probably a bad thing.
- I believe working agreements in Scrum are so powerful, that the status of Agreements should be upgraded in the Scrum Guide. Please use you votes to help make this happen! Thank you. Vote here: http://tinyurl.com/ScrumAgreements
- peter@sierra-charlie.com www.scrum-breakfast.com