Travis Birch and I are going next week to the SAFe Program Consultant (SPC) training with Dean Leffingwell. For Berteig Consulting, this will be an opportunity to expand our knowledge and to, perhaps, offer some new services including training and consulting. Of course, there have been many articles written about SAFe from a Scrum perspective, but I’m hoping to write an article about it from an enterprise Agility perspective. I have been involved as a coach and consultant in a number of such transformations, and I’m interested to see what I can learn from SAFe and perhaps how it can help to improve our Real Agility Program. I currently consider SAFe to be a “pragmatic” approach to enterprise Agility vs. a “transformative” approach. This perspective is based on some light reading and 3rd party reports about SAFe… clearly not a good enough base of knowledge! I’m looking forward to bridging that gap!
My heartfelt congratulations on this important and historic event! Scrum is one, again!
From the official announcement issued by Scrum Alliance:
SCRUM ORGANIZATIONS ANNOUNCE OFFICIAL
COLLABORATIVE ADOPTION OF SCRUM GUIDE
Scrum Alliance, Scrum.org, and Scrum Inc. announce the release and joint endorsement of a new community website, ScrumGuides.org. The new website is the official source of “The Scrum Guide, The Definitive Guide to Scrum: The Rules of the Game.”
Dr. Jeff Sutherland and Ken Schwaber created Scrum and authored “The Scrum Guide” to ensure Scrum remains true to its core principles and values.
“The Scrum Guide is the canonical definition of Scrum. Ken and I have worked closely together for decades to keep it simple, clear, and, in the true spirit of Scrum, to include only what is absolutely necessary,” says Sutherland, CEO of Scrum Inc. “Scrum is a powerful tool to radically increase productivity. Every implementation of Scrum is different, as teams and organizations apply it within their context, but the fundamental framework always remains the same. For Scrum Alliance, Scrum.org, and Scrum Inc. to come together to recognize the central place the Scrum Guide holds will provide clarity to the hundreds of thousands of Scrum practitioners across the planet.”
The explosive growth of people and organizations using Scrum in recent years has led to some market confusion as to the precise definition of Scrum. The preeminent certifying bodies, Scrum Alliance and Scrum.org, coming together in support of a common definition of Scrum is a win for Scrum practitioners around the world.
“The pieces of Scrum are carefully fit to each other to yield the best possible results. This has taken years for Jeff and myself to achieve. Watch for new versions as we continue to refine,” said Ken Schwaber, founder of Scrum.org.
“It’s time for convergence in the Scrum community,” said Scrum.org’s operations chief David Starr. “Giving this clear explanation of Scrum clarifies the framework for the entire industry. We are pleased to support a shared and unambiguous source of truth defined by Scrum’s creators.”
Carol McEwan, Scrum Alliance Managing Director, said, “This makes the most sense for the Scrum community. The Scrum Guide is based on the principles on which Scrum was founded. It offers Scrum practitioners worldwide a common standard and understanding of the foundations of Scrum. This collaboration adds real value and can only benefit everyone practicing, or considering practicing, Scrum.”
Over the many years that I have been teaching Scrum (since 2005!), I have had a Scrum diagram as part of my slides and/or handouts. The diagram has gone through several major and minor changes throughout that time. Here is the progression from oldest to newest:
This diagram was used in some of my earliest slides when I first started delivering Scrum training. It is bad. It is woefully incomplete. But, here it is:
I knew the first one was bad so after not too long, I created this next diagram as a supplement that was meant to show the whole Scrum process all in one page. Similar to other Scrum “cheat sheet” style diagrams. I used this diagram until about 2008 when I got some very good feedback from a great trainer, Jim Heidema.
The changes I made were small, but to me, significant. Changing from a “mathematical” language of “Sprint N”, “Sprint N+1” to a more general language of “Current”, “Future” was a big deal. I really struggled with that. Probably because I was still relatively new to being non-technical.
This fourth diagram made some minor formatting changes, but most importantly added “Backlog Grooming”. It’s funny how long I talked about grooming in my classes before realizing that it was missing from the diagram. I used the previous diagram and this diagram for a couple years each before making a rather major change to create the next one.
A couple years ago I realized that I wasn’t really talking about the Scrum values in my classes. I started to introduce them in some of my other handouts and discussions, but it still took a while for me to reflect those values in my diagram. I had also received a lot of feedback that having two Product Backlogs in the diagram was confusing. Finally, I realized that I was missing an opportunity to use colour more systematically. So, a major reformatting, systematic colour coding and the addition of the Scrum values was my next change.
Branded Diagram (ug.)
In a rush, I added some logos to the diagram. Just made it gross, but it’s badness, combined with feedback about said badness, actually inspired a major change for the next version.
Seventh Diagram (Sep. 2014)
I was showing my brand-new branded diagram to a bunch of people who really care about design and UX. The very first comment when I handed out the diagram was: “wow, you can really tell this wasn’t done by a designer!” Well, that got me thinking deeply about the diagram (again). So, here is my newest, latest and greatest (still not done by a designer) version of my Scrum diagram!
Eighth Diagram (2016-ish)
This new diagram represents many small changes including a much stronger focus on Scrum “by-the-book”. The most important and significant change is the addition of a bit of information about the definition of done. It also includes some other very minor layout and content changes, and updated branding (again) with the new BERTEIG logo. This one has been in use since some time in 2016, but I don’t remember the exact date.
Ninth Diagram (June 2019)
A re-branding of the diagram with color and iconography meant to be consistent with our other diagrams. The work on converting from the previous diagram to this one was done by my son, Justice Berteig.
Tenth Diagram (Sep 2019)
There were quite a few things that were missing from the previous diagram and a small number of things lingering that still were not compliant with the definition of Scrum from the Scrum Guide. I think this one has all the needed changes. Big additions include the “Development Team”, “Transparency, Inspection and Adaptation”, “Product Vision” and “Marketplace”.
I would absolutely love constructive feedback about this latest diagram. Of course, if you like it, please let me know that too! The thing I like about this is that it is a way of looking back at almost 9 years of my teaching history. Continuous improvement is so important, so I welcome your comments! If you have your own diagrams, please link to them in the comments – I would love to see those too! In fact, it would be really cool if a bunch of people could make little “Evolution of a Scrum Diagram” posts – let me know if you do!!!
PS. Here is a Scrum diagram created by my colleague Travis Birch.
Well, last spring I announced that I was going to be publishing a collection of the best Agile Advice articles in a book. I managed to get an ISBN number, got a great cover page design, and so it is almost done. I’m still trying to figure out how to build an index… any suggestions would be welcome!!! But… I’m hoping to get it published on iBooks and Amazon in the next month or two. Let me know if you have any feedback on “must-have” Agile Advice articles – there’s still time to add / edit the contents.
There are six major sections to the book:
- Basics and Foundations
- Applications and Variations
- Agile and Other Systems
- For Managers and Executives
- Bonus Chapters
- Agile Methods Quick Reference and Selection Guide
The book will also have a small collection of 3 in-depth articles that have never been published here on Agile Advice (and never will be). The three special articles are:
- Agile Mining at a Large Canadian Oil Sands Company
- Crossing the Knowing-Doing Gap
- Becoming a Professional Software Developer
Again, any feedback on tools or techniques for creating a quick index section on a book would be great. I’m using LibreOffice for my word processor on a Mac. I’m cool with command-line tools if there’s something good!
Organizations like to have clear role definitions, clear processes outlined and clear documentation templates. It’s just in the nature of bureaucracy to want to know every detail, to capture every dotted “i” and crossed “t”, and to use all that information to control, monitor, predict and protect. ScrumMasters should be anti-bureaucracy. Not anti-process, not anti-documentation, but constantly on the lookout for process and documentation creep.
To help aspiring ScrumMasters, particularly those who come from a formal Project Management background, I have here a short list of exactly which artifacts the ScrumMaster is responsible for.
– None – the ScrumMaster is a facilitator and change agent and is not directly responsible for any of the Scrum artifacts (e.g. Product Backlog) or traditional artifacts (e.g. Gantt Chart).
– Obstacles or impediments “backlog” – a list of all the problems, obstacles, impediments and challenges that the Scrum Team is facing. These obstacles can be identified by Team Members at any time, but particularly during the Daily Scrum or the Retrospective.
– Definition of “Done” gap report, every Sprint – a comparison of how “done” the Team’s work is during Sprint Review vs. the corporate standards required to actually ship an increment of the Team’s work (e.g. unit testing done every Sprint, but not system testing).
– Sharable retrospective outcomes report, every Sprint – an optional report from the Scrum Team to outside stakeholders including other Scrum Teams. Current best practice is that the retrospective is a private meeting for the members of the Scrum Team and that in order to create a safe environment, the Scrum Team only shares items from the retrospective if they are unanimously agreed. Outsiders are not welcome to the retrospective.
– Sprint burndown chart every Sprint – a chart that tracks the amount of work remaining at the end of every day of the Sprint, usually measured in number of tasks. This chart simply helps a team to see if their progress so far during a Sprint is reasonable for them to complete their work.
– State of Scrum report, every Sprint – possibly using a checklist or tool such as the “Scrum Team Assessment” (shameless plug alert!).
NOT RECOMMENDED (BUT SOMETIMES NEEDED):
– minutes of Scrum meetings
– process compliance audit reports
– project administrative documents (e.g. status reports, time sheets)
– project charter (often recommended for the Product Owner, however)
– project plans (this is done by the Product Owner and the Scrum Team with the Product Backlog)
– any sort of up-front technical or design documents
The ScrumMaster is not a project manager, not a technical lead, not a functional manager, and not even a team coach. There are aspects of all of those roles in the ScrumMaster role, but it is best to think of the role as completely new and focused on two things:
– improving how the team uses Scrum
– helping the team to remove obstacles and impediments to getting their work done.
I’ve proposed a session called “Agile Manifesto and Enterprise – Rant and Rave” for the Toronto Agile Community’s conference “Toronto Agile and Software“. The session is based loosely on my earlier article “The Agile Framework: Agile Values and Principles, The Agile Toolkit, The Agile Organization“, as well as some of the things that I do in the 2nd day of my Certified Scrum Master training session. If you are thinking of coming to the conference, I would greatly appreciate your votes or feedback on my session proposal!
Great metaphor! Scaling Agile – a perfect method.
So you’re trying to do Scrum well because you heard it gave you great results. You know that the ScrumMaster role is critical. How do you find the right people to fill that role? Here is a list of several roles that people commonly leave to become ScrumMasters, and a few not-so-common roles as well, all ranked by how well those people typically do once they become ScrumMasters. From Worst to Best:
- Worst: PMI-trained Project Managers (PMPs). Too focused on control and cost and schedule. Not easily able to give teams the space to self-organize. Not able to detach themselves from results and focus on the process, values and teamwork needed to make Scrum successful.
- Bad, but not awful: Functional Managers. The power dynamic can be a serious hindrance to allowing teams to self-organize. But, good functional managers already are good at building teams, and empowering individuals to solve problems.
- Bad, but not awful: Technical Leads. Here, the biggest problem is the desire to solve all the team’s technical problems instead of letting them do it. Now, instead of detachment from results (project managers), it’s detachment from solutions.
- So-so: Quality Assurance people. Good at rooting out root-cause for problems… just need to shift from technical mindset or business mindset to cultural and process mindset. Another problem is that QA is not nearly as respected as it should be and QA people typically don’t have a lot of organizational influence.
- So-so: Junior techies: Enthusiasm can make up for a lot of gaps and naiveté can help solve problems in creative ways, but there will be a huge uphill battle in terms of respect and influence in an organization.
- Good: non-PMI-trained Project Managers: rely on teamwork and influence rather than tools, processes and control (of course there are exceptions).
- Awesome: Executive Assistants. Respected and respectful, use influence for everything, know everyone, know all the processes, know all the ways to “just get it done”. Of course, they don’t usually know much about technology, but that often turns out to be good: they don’t make assumptions, and are humble about helping the technical team!
The ScrumMaster creates high performance teams using the Scrum process and values. The ScrumMaster is not accountable for business results, nor project success, nor technical solutions, nor even audit process compliance. The ScrumMaster is responsible for removing obstacles to a team’s performance of their work. The ScrumMaster is an organizational change agent.
Other things you might want to consider when looking for a ScrumMaster:
- Does the person have experience managing volunteer groups?
- Does the person have good people skills in general?
- Does the person want to create high-performance teams?
- Can the person learn anything – business, process, technical, people, etc.?
Bottom line: try and avoid having PMI-trained project managers become ScrumMasters. Even with good training, even with time to adjust, I often find that Scrum teams with PMI-trained project managers are always struggling and almost never become true teams.
Message from Mishkin
Product Owner Training – New AgendA
Upcoming Learning Events
Other Information and Links
Please feel free to subscribe to the Real Agility Newsletter to gain access to archives and receive future issues.