SAFe SPC Training: A Reflection March 20, 2014 at 12:18PM Overview I recently attended the Scaled Program Consultant (SPC) training with Scaled Agile Academy in Washington, DC. The instructors for the class were Alex Yakyma and Rich Knaster. Several others in the Scrum community have provided commentary on their experience in SAFe training; namely Ron Jeffries and Peter Saddington. I have not reviewed these critiques as yet because I wanted to provide my own, unbiased perspective. I don’t intend for this write-up to be all-inclusive. Rather, I will share some key points, which stuck in my mind. SPC Class The first three days of training were primarily lecture with more than 500 slides. There were several breakout sessions also during those first three days. The training was 8 full hours each day. There were about 42 people in my class (7 tables of 6). My goal in attending this course was to remain as objective as possible and to fully listen to what was being presented rather than to argue every point where I experienced cognitive dissonance about the subject. I put many questions on the Parking Lot for later, took copious notes, and recorded the lectures so that I may refer back to what was actually said in class. On a few occasions, I did feel the need to interject because something was said that was so blatantly incorrect or inflammatory that many folks in the class turned to me to see what I would say. I had identified myself in the beginning of the class as a CSC and CST. I want to be clear that Alex and Rich are solid instructors and good guys in general who are genuinely trying to help people. I have a lot of respect for what they are doing. However, I see benefits and detriments in the course material, approach to instruction, and in SAFe overall that I want to share so that folks have various perspectives to consider. Throughout the training, there were many references to true agility presented; which was surprising to me. Many of the same sources were cited and statements made that CSTs (including myself) have been making in our CSM and CSPO training for many years. For instance, Donald Reinertsen is noted as being Dean Leffingwell’s inspiration and source for creating SAFe. There are also quotes and references to: Jeff Sutherland, James Coplien, W. Edwards Deming, Adam Weisbart, Rachel Davies, Taiichi Ohno, Takeuchi and Nonaka, and many others. In fact, there is little that is NOT included in the SPC training course in terms of mainstream Agile knowledge. It’s somewhat overwhelming and indiscriminately assembled in a way that leaves me thinking about my grandmother’s test for spaghetti done-ness: throw it against the wall and see if it sticks. Background This wasn’t my first official exposure to SAFe. From 2010 to 2011, I worked at NAVTEQ in Malvern, PA. We were implementing some of the earlier constructs of what is now called SAFe; such as Release Trains. Initially, the planning meetings and practices were effective in pulling together product teams across the organization into releases by synchronizing efforts around feature teams. Ironically, it was a message the other two coaches and I had been giving to management for over 6 months. Somehow, the sound of “release train” and “PSI” were catchy enough to make an impact and gain support. It probably helped that the message was delivered by Dean Leffingwell, who had written Agile books. As time went on, requirements such as having everyone attend the PSI planning meetings in person were relaxed and the meetings began to lose their effectiveness. My contract ended shortly before NAVTEQ announced the closure of the Malvern office. In maintaining contact with numerous folks from NAVTEQ, I have since heard that they are not only NOT doing SAFe any more but they are not even attempting to be Agile any longer. Observations For the most part, “Scrum” is recommended as the underlying delivery framework at the team level in SAFe. I say “Scrum” because there are some significant modifications SAFe makes to mainstream Scrum, which are cause for alarm. That is, most practitioners of true, well-formed Scrum would consider these changes harmful to Scrum and contra to its successful usage. In the Leading Safe Handbook is a quote by Jeff Sutherland: “Many agile programs struggle or fail. One major cause of this is simply bad Scrum.” This seems ironic to me because here the founder of Scrum is saying that Scrum implemented incorrectly is the reason for program failure and then the SAFe Training Course proceeds to define how to use Scrum incorrectly. In fact, each time Scrum was mentioned by the instructors, it was couched as being inadequate by itself and dysfunctional examples were provided such as “Waterscrumming” or having Development Teams in Scrum which were actually not cross-functional but rather, functional silos. These examples of Scrum were used to underscore the need for something more; i.e. SAFe. I would have liked to have seen Scrum promoted correctly and in accordance with what Schwaber and Sutherland (and all of the CSCs and CSTs of the Scrum Alliance) promote instead of saying in essence: ”There are problems with every organization that attempts to use Scrum, so we need to accept this dysfunction and build a process that accommodates organization impediments instead of looking for how to remove them.” The following are some things about SAFe that attracted my attention during my training. SAFe can be tailored however an organization wants and needs in order to make it work As long as I am able to work with a client implementing “SAFe” and we are allowed to tailor it to include the helpful parts and throw out the harmful parts, I don’t see anything really evil or wrong with SAFe here. What we are left with is doing precisely what I have already been doing for the last 8 years: looking for how to instill the values and principles Agile and Lean in the culture of an organization so that a paradigm shift toward continuous innovation and customer delight happens. The net result is that they understand why they are following the practices they choose to follow and not just blindly implementing methodologies. There are several groups today who are working toward addressing complex adaptive systems by adding additional layers of complexity. From my perspective, as someone who coaches large enterprise organizations, call it SAFe or DAD or LeSS or whatever makes people feel more comfortable and helps invite their voluntary participation and contribution to real change. If SAFe helps us get conversations going in an organization where there was no discussion before, then how can that be bad? The important thing to keep in mind is to keep an open mind. Once minds begin to shut and fixate on a “simple” solution it usually signals that we have reached the point of stagnation. When there is no interest in REAL change, growth, learning, etc. then it is usually time for me to move on to an organization that practices the “art of the possible”. SAFe can not help with the organizational and cultural changes necessary to support itself. It is only intended to be useful at the Program level. This point was made numerous times. It’s the same rationale that is used to fault Scrum; i.e. that it is not an all-inclusive solution and answer for everything. Here again, as someone who might be interested in implementing and helping clients with SAFe, I am not really able to unless I have the experience, knowledge, and skills that I would need in coaching any organization using any Agile practices. Again, we are back to me doing what I have been doing with Scrum all along by helping my clients figure out what their culture really represents and any changes that need to occur to support the practices they are trying to adopt; including, choosing the right practices to suit their culture and agenda to begin with. It Depends… Initially, the instructors mentioned this classic consulting answer as a joke. However, whenever there was a really tough or specific question asked about how SAFe addresses [this] in practice, the answer was always “It depends…” By the end of the first or second hour, the joke wasn’t really funny anymore; people were genuinely expecting answers, which, just weren’t there. And so it would seem that the same flexibility is built into SAFe as there is in Scrum with respect to inspecting and adapting and responding to change. This is interesting because the SAFe diagram and definition include many prescriptions. For instance calculating Weight Shortest Job First, using “Normalized” Story Points, mandating organizational cadence at the Sprint level (4/1) instead of at the release level, requiring that architecture and feature backlogs be treated independently and separately, just to name a few. If the ultimate answer is “It depends…” then I don’t see that SAFe is adding any value beyond what is already in the toolkit of most experienced Agile coaches. There is a definite marketing bent toward the middle tier of management since Scrum does not provide a prescription for or limit on what middle management can or should do during an Agile transformation. In fact, this targeting of middle tier management was made clear on the first day. There are references made to centralizing some decisions and decentralizing others; i.e. making strategic decisions in business and management and more tactical, delivery decisions at the team level… just like in Scrum. It’s the classic “what” vs “how” distinction. ScrumMaster is not a full-time role Here is a key point in SAFe which clearly promotes dysfunctional Scrum. The ScrumMaster role is trivialized and treated as an optional role. I heard from the instructors that anyone on the team can step in when needed to be the ScrumMaster and that each team does not require a ScrumMaster but they MUST have a Product Owner; which prompted me to ask “How does the ScrumMaster decide which way they will disappoint the team: by not finishing the work they have committed to during the Sprint or by not removing an impediment for other team members? Either way, they are letting the team down.” The answer was, of course, “It depends…” The reasoning and comments clearly shows a wholesale lack of understanding of the role. I asked what their thoughts were on Michael James’ “ScrumMaster Checklist” and it was clear that they had no idea what I was talking about. The comment back was that it can be helpful as a checklist but that there should still be flexibility in what the ScrumMaster does; i.e. in terms of work on the Development Team. In reality, the checklists provides support for the idea that ScrumMaster IS most definitely a full time role because it suggests all of the various activities that a ScrumMaster should be doing in order to adequately serve the needs of a typical team. There was no mention of the ScrumMaster as a coach to the team or as a servant leader or “chief impediment remover” to the team. I would have been slightly happier if they had said that in SAFe, the ScrumMaster is responsible for helping people to understand SAFe and to help coach them through their understanding of release trains, etc. But alas, there was no talk of helping Product Owners to understand how to break down PBIs or how to accomplish the organizational level changes that SAFe recognizes as necessary in order for an organization to develop its own Agile abilities. No Emphasis on a PSI at the Sprint Level Another missed opportunity in SAFe when compared to Scrum is that Scrum focuses more on value delivery and technical discipline by emphasizing a potentially shippable increment (PSI) EVERY Sprint. Across complex systems and architectures, this requires careful and deliberate collaboration amongst teams. It also forces an organization to re-examine how it has been producing software to date. As Einstein mentions, “We cannot solve our problems with the same thinking we used when we created them.” So why are we expecting that we can pursue change, vis a vis Agile adoption, and not attempt new ways of architecting systems? End to end slivers of functionality that deliver customer value every Sprint are possible. It requires a shift in thinking and ability to see what is possible. These usable slivers of functionality are represented by Product Backlog Items with testable Acceptance Criteria. In SAFe, there is no requirement that a team produce anything that is intrinsically valuable to the customer until they reach the PSI boundary along with other teams. This thinking, then, promotes waterfall within the context of Scrum. Teams are no longer required to completely integrate and test during their Sprints. They can wait until the HIP Sprints for that; discovering only after 5 weeks that there are critical, system wide defects… By delaying value delivery, there are missed opportunities for customer input and feedback with the net result being more inventory, not less. As the principles of Lean indicate, inventory is waste because it is unrealized value. Thus, reducing inventory and producing smaller batches is preferable; such as producing a PSI every Sprint. HIP Sprints HIP stands for Hardening Innovation and Planning. In SAFe, apparently, one Sprint every four Sprints is reserved for “catching up” on integration, design, and other tasks which were not completed during the previous four Sprints. This assessment is based on comments by the instructors and the Leading Safe handbook. In another part of the training, the analogy of Google 80% time was used. That is, the team is given an entire Sprint to do whatever they want. However in yet another part of the training, it explicitly states that HIP Sprints are NOT intended for catching up on testing, integration, and planning. So, it is not really clear why HIP Sprints are necessary. In the case of providing Google 20% time, I would support letting the team pursue this goal. However, allowing the team to decide how to implement it by promoting self-organization will yield better results than saying “Ok, GO! Now is your time to be creative. Hurry up, you only have one Sprint…” Leaving integration and testing until the fifth Sprint introduces four Sprints worth of risk in terms of defects and code refactoring work that needs to be done. If we aim for integration as an ongoing part of development each Sprint with much smaller vertical slices, then the defects we discover can be addressed at a lower cost (for 2 weeks) with less refactoring effort than if we discover these after 10 weeks (during the HIP Sprint). Architecture Epics vs Feature Epics As part of emphasizing delivery of customer value each Sprint, we often refer to Bill Wake’s INVEST acronym to remind us of the characteristics of good Product Backlog Items. The first characteristic is “Independent”. It is difficult to see how a feature can stand on its own if it can not be built until the underlying architecture to support it is in place. The idea of emergent design is to develop the architecture WITH the features that provide customer value. Thus, each customer-facing feature must include in its delivery and construction the very elements which support it. Creating an architecture which is separate from the features introduces disparity and fundamentally, additional inventory which delivers zero customer value. The evolution of emergent design and value delivery is continuous delivery wherein pieces of end to end functionality are fully realized and delivered as they are completed and not held for release. Several enterprise wide systems are employing this model with a high degree of success today. Features are coded, tested, integrated, tested, accepted, and deployed all throughout the product lifecycle. Conway’s Law postulates that an organization will produce software that mirrors its organizational structure. This further emphasizes the need to have integrated teams who work simultaneously on architecture and functionality with each product backlog item. Having systems architects who make decisions about the entire system separate from the delivery teams who implement these elements and other teams yet who construct the features perpetuates brittle architecture with many dependencies and barriers to value delivery. General bias against Scrum and the Scrum Alliance A statement was made that if an organization hires 10 trainers from the Scrum Alliance, they will get 10 different versions of Scrum; which don’t use any consistent terminology. This is 100% false. Every CST is required by their license agreement with the Scrum Alliance (and the Code of Ethics) to train Scrum in accordance with the Content Outline and Learning Objectives; which map to the Core Scrum Definition on the Agile Atlas website. (ift.tt/1lT7n5V) This is for both the CSM and CSPO class. An organization who hires 10 different CSTs WILL get the individual experiences, stories, and wisdom of 10 different trainers as a supplement to Core Scrum. That is, my stories, which support the need for self-organizing teams, will be different than another CST’s stories that support this concept. This dynamic provides more rich background and experiences for an organization as a whole to draw from. Students may also experience 10 slightly different training techniques; although, for a common client, it is not unusual for an agreement to be made that common materials are used amongst all Scrum trainers for that particular organization. The trend in the CST community has been to employ constructivist didactics instead of dialectic learning models. That is, we teach Scrum by modeling the class after Scrum and use various different elements of our courses which address different learning modalities; auditory, visual, tactile, sensorimotor, etc. These are commonly referred to as “Training From The Back Of The Room” (TFTBOTR) techniques after Sharon Bowman’s book of the same title. I didn’t get the sense that either instructor has ever experienced Scrum as it was intended to work; which explains why there was bias against it. Perhaps if they had been involved with some successful implementations at the enterprise level, they might have different experiences to draw from. I also see that the PO certification that Scaled Agile Academy (SAA) is currently working on has the potential to become a directly competing certification with the CSPO from the Scrum Alliance (SA). If SAA created a ScrumMaster certification, then there would certainly be direct competition with SA. Perhaps this is part of why they have decided to de-emphasize the role with a later plan to launch this spring boarding off the success of other SAFe certifications. Conclusion Attending the SAFe SPC course has provided me with deeper insight into the framework and a better understanding of the intentions of those who are promoting it. I came away with the realization that many elements of SAFe include what we often do in Scrum with large scale Agile adoption. In Scrum, however, we are less prescriptive and do not begin with a final picture in mind of what the organization should look like. Rather, we seek to understand what the organization is attempting to accomplish and build upon that vision as we empirically gather information and iteratively inspect and adapt upon it. In Scrum, we use techniques such as mapping value streams as part of developing a Product Roadmap and elaborating Epics into Product Backlog Items and using a portfolio level Product Backlogs that feed program level Product Backlogs which in turn feed team level Product Backlogs. However, we keep the emphasis on self-managing teams so that those closest to the work are making the decisions: Your firms are built on the Taylor model. Even worse so are your heads. With your bosses doing the thinking while workers wield the screwdrivers, you’re convinced deep down that is the right way to run a business. For the essence of management is getting the ideas out of the heads of the bosses and into the heads of labour. We are beyond your mindset. Business, we know, is now so complex and difficult, the survival of firms so hazardous in an environment increasingly unpredictable, competitive and fraught with danger, that their continued existence depends on the day-to-day mobilisation of every ounce of intelligence.” -Konosuke Matsushita In Scrum, we emphasize more frequent and regular development of value earlier on so that ROI is realized from the very first Sprint. Using the organizational cadence defined by release trains is merely one way to achieve integration between teams across a complex system. There are other models that must be considered in order to provide options suitable for various organizations; one methodology does not fit all. In so far as SAFe is a mutable framework that can be tailored to an organization and adapted as needed, I don’t see issues with conversations starting with SAFe. It’s not where I would begin the conversation myself. However, when my clients ask me my thoughts or would like to share their thoughts as they consider pursuing SAFe, I am now more inclined to reason through the different elements of SAFe with them, highlighting the pros and cons and making them aware of other options as well. As a newly confirmed SPC, I have the ability to train SAFe Agilist (SA) and SAFe Practitioner (SP) courses. As with any certification and set of practices, if I am training a SAFe course, I will remain true to training what the SAFe learning objectives define. However, as with any training that I do, I will also encourage my students to think for themselves and make the process serve their organization, not the organization serve the process. No tool or process should ever replace thinking and communicating.
Posted on: Thu, 20 Mar 2014 18:07:17 +0000
Trending Topics
Recently Viewed Topics
© 2015