I just spent 4 days attending an SPC class with Dean Leffingwell & Alex Yakyma (funny but useful :)) in Boulder and wanted to share my reflections when they are still fresh in my mind.
It was a large class – 7 tables with about 5-6 people at each table, so it was a bit cramped. But we were all spoiled rotten by the amazing, kind, friendly, helpful and super nice people at SAI. The food was amazing and dessert was even better. If there is one piece of advice I can share with others who might attend this course at this location – LEAVE ROOM FOR DESSERT!
I was first exposed to SAFE at an Agile 2012 presentation that I think Drew Jemilo made. I had a very strong reaction when I saw the big picture and I still do. However, attending the course helped me understand Dean’s perspective and while I may not agree with every element of the approach, I have a new found respect, admiration and affection for him and his entire team, and what they have helped large organizations accomplish throughout the world.
INNER STANCE
Throughout the course, I tried to have an inner stance of curiosity, humility, openness and respect for SAFE. Large companies have done some awesome stuff using SAFE that they might not have been able to do otherwise. For instance, in our class, we had members of the Orion Space Program who had successfully conducted big-room PI (Program Increment) Planning with 400 people. Is that cool or what?
HUMBLED AND INSPIRED
I was humbled, touched and inspired to be part of class full of people who had a shared objective of rescuing value from the Bermuda Triangle of command and control management and phase-gate-waterfall thinking.
The class also helped refresh, reconnect and revisit the mindset and core principles of our industry – the Manifesto and Principles, Scrum, XP, Lean, De-centralized decision-making, Kotter and Dan Pink. I also walked away with some new names, tools and reading suggestions.
CONTEXT
Before I share my reflections on the framework, let me share my experience with Agile and scaled software delivery, which no doubt influence my thoughts…
- I have a development / delivery background – starting out as a developer and then evolving into a Delivery Manager for a $125M network monitoring and analysis product with a geographically distributed team. I have worked on both sides of the ocean – off-shore as well as on-site
- I also have a Masters in Entrepreneurship, and have founded and run a small consulting firm which gives me a greater appreciation of the challenges of a Product Owner
- In my largest experience of Scaling Scrum, I was the Coach for a Program with 250+ Scrum Team Members in a geographically distributed, multi-vendor, Fortune 15 setting.
- I am also a Professional Scrum Trainer through Scrum.org and conduct PSF, PSM, PSPO trainings. Between these training and custom Agile Training for clients, I have trained hundreds on students on Agile Software Delivery
With that context, here are some reflections on SAFe…
1. FRAMEWORK DESIGN & DOCUMENTATION:
Based on my understanding, frame-works are descriptive in nature. They are guided by core principles, have a few rules and might offer guidance in other areas.
- RULES VS GUIDELINES
As I looked at SAFE, I had a clear idea about the under-lying guiding principles because they were called out explicitly. However, I struggled to distinguish between the rules and the guidelines.
My understanding is that primary reference was the Big Picture and the student work-book. However, the work book is fairly large and as I browsed through the slides, I could not distinguish between the rules and guidelines either.
- EVENTS & ARTIFACTS: MANDATORY VS RECOMMENDED
In a similar vein, I got a sense of what are the core mandatory events – PI Planning, etc. However, there were many other practices and activities like the Portfolio Epic & Architecture Kanban which seemed to be optional, and I could not tell what the framework stated in these areas. I had similar questions about mandatory vs optional artifacts.
- ROLES: ACCOUNTABILITIES & MANDATORY VS RECOMMENDED
Similarly, I intuitively got the accountabilities of the key roles and can adapt based on the context. However, I am not sure what the framework says about which roles are mandatory and which are optional.
Chances are that these questions are answered in the Big Picture and other documentation. However, I would have preferred a brief SAFE guide, kind of like the Scrum guide that crisply defines the principles, roles, events, artifacts and rules. But this is just a personal preference and I am sure others would might feel comfortable with the current documentation.
2. SPC COURSE DESIGN AND PRESENTATION:
The SPC course is fairly intense – 4 days of going through some very dense slides. I appreciate the point that slides double up as a reference guide but it does make the experience of a student challenging.
I really enjoyed the exercises and the real-world stories, but I wish there was a little bit more interaction and less presenting. In some modules, I felt like I was being read the bullets of the slide which was not very valuable. There were some pretty long sessions without exercises and it got a bit monotonous.
I now have a new appreciation for how my students probably feel in my classes 🙂
3. SPC TTT AUDIENCE:
There was a lot of diversity in the audience. Some people had little or no exposure to Agile outside SAFE. Many did not have a background in software delivery. Some were experienced trainers and coaches.
As someone who has attended other TTT courses, I feel 3 days would have been enough. 2 days to attend from the perspective of future students and 1 day to deconstruct the course, learning objectives and discuss the mechanics and stance of the trainer.
However, since there were some people who were relatively inexperienced with Agile Fundamentals and Software Delivery, I feel even 4 days might not have been enough to give them the expertise needed to be SPC’s.
4. SPC CERTIFICATION & MODEL:
The exam was challenging – 122 questions in 2 hours. I have no idea if I passed or failed – I will find out in a few days. My concern, as I answered the questions, arose from not understanding which elements of SAFE were immutable rules and which were suggestions.
Without this clarity, I could not walk in the shoes of the evaluator. Many scenario based questions could be answered in different ways based on the context – as consultants often joke – “It depends”. I could not tell if the exam designer was looking for an answer based on clear, unambiguous definition in the framework or if the situation fell in the category of “It depends”.
I was also concerned that without a more rigorous certification process for trainers, it is possible to unleash trainers into the world who may understand and preach the letter and mechanics of SAFe without understanding the underlying principles that Dean had in mind.
For instance, once certified, SPC’s can present courses like…
- SAFe Product Manager/Product Owner – Intended to potentially replace CSPO / PSPO training
- SAFE Scrum Master – Intended to potentially replace CSM / PSM training
- SAFE Scrum/XP
As a trainer of PSF, PSM and PSPO I know what kind of complex questions students ask in these courses and how much studying, thinking and learning is needed to provide answers that are consistent with the principles, rules and guidelines of Scrum.
I feel that someone could be an expert in SAFe without necessarily having the expertise to teach people how to be effective Scrum Masters, Product Owners and Scrum/XP Developers and vice versa. Perhaps, some additional vetting could be done before SPC’s are given the license to present these courses.
5. TOOLKIT VS FRAMEWORK:
My biggest concern with SAFe is related to the distinction between a toolkit and framework. I have no doubt that in the hands of experienced practitioners like Dean and Alex, SAFe can help large companies do magical things.
As a practitioner, I like SAFe as a toolkit from which I can pick the most relevant elements that fit the context of my organization at the time. However, when we codify the tool-kit into a formal frame-work, it is held to a much higher, rigorous standard.
Let me share an analogy…
API vs COMPILER
As a programmer, one analogy that comes to mind to illustrate the contrast between a tool-kit and framework is the difference between an API and a compiler.
- API: When I share an API with other programmers, I give them the freedom to choose the specific method that is relevant to their context. They may choose as many or as few of the methods as they like.
- COMPILER: When I share a compiler with a programmer and they start programming in it, they no longer have the option of choosing to follow certain rules of the compiler and ignoring others, based on the context. The code may not compile if the rules are broken.
Perhaps a framework is similar. Once the immutable rules of a framework are broken, the entire framew0rk is at risk of collapsing. Even if it does not collapse, it is possible that the framework may not deliver the desired results because its integrity has been compromised.
The challenge I faced was to read the SAFe documentation and distinguish between the rules and suggestions.
I am concerned that in the hands of people who might not be as experienced, well-read and grounded as Dean and Alex, SAFe could expose companies to a variation of the command and control, prescriptive structures that we as an industry have been struggling to escape.
Might less experienced SPC’s cling to the Big Picture and institute some variation of PMBOK rigor in our industry? Might less experienced executives and managers cling to the Big Picture and avoid the journey of Agile, Lean and Scrum thinking that is needed for true Business Agility?
6. SPEED OF ROLLOUT:
My final concern about SAFe is the speed of roll-out.
In my experience, each organization has a finite capacity to change. In some organizations, up-scaling Agile without first addressing the systemic issues that plagued Agile at the existing scale, might be risky.
As a practitioner, I prefer to start with a small Agile roll-out – maybe a few scrum teams and see where the organization starts breaking. I typically like to make a few tweaks, inspect and adapt before I scale to the next level. My preference is to address the key organizational impediments at each scale of Agile before I take the organization to the next scale.
If we move too fast, it is possible that there might be a destruction of value. Conversely, if we move too slow, it is possible to miss the window of opportunity because the competitor will make one irrelevant.
While I relish challenging an organization to step out of the comfort zone, I am also wary of subjecting an organization to a degree of change that they are not capable of handling.
I realize it is a judgment call and a preference. It just so happens that my preference is in the area of starting small and inspecting and adapting based on organizational indicators.
CONCLUSION
So in conclusion, I respect and admire the amazing results Dean, Alex and the team have helped large companies accomplish through SAFe. My recommendation is that other practitioners consider and manage some of the risks and concerns that I have outlined above to minimize the un-intentional collateral damage.
Would love to learn from your perspective. What do you think…?
Comments