Scrum was my first love in agile. I still remember the revolution and excitement I felt after the Scrum Master course and when I and my colleague Öystein started our first Scrum team. It was awesome!
Later I moved on to more flow based approaches when I ended up in environments where Scrum was not a great fit with it s iterations and locked down scope.
Scrum and I was far away from a time. There are no hard feelings but we just don’t hang around much anymore.
I saw someone tweet something like;
I feel like many people talking about Scrum doesn’t really know what it’s about. Really.
Something like that. I felt that it was about me. So I decided to read the official Scrum guide and take some notes. They are summarized in this post.
Structure of this post
What I did was that I tweeted as I read the guide. Basically sharing my highlights of the text on twitter. I then tweeted some reflections after reading the whole thing.
In this post I will write the same things, maybe add some more context around it.
My highlights
Here’s the thing I found noteworthy in the guide - most of them are straight quotes. Many great things and learnings can be found here - for any agile team, regardless of your process.
General about Scrum
The Product Owner is one person, not a committee.
For the Product Owner to succeed, the entire organization must respect his or her decisions.
Development Teams are structured and empowered by the organization to organize and manage their own work
Self-organizing; no one tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality
Scrum recognizes no sub-teams in the Development Team
Scrum recognizes no titles for Development Team members other than Developer
About the events and meetings
All events are time-boxed events… Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.
During the Sprint: No changes are made that would endanger the Sprint Goal
The Daily Scrum is a 15-minute time-boxed event for the Development Team
http://bit.ly/2orJfOt Nothing about the informing the PO or other external stakeholders at the Daily Scrum
During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.
Sprint Retro is an opportunity for the Scrum Team to inspect itself & create a plan for improvements to be enacted during the next Sprint.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint
About the artefacts
Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation.
The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made
Product Backlog items have the attributes of a description, order, estimate and value.
As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list.
The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team
At any point in time, the total work remaining to reach the product goal can be summed.
About Sprints
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed.
At end of a Sprint, the new Increment must be “Done,” i.e. it must be in useable condition & meet the Scrum Team’s definition of “Done.”
Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts.
The purpose of each Sprint is to deliver Increments of potentially releasable functionality [… as of the] current definition of “Done.”
Development Teams deliver an Increment of product functionality every Sprint. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.
And finally about the guide itself
Scrum is free and offered in this Guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum
Reflections
I then tweeted a few reflections or general feeling I got after reading the guide. I will fill these out a little bit more here since I now got the space.
Scrum is pretty rigid! “The team does this”, “At the end of the Sprint X is complete” “The organization will support” etc. There’s not much room for changes in how it supposed to work. Very prescriptive level of description - which, at least for me, was exactly what I needed. Then.
Scrum, as described, requires discipline! I don’t think I ever saw a team doing “proper” Scrum. Which is important since that’s what Scrum is if you don’t do all of Scrum as described in the guide it is not Scrum. Now that in itself is only important if you are selling Scrum and need to guarantee that it works. The rest of us try to make something work.
The Scrum Master sounds, in the guide, like a pain in the xxx. “She teaches, enforces, educates…” etc. Not much servant-leadership-y as it most often has been described by others.
There’s a lot of effort put into the guide to ensure the team and PO are shielded from the outside. The decisions lie within PO / Team. This requires a big buy-in from the rest of the organisation and doesn’t fit any organisation bigger than 10 people where I ever been.
Scrum - as described - is (sounds) super effective. I get really inspired. But requires understanding and buy-in from org around the team.
Conclusion
I have no real problem with Scrum. It is really effective. However, in order to be that effective, there has to be some, in my experience, pretty massive adjustments from the rest of the organisation.
That doesn’t mean that Scrum can be used, in part, to still give you some (significant?) improvements. However it’s then not Scrum (TM) - and you don’t have to care about that.
Go ahead - make your own Scrum. Call it something else if needed. Here’s a recipe that I’ve seen work (well really … someone has made a method around this :)):
- Start where you are - that is, just show your current state and ways of working now.
- Visualize your workflow (as you probably have done if you’re doing Scrum)
- Limit your work in process so that you strive to do fewer things at the same time over more things at the same time.
- Help the work to flow faster. Focus on the work - not the workers. A good idea is to make smaller things or collaborate to move things faster
- Agree to improve in an experimental fashion, in small steps
If you end up with something that looks like Scrum or not… who cares?
The customer doesn’t care how we are organized!
Leif Östling, CEO Scania ca 30 years