Chapter 2. Real Organizations

In this chapter, we turn our sights to organization-level questions concerning culture, scaling, and other systems-related topics. All organizations have similar questions on how to work more effectively so that they can gain or maintain a competitive edge in the marketplace. The perspective provided may be a little shocking and revolutionary for some readers.

However, innovation seldom results from behaving, following the rules, and accepting things for what they are. In order to be more competitive in the marketplace with our goods and services, we need to adopt an entrepreneurial attitude by considering the “art of the possible” and what we CAN do.

Join me as we take a closer look ...

How can I grow my organization and still practice Scrum?

How can I leverage Scrum patterns and practices to develop large products, such as entire systems with many applications?

The first question that people SHOULD be asking is “Why do we need large teams in the first place?” Most often, organizations aren’t really sure why they need very large teams or their rationale is based upon broken thinking, which caused them to seek relief by inquiring about Agile.

Most folks don’t really take the time to learn and understand how to use Scrum successfully with small teams before they begin asking about how to scale or work across multiple teams ... in a distributed manner ... and other such complex topics. Isn’t it already difficult enough just working with a small team that is right in front of you?

I use the example of Luke Skywalker in The Empire Strikes Back when he is working with Yoda on Dagobah. Luke is impatient. He wants all the answers. He lacks the discipline to truly master the craft of being a Jedi. He isn’t content to finish his training before he runs off, ill prepared and with a mind full of assumptions. He happens to pull it off because he is the protagonist and George Lucas knew that this is what would sell.

Many of the organizations I have worked with have caught the Agile Fever and learned enough about Scrum to see that it is simple. However, instead of taking it at face value and contemplating how their organization and culture might need to change in order for Scrum to work effectively, they begin to look for ways of modifying Scrum by tearing it apart and making it suit their situation. This seldom works out well since they don’t have George Lucas there to save the day with creative license.

Scrum specifically prescribes that teams should be five to nine people (7 ± 2). This wasn’t an arbitrary range. The logic behind defining an effective development team to be this size follows the concept of Miller’s law: our brains are capable of keeping 7 ± 2 pieces of information in the forefront of our brain at any given moment for immediate recall. Thus, if I am working with this many people, I could theoretically recall what each is working on almost instantly.

Another justification for the lower end of the five to nine development team size involves the idea that a team of fewer than five will have a more challenging time establishing the cross-functionality necessary to ensure that all features are meeting the definition of done. Although, these days, the Scrum Guide mentions having development teams as small as three people. It would still be possible to build a product using Scrum with a team this small if the people on the team are themselves cross-functional. Still challenging, however.

On the plus side, there is usually more synergy and close collaboration with smaller teams when they are allowed to self-organize. Because everyone has a limited amount of capacity for face time and interactions, each person’s budget goes to fewer people, which results in closer ties.

With teams of nine people or more, the communication increases in complexity and decreases in frequency. As mentioned, the time that each person has available to share with others may not accommodate EVERYONE on a team that is larger. There might be a tendency to form cliques within the team, and this can sometimes drive a wedge between one “faction” and another.

On the other hand, teams that are on the larger side have an easier time with cross-functional skillsets and redundancy of skills; that is, if one developer or tester is out unexpectedly on a larger team, the entire team doesn’t suffer as much. There still may be capacity for development or testing by others on the team.

Arguably, not all applications or systems can be handled by a single team. If we consider a Web site for a banking institution, there can be MANY different features that banking customers might wish to have. It would be confusing if as a checking account user, I navigated over to manage my savings account and the interface looked and behaved completely different. Also, there will most certainly be components and pieces that could be leveraged by both checking and savings interfaces. So, if teams were dedicated to each of these areas, they would definitely need to be in close communication and collaboration with each other to figure out how to build things in such a way that both teams are leveraging each other’s products.

Furthermore, there must be a unifying vision of the end-state product at a high level that is shared by all teams working across the entire customer banking management system. With a shared vision and purpose and close collaboration among the teams, there will be a consistent look and feel, as well as consistent paradigms, so that the user doesn’t need much documentation to understand how the system behaves.

Some swarming might take place wherein several teams work together to focus their efforts on producing end-to-end functionality on one or two features within their respective areas of the application in a single iteration at a time.

Melvin Conway pointed out in 1968 at the National Symposium on Modular Programming that system design follows organizational structure. If an organization’s communication structures are highly stratified, bureaucratic, and formal, then its systems and applications will be similarly complex and hierarchical. Consequently, it makes sense to simplify the organization as much as possible in order to reduce the complexity of its products. This also touches on the concept of Occam’s razor.

Numerous comprehensive texts delve into the realm of scaling. I am listing five of my favorites for further reference and follow-up by the reader:

James Coplien—Organizational Patterns of Agile Adoption

Bas Vodde and Craig Larman—Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum

Dean Leffingwell—Scaling Software Agility: Best Practices for Large Enterprises

Mike Beedle—Enterprise Scrum: Agile Management for the 21st Century

Ken Schwaber—The Enterprise and Scrum

There is no simple answer or solution to the question of scaling. One thing is certain: adding complexity to an already complex situation is not likely to yield more effective or desirable results. If we can look for ways to simplify how people communicate and collaborate, then we have a better chance at achieving the results we are looking for.

For instance, I continually hear organizations complain that they aren’t able to relocate people or take the steps necessary to have teams collocated so that they can improve the efficiency (frequency and clarity) of communication by emphasizing face-to-face communication. But then the same folks are surprised when there are mistakes, misunderstandings, and waste that result from poor communications. Improvement is a desirable output that results from a change in input and/or process. We can’t expect improvements without doing things differently.

Any approach that prescribes practices across an entire organization is suspect, especially if its intention is to optimize performance at the component or team level. Rather, an organization should seek to optimize performance across the entire system, and the best way to do this is to observe the Theory of Constraints, which suggests that systems be built around the inevitable constraints that exist in the system.

Several others in the Scrum community have provided commentary on their experience in Scaled Agile Framework (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 that stuck in my mind.

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 could 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 Certified Enterprise Coach (CEC) and Certified Scrum Trainer (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, many references to true Agility were presented, which was surprising to me, since the SAFe process diagram leaves me with the feeling that this is one of the most heavyweight methodologies in a long time. 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 were also quotes and references to Jeff Sutherland, James Coplien, W. Edwards Deming, Adam Weisbart, Rachel Davies, Taiichi Ohno, Hirotaka Takeuchi and Ikujiro 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 doneness: throw it against the wall and see if it sticks.

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 “potentially shippable increment (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.

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, that is, SAFe.

I would have liked to have seen Scrum promoted correctly and in accordance with what Ken Schwaber and Jeff 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 of 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 that are working toward addressing complex adaptive systems by adding layers of complexity. From my perspective as someone who coaches large enterprise organizations, call it SAFe or Disciplined Agile Delivery (DAD) or Large Scale Scrum (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 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 Cannot 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, that is, 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 Weighted Shortest Job First, using “Normalized” Story Points, mandating organizational cadence at the Sprint level (4/1) instead of at the release level, and 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. References were made to centralizing some decisions and decentralizing others, that is, 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, which prompted me to ask, “How does a person who is expected to play both roles (Development Team and 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 show 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, that is, in terms of work on the Development Team. In reality, the checklist 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 Scrum Team/organization or as a servant leader or “chief impediment remover” to the Scrum 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 Product Backlog Items (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. To their credit, the instructors acknowledged the need for a full-time Product Owner. The ScrumMaster needs to be viewed as a full-time role as well in order for Scrum to work properly.

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 PSI in EVERY Sprint. Across complex systems and architectures, this requires careful and deliberate collaboration among 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 out of 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 percent 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 percent 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 Versus 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 cannot 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 that 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 yet other teams 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 that don’t use any consistent terminology. This is 100 percent false.

Every CST is required by his or her 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 Web site (http://www.agileatlas.org). This is for both the CSM and CSPO classes.

An organization that 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 a richer background and more 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 among 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 leveraging the success of other SAFe certifications.

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 to 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 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 return on investment (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. Other models must be considered in order to provide options suitable for various organizations; one methodology does not fit all.

Insofar 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.

Organizations are also complex adaptive systems, since they are made up of people. As complex as each person is, when we bring all of these people together, the complexity tends to have a multiplicative effect similar to resonant frequencies in physics; the more aligned the positives are, the more amplified they become. The more aligned the negatives, the deeper those negatives become.

I have coached various different organizations over the last 9 years, public and private, for profit and nonprofit, federal and state government, etc. These organizations have also spanned numerous industries from biotech to financial services, automobile manufacturers to online payment processors, and many others.

I have found that there are some similar patterns of behavior. However, there is not really one “biggest hurdle” that could be applied across all organizations. Each has its own unique culture and set of issues. Instead of just one biggest hurdle, I will share a few of the gotchas I have found and also some success factors.

However, I often find that although management is very gung ho about adopting Scrum, they have very little understanding of WHY they are adopting Scrum or what the implications and trade-offs are in doing so. They have a firm grasp of the POTENTIAL benefits of following Scrum practices, but they haven’t come to grips with the fact that success doesn’t come easily or for free.

Scrum doesn’t have all the answers. Scrum raises transparency in the organization so that the decision makers have better data to work with and can make better decisions. If your culture bashes people for bringing up issues or concerns, then Scrum isn’t going to work for you because the workers will continue to hide things or obscure them from management for fear of repercussions.

As a leader, I have always encouraged people to give me the facts, no matter how ugly. I am not a fan of arm-waving, Chicken Little–style complaining about EVERYTHING. However, if there are legitimate concerns that are backed by data or information, I welcome those concerns ... as well as suggestions for how to mitigate the risks. There’s a saying that goes: “Don’t just bring me problems. Bring me solutions.”

Ultimately, in order for Scrum adoption to work, there has to be buy-in and support from all levels, not just top-down. Leadership must come to accept that there are trade-offs to be made and that the benefits of increased customer value and quicker time to market are the product of decentralized decision making and increased trust in teams.

For this reason, it can be harmful to take a shotgun approach to adopting Scrum—that is, to roll out Scrum practices to ALL areas of the business at once. Perhaps there ARE some practices being followed currently that are helpful. Ripping those out and replacing them with Scrum without any sort of consideration is irresponsible.

In some cases, an organization may be SO broken that there is nothing left that can be salvaged. In those cases, it might make sense to completely start over from scratch and adopt Scrum across the entire organization all at once. It could be a fresh start, a reset.

In some organizations, there may already be awareness of what Scrum is and a corporate culture that is ready for Scrum, which would warrant a wholesale implementation.

There are pros and cons to taking the “shotgun approach.” On the positive side, it is a definitive, decisive maneuver with clear intent and perhaps a clear goal and end state in mind. On the negative side, if there isn’t sufficient education, awareness, and buy-in, the transition can be abrupt and painful. As with most things in life, there is no “one size fits all” approach.

Unfortunately, these people are living in the Land of Oz, not the real world. In the real world, REAL trade-offs must occur. It’s not possible to know exactly what the scope, cost, AND date will be.

As the saying goes: “You can have it good, fast, or cheap. Pick any two.” I maintain that it’s worse than that. You can have one thing that’s fixed (non-negotiable), one thing that is firm (optimized), and one thing that is flexible (no limit). I call this the Trade-off Matrix and have used it very effectively to demonstrate to executives that they make the big bucks because they have tough decisions to make around trade-offs.

The first scenario I call the “Wizard of Oz” (see Figure 2-1).

The reason why is because many times leadership asked me how they can have fixed scope, cost, AND time and I usually reply, “I can’t help you with that, but maybe the Wizard of Oz can, because that is DEFINITELY fantasyland, not reality.”

The second scenario represents a Minimum Viable Product (MVP) situation (see Figure 2-2).

In this case, we absolutely MUST release the identified scope. This is non-negotiable. That’s fine. We just CANNOT know precisely when it will be released or how much it will cost then.

Similarly, we can have the case where the date is fixed (see Figure 2-3).

In this scenario, we absolutely MUST release by a given date—that is non-negotiable. Once again, this is perfectly fine as long as everyone realizes that we CANNOT also know exactly what will be released or how much it will cost.

Thus, the trade-off matrix can be very useful and powerful for emphasizing the fact that trade-offs must be made; we can’t have everything, no matter how much we kick and scream.

However, this is not the only issue with the bottom liner. I often hear stakeholders say that they don’t want to see anything until the entire release or product is done. This is another place where I use the mortgage analogy:

Let’s assume we are buying a $500,000 house with a 30-year fixed mortgage at 3.35 percent APR. The total payments would be almost $800,000. Do you think that the mortgage company would be ok if you said, “Hey, don’t worry, we will write you a check 30 years from now for the full $800,000.” Hell, no. They want iterative, incremental delivery of value on their investment, confirmation that you are on the right track and aren’t going to default on the loan.

As a stakeholder, I can’t understand why you wouldn’t want to see regular, steady delivery of value all throughout the product development lifecycle. Or, how about confirmation every 1 to 4 weeks that the team is truly on track with delivery? Or, how about the option to change your mind as customers change their minds or technology changes?

These are the true benefits that using Scrum provides. It’s called “Agile” for a reason. Agile means:

1: marked by ready ability to move with quick, easy grace <an agile dancer>

2: having a quick, resourceful, and adaptable character <an agile mind>

Synonyms:

graceful, featly, feline, gracile, light, light-footed (also light-foot), lightsome, lissome (also lissom), lithe, lithesome, nimble, spry, acrobatic, flexible, limber, loose-jointed, pliable, pliant, supple; adroit, deft, dexterous (also dextrous), light-fingered; fleet-footed, sure-footed; athletic, balletic, coordinated

A big part of the benefits of Agile is to be able to change quickly and be adaptable. Recognizing this as a benefit and a strength is key.

Organized labor, for IT ...

Without getting into too much of a political snafu about collective bargaining agreements in light of the vast need for highly skilled developers out there, the general impression I have is that this is NOT a beneficial practice to the organization. I have met developers in these situations who were quite comfortable with where they were in the organization and not in much of a hurry to see anything be very successful. It’s nearly impossible to motivate, remediate, or terminate underperformers when necessary.

Someone once said to me:

“Look, I have 3 more years until I retire and get a full pension. So, I don’t give a f*** about your ‘Agile.’ As long as it doesn’t make my life difficult, then fine. Otherwise, don’t expect me to support it or be excited about change.”

I was just completely dismayed.

And, not because they used the word “f***.” I was in the Navy and was also a volunteer EMT/firefighter. I have heard (and seen) it all. It was just the sheer attitude of selfishness and complete disengagement/disinterest that blew my mind.

So, being wary of the fact that the people on the teams and in the trenches can easily torpedo any effort they don’t agree with is important. Gaining their buy-in and support is crucial. The thing to remember here is that everyone has the same question in their mind about any change initiative: “What’s in it for ME?”

As I mentioned, each person is different and thus, motivated a bit differently. Understanding what motivates each person and being able to relate to them on their level will help answer that question.

People don’t typically go through college thinking, “Gee, I can’t wait to graduate so that I be marginalized by going to work for a massive corporation, chained to a desk, in a 6 × 6 cubicle with no sunlight for the next 30 to 40 years ... or until I fall over dead.” No, they have higher dreams, goals, aspirations, ideas.

But then they are beaten down by systematic abuse by bad bosses and toxic environments to the point where it kills their passion for innovation and their drive for excellence. They become cynical. Agile gives people an opportunity to realize their vision by being a part of the decision making and having more control over their own work.

Being able to understand the passions of each person will help in answering the “What’s in it for me?” question and, ultimately, help gain trust and support.

And the pig replies, “Ok, what would we call it? What would we serve?”

“How about ‘Ham and Eggs’? That’s what we would serve, also.”

The pig thinks for a moment and says, “I don’t think I like this idea. You would just be involved but I would be COMMITTED.”

(cue the sad trombone sound)

I have never really liked that joke.

I am glad that the majority of the community has decided to deprecate it.

Apart from the obvious cultural snares that are inherent in the joke, it’s really irritating and uncomfortable to be working in an organization where people are running around calling each other “pig” or “chicken.”

When people haven’t heard the cute little joke, there is no context and they are like “WTF???”

Not really a good way to focus on individuals and interactions.

However, even deeper than all of this is a flashback I had to my high school years and George Orwell’s Animal Farm.

We have organizations being run by the farmers of the world in a traditional command-and-control approach. And it sucks for the animals. But at least they are producing SOMETHING.

Then, there is an uprising and an upheaval of the power balance by the pigs to something, which is initially more equitable for all of the animals on the farm. Things are great from their perspective ... for a while.

However, gradually, the pigs begin to install a system that is far more oppressive and tyrannical than anything they had under the farmer. The farmer at least had a strategic view of farm operations and bigger-picture thinking than the pigs, who simply wanted to ... well ... pig-out.

And, as the story goes, it didn’t end very well for the chickens in Animal Farm.

Similarly, over the years I have seen Agile transformation teams become like the pigs in Animal Farm, wielding Agile as a weapon to further their own agendas and establishing a rigid structure of process in the name of Scrum, which is contrary to the values of Scrum and the values and principles of the Agile Manifesto.

Based on my experience over the last 9 years, there are five key tools that we can use when approaching organizational transformation to ensure that we don’t fall into the trap of becoming zealots for process in the name of Agile:

Organizational Vision—Create understanding across the organization of what they are trying to be and why.

Transformation Backlog—Build a backlog of changes and refinements and ensure that it is ordered by highest value at any given moment.

Communities of Practice—Establish groups that will support learning and growth across the organization. Begin with people who are passionate about opportunities and innovation.

Regular, Organizational-Level Retrospectives—Conduct regular retrospectives for the transformation effort so that EVERYONE understands what is working well, what isn’t working well, and what experiments they would like to run.

Think Globally, Act Locally Mind-Set—Decentralize decision making by de-emphasizing uniformity and consistency across the entire organization. We don’t want battle droids or clones assembled into teams. We want autonomous, free-thinking knowledge workers who are motivated toward helping the organization be successful.

I am planning to elaborate further on these at the Scrum Gatherings in Shanghai and Prague, assuming my proposals are accepted, and also at other venues where I have been invited to speak.

But for now, I would like to ask the remaining few who are telling the pig and chicken joke to let it die a somewhat dignified death.

In the profound words of Morrissey:

“I wish I could laugh, but that joke isn’t funny anymore ...”

“WHY?” That is, “Why does your organization want to practice Scrum?” Is this a grassroots effort by Development Teams? One manager’s idea for his or her area of the organization? A top-down push by upper management handed down as an edict or mandate?

I often find that organizations have an unrealistic view of what Scrum will provide for them. They expect Scrum to solve all of their problems or will magically give them the miraculous benefits they keep hearing about without sacrificing ANYTHING. It reminds me of the late-night infomercials, which promise that you can eat anything you want, never work out, and you won’t gain a pound if you simply use their product. In fact, they often promise that you will actually LOSE weight!!

Scrum will not solve all of your organization’s problems. In fact, it is going to cause a lot of problems for your organization because Scrum has the effect of holding up a mirror to the organization so that it can see what it really looks like. This results in a lot of pain because people don’t like to see the harsh reality of how they behave and the issues they are faced with. Instead, they are content to live in blissful ignorance, or at least feigned ignorance.

Furthermore, your organization is probably struggling with organizational impediments and dysfunction that it simply isn’t aware of. Much of this goes unnoticed or is swept under the rug because the culture of the organization doesn’t truly support learning or growing—or even worse, the culture is not open to its people bringing up issues.

As Ken Schwaber has said: “If what you are doing in your organization is working well for you, then don’t try Scrum. Keep doing the things that are working well for you.” Better yet, if you aren’t willing to have the courage to stand up for what you believe is the right thing to do in the organization, then please, do yourself and the rest of your organization a favor and do NOT pursue Scrum.

Most organizations that seek to implement Agile aren’t really looking to improve. What they really want is to go faster or have quicker time to market with their products without sacrificing anything or while still producing all the same metrics, or by following a “tailored and practical approach to Agile.” These are all buzzwords for “We want to fail.”

I have yet to hear a client say to me, “All we really want to do at this point is LEARN about ourselves because we really aren’t sure who we are or where we are going, let alone how we get there.” Most of the time, the clients ask me how they can compromise between what Scrum requires and what their management or stakeholders are requiring or how they can become more accurate and predictable by measuring things with metrics.

For the culture question, then, after understanding what is motivating the push or drive to use Scrum, I would most likely recommend some kind of an assessment to really gauge where the understanding and support are across the organization. Although metrics can’t solve your problems, it’s also impossible to make decisions with absolutely zero data or information. Establishing a baseline will be crucial versus making assumptions.

Once the assessment has been completed, we would identify gaps in understanding, knowledge, support, skills, etc., that are acting as barriers to your organization’s successful Agile adoption. Perception is reality. What are the perceptions of those across the company? Do they know what is expected of them to make this work? What the benefits are for them?

We would look at how to gradually close these gaps and move toward self-sufficiency in the organization. As an Agile consultant, that is my primary concern: to help the organization grow and become independent so that WHEN I move on to the next organization (not “if”), your organization doesn’t revert back to its old ways and dysfunction.

First and foremost, it is important to invest in education. Training is the best way of level-setting in terms of expectations for what Scrum is, what it is NOT, what can be tweaked, and what is non-negotiable. Scrum does have some hard, fast rules—very few, but they are really not negotiable, or the benefits are lost.

This book is entitled Real World Agility because I continually heard comments from people like “This is MY reality ...” or “Yes, but in the ‘real world’ ...” Scrum IS the real world—more real than most people think or want to acknowledge. Scrum is empirical process control, which means that it focuses on making small plans, doing some work, checking how the work matched the plan, and then taking action on modifying the way we work and plan. This is the plan-do-check-act (PDCA) process as defined by W. Edwards Deming.

This follows very closely how we as human beings are wired mentally. We are inquisitive, explorative beings who innately look for new ways to do things. When we try something new, we learn from the experience. By nature, there is no concept of failure or success—there is only learning. What worked? What didn’t work? No emotion. No judgment. Just pure empirical evidence.

This is the place where we want our organizations to be: focused on learning and not worrying so much about success or performance.

Ultimately, to answer the culture question, it is important to recognize that YOU are the culture of the company. You and all of the other yous like you who are in the company. The biggest question on everyone’s mind is, “What’s in it for me???” Why should they care about this “Agile” thing? What will it do for THEM? To win people over, it’s absolutely crucial to be able to answer that question for each person in the organization.

The next most important thing is to be the change that you want to see in the organization. We don’t have control over what anyone else does, but we can ALWAYS have control over our own actions. Sometimes, that means taking a passive resistance approach where you purposely go against something that the company is forcing you to do because you know that it is something that is harmful for the company.

For instance, I have occasionally defied orders from superiors in organizations because I was being ordered to do something contrary to what I could clearly see was the right thing to do. People fear that they will be fired or that other dire consequences will happen if they don’t comply. Ninety percent of the time, the things we worry about don’t happen, and the other 10 percent is usually not as bad as we think it is.

One such instance was when I was told to create a Scrum training program for one of my very large federal government clients. They insisted that the program follow a very specific script, slides, etc. The content was an unrealistic amount to cover in the time allotted—essentially a 2-day course covered in 4 hours. I created the materials and training program that they had requested, but when it came time to delivering the training, I ignored the classroom materials and instead taught the people what I thought they NEEDED to learn. In the end, I received outstanding ratings from the attendees, and they continued to thank me afterward for preparing them well for the changes that were coming.

One of the most important things to keep in mind about not only Agile but life in general is that we are in control of our actions and our destiny, and we make the outcomes happen that we set our minds to accomplishing. It’s the concept of internal locus of control versus external locus of control.

Those who have an internal locus of control believe that they are in control of their lives and that if they are not happy, they can make changes to their circumstances; they can take control of the situation and actually change the situation. Those who have an external locus of control view themselves as subjects to the will and whim of others; they view themselves as simply pawns in the game who are hopelessly and helplessly moved around the board.

To overcome the corporate culture, which is resisting Agile adoption and Scrum implementation, it’s up to you to stand your ground and be courageous. Speak up. Decide for yourself whether you are content to be just another cog in the machine or if you want to make a difference and work in a fabulous culture.

I really despise the word “train” and all its variations (trainer, trained, training, etc.). Training conjures images of a lion tamer training animals to do tricks. Or, the best case is an athlete or soldier, etc., going through the same drills over and over again until the actions they seek to optimize are part of their muscle memory and the actions become almost instinctive. They are establishing a routine.

When we “train” people in various Agile topics, the goal is a bit different. We seek to educate, inspire, enlighten, and break free of the routine—to explore new ways and provide building blocks but not complete blueprints. The Agile Manifesto Values and Principles are building blocks. eXtreme Programming engineering practices are building blocks. Scrum practices and Kanban mechanics are building blocks—a means to an end, but not the end. It’s like teaching someone the scientific method and then inspiring them to use that approach to discover a world of possibilities in chemistry, physics, anatomy, and so on.

Everyone in an organization should be a leader. I often share with my classes (and give a talk at other events) about entrepreneurial spirit and how THAT is really the key ingredient to success. Everyone is a leader at some level.

However, I understand that the real question here is “How do we help the folks (who are setting strategy and vision for the organization and who are in control of the money) understand the value proposition of Agile and the practices that help to realize that value?” This person is really asking about the C-level, VP-level, director-level, etc., people in their organization.

They are frustrated.

Perhaps their leadership team has charged them with the directive of adopting Agile or, worse, implementing Agile. Then, that leadership team didn’t acknowledge the reality of improvement as a CHANGE in the way things are done. They want all the improvements, efficiency, quicker time to market, delighted customers, competitive edge, etc., without sacrificing any of the things they are doing today, like TPS reports and other metrics, investing in full-time ScrumMasters, co-locating teams, and so on.

It’s also possible that their efforts to become more Agile in their thinking are more of a grassroots effort and that management just doesn’t understand it at all. They see “this Agile” as a methodology of the month or don’t really care what it does as long as scope, cost, and time are all fixed. “As long as I get what I want, I don’t care how it is accomplished.”

I have run into that same immature, noncommittal leadership style on many occasions—leaders who are paid a lot of money to be in the positions they are in who are incapable of making trade-off decisions. Or, they just aren’t willing to take the appropriate risk in order to realize the benefits.

Everyone wants to be a rock star, but no one wants to practice guitar 8 hours a day. Everyone wants to look like Brad Pitt or Angelina Jolie, but no one wants to work out every day and forego that second helping of pie. It points to a larger sense of entitlement as a product of our decaying society.

Rich Roll, the famous attorney from Los Angeles, regularly evangelizes against this mentality and the cargo cult of “hacking” by advocating for good, old-fashioned hard work and trade-offs. Rich went from being 50 to 60 pounds overweight in his mid-40s to being the only person to run a triathlon on each island of Hawaii within the same week. He also regularly places in these insane Ultraman events, which are two back-to-back Ironman events.

The key here is value: focusing on the things that add value and de-emphasizing the things that do not. That is the mind-set that leaders must have.

When I agree to coach or train an organization, I make it clear that they need to include folks who are at that executive leadership level so that it’s clear what Agile means and what it does NOT mean.

I don’t “implement Scrum.”

I don’t “transform organizations to Agile.”

I help people identify experiments that they can run in order to learn from them. Small experiments yield small, gradual improvements and learning.

Oftentimes, leadership teams and organizations in general fear the change that Agility brings because they hear myths about wholesale abrupt change. I have seen this approach fail time and again. Identifying small experiments helps mitigate this risk.

I have been making a conscientious effort over the last few years to stop using the terms “success” and “failure.” Rather, we try something and have a vision of the outcome. Either we get the outcome we desired or we learned a lesson about the outcome. In the end, there is value in the outcome.

So, how DO we go about educating the leadership teams in organizations?

First, they need to know what everyone else knows.

The elements of Scrum, values and principles of Agile, etc., can be learned and memorized from a book. Anyone can teach Scrum in 15 minutes if it is just about memorization and theory.

The real value in the education process is having an experienced trainer and coach who takes the theory and makes it real with stories, discussion, activities, simulation, etc. It’s like the difference between someone who just does tricks in magic and someone who creates illusions or someone who gets up on stage and recites lines versus someone who brings characters to life.

Ideally, EVERYONE would attend the same training: executives, managers, teams, etc. This way, everyone hears the same message and there are no questions about what is expected. I have had many clients who have followed this approach with great success. The training was then followed by coaching over a period of time so that the teams could benefit from my experiences and the learning of other organizations that had gone down this path before them.

Executives and leadership teams often only want a 2- to 4-hour session that teaches them the very basics about Agility. Sometimes, it is worse. They just want an “executive overview” of Scrum. I don’t do workshops less than a day in duration, and I don’t know anyone else who does either.

Even a full-day workshop seldom provides an adequate understanding of how leadership needs to help support the practices and improvements or the REAL value that these bring. I find that there are usually many more questions than we have time for, and so I usually provide a day-long workshop on the fundamentals (for executives) and a one-day coaching session where they can ask more questions and we can get down to work looking at next steps.

At a minimum, the leadership team needs to be attending these education sessions at the same time that the ENTIRE rest of the organization is attending workshops on the operational aspects of Agile, that is, the practices. “Here’s the scientific method. This is a beaker. This is a graduated cylinder. This is what sodium looks like. Never let pure sodium come in contact with water. This is what could happen ... (demonstration).” And so on.

The education, or “training,” is only the first step. This MUST be accompanied by coaching, mentoring, advising, etc., or the organization will make many mistakes needlessly. They will not have the benefit of someone who has helped to guide other organizations before.

Engaging a coach up front can also help you figure out how to convince the leadership team that there is value in having them attend the training where they are learning about value. Having leadership teams attend a brief workshop is better than having them attend nothing. The brief training can open the door to additional learning, and perhaps they will have a better understanding so that they can support your teams.

Culture is complex.

Organizations are complex.

Large organizations with inertia will take patience to mature. When leaders and others in the organization set out to improve the way the organization operates, it will certainly take time.

Holistic change that considers value from multiple perspectives is the best approach to making the changes significant and sustainable. When organizations force change prematurely, there is often resistance and, eventually, rebellion and failure. Oftentimes, the organization is left in worse shape had they NOT undertaken improvements.

In the next chapter, we turn our focus to the products we create, which includes anything that we build for our customers that solves their problem and, consequently, delivers value.