Ken Schwaber, the founder of Scrum, has a blog. In it, someone mentioned that Scrum is changing. Ken responded:
If you change the Scrum framework you just simply aren’t using Scrum and are probably canceling some of its most important benefits.
Thank you Ken! I wholeheartedly agree. Every CSM class I teach, I emphasize the complete nature of Scrum as a single tool, not a collection of tools. Learning Scrum is about learning the tool, not learning how to pick and choose pieces of a tool. Let’s explore this metaphor of Scrum as a tool.
Consider a hammer. A hammer is ideally suited for pounding nails into wood. It has two parts: a head and a handle. If you take the parts and use them separately, they can still be used for pounding nails into wood… but they are very ineffective compared to the hammer (although better than using your bare fist). It is non-sensical to decompose the hammer and try to use the pieces separately. However, a hammer is not suited to other purposes such as driving screws or cutting wood. It’s perfection is not just in its form, but also in its proper application. A hammer works through a balanced combination of leverage and momentum.
Scrum is like a hammer. It has parts (daily Scrum, Sprints, ScrumMaster, etc.), but taking the parts and trying to use them separately is… you guessed it… non-sensical. The parts of Scrum combine to be an extremely effective tool for new product development. Just like a hammer, there are things you wouldn’t want to do with Scrum such as manufacturing or painting a wall. (We might not all agree on the limits of the use of Scrum… that’s something for another article.) Scrum works through a combination of pressure on the organization and “inspect and adapt” (continuous improvement).
Please. Don’t modify Scrum. If you must change things about Scrum, please stop calling it Scrum.
PLEASE NOTE: these are my own notes based on the presentation – any errors or omissions are my own.
TOPIC: Treat People as Adults
- “we need to X first”… e.g. X=architecture
- – this is a parent-child approach – need to tell someone how to do something
- – does this mean we are not adults?
- – only through direction and planning will we do intelligent things
- Story from “Scrum in the Enterprise” about a “team” of 17 people
- vs. treating people as “resources”
- — banter –
- “Maverick” book
TOPIC: Teach “ask the team” by actually asking the team (in the class).
- teaching by example! Using the adults in the class to help answer the question
EDITOR’S NOTE: okay. this is very interesting, but I’m having so much trouble hearing that I’m going to bail on this one. Instead, I believe that Mike Vizdos at implementingscrum.com is also blogging this session. I’m sure his notes will be up soon
AGILE Project Management with Scrum -A book by Ken Schwaber
Prior to the Certified ScrumMaster seminar I attended in August 2008, I read the book by Ken Schwaber called Agile Project Management with Scrum based on a recommendation from Mishkin Berteig. After attending the seminar and becoming certified as a ScrumMaster I re-read the book. The second reading was much more valuable than the first for I had a much better understanding of Scrum. Here are my comments on this book.
What have I learned?
1. The adoption of Scrum methodology is more about changing roles and behaviours than it is about embracing a new process.
It was obvious to me and to Ken that one of the greatest challenges facing those individuals when moving from a their current environment to a scrum environment was that they would need to change their behaviours. In the former environment the team member would be directed and inspected based on what their project manager told them to do. The PM is the boss and the team members are somewhat powerless. In Scrum the team members take responsibility for their commitments and communicate their accomplishments on a daily basis. The hardest change occurs when the project manager is asked to become a ScrumMaster. The project Manager is familiar with assigning tasks and personally inspecting results. In the scrum environment they are the servants of the team, removing obstacles and facilitating the process. As Ken states in this book some project managers have great difficulty transitioning into the ScrumMaster role. They are unwilling to give up the power and position as a project master. It is hard to move from the leader of the pack to become the sheep dog herding the sheep!
2. Scrum is unforgiving for if you do not apply the fundamental principles it is likely your efforts to adopt Scrum will fail.
As I reviewed the numerous case studies Ken chronicled is was apparent that when organizations, Team members, Product Owners and ScrumMasters followed the terms, conditions and guidelines of the Scrum methodology, they tended to deliver on their commitments. When they misunderstood, misused or deleted some portion of the methodology they tended not to accomplish their objectives. The methodology is well thought out and works in many situations when used appropriately.
3. Scrum enhances individual and team expertise.
I agree and totally support Ken’s opinion about the value of Scrum. I have no doubt the individual team member is empowered and has a greater sense of achievement. Obviously based on his case studies, Ken builds a strong case that Scrum allows the team to deliver quicker. The process is more change adaptive, responsive to customer needs, timely and economical than traditional methods. Greater energy and capacity is released in the team and individual team members.
I have been reading a book entitled “Agile Project Management with Scrum” by Ken Schwaber. It is an interesting read. The examples and stories that he shares of companies who have struggled with Scrum and those that have succeeded are fantastic. The way Schwaber breaks up the book and explains all the roles then gives example makes it a great learning tool. It is also really funny and clever.
One complaint I have with the book is that it is very technical, it seems that the reader is assumed to have many years of software development experience. It is interesting that the projects that Schwaber discusses that have the most trouble with Scrum are those that are “stuck” in their old ways of working. It’s almost as if the old saying of “A little knowledge is a dangerous thing” is true for Scrum implementations. “Scrum means doing things in small cycles – so I will do everything the same except in shorter cycles.” Anybody ever heard of that type of reasoning?
I definitely recommend this book for those who have considerable experience in the technology field. For those who don’t this book might be challenging at times, espcially with the computer language words that are used.
I want to continually learn for my own personal and professional growth. So IÂ would like to know which books do you suggest? Are there any books that share examples and stories that are not focused on software development? If you disagree which my review of the book please comment.
I’m working with a number of companies using agile methods that have between 10 and 20 teams all working on the same product/project/program. They didn’t start small. These aren’t cases of organically growing from one good agile team to many good agile teams. Rather, these are organizations that have grown up in a non-agile approach and now want to reap the benefits of agile with their many teams. What is interesting is that these organizations all have some common problems and then all have some unique problems. There isn’t an obvious prescription for how they should be doing their agile implementations. I hope to write a few articles about scaling agile and scrum, and this one is our starting point: what reading should you do if you find yourself in the situation of trying to build a large agile organization.
Here are my rough notes from the May 2005 Scrum Gathering in Boston. Regrettably I was not in the room for most of Mike Cohn’s presentation on User Stories… but his book (User Stories Applied : For Agile Software Development) is excellent
The notes in this entry include predictions from Ken Schwaber, a presentation from Bob Schatz formerly of Primavera on their enterprise-wide implementation of Scrum, a panel discussion with Tim Bacon, Jeff McKenna, and Diana Larsen, moderated by Esther Derby. In the afternoon we heard from Pete Deemer about Yahoo!’s enterprise adoption of Scrum, Mike Cohn about User Stories, and to close the day we had an energetic presentation from Tim Dorsey of WildCard Systems about their enterprise implementation of Scrum.