A(nother) Response to SAFe Criticisms: Part 1

Full Disclosure: I am a certified Scaled Agile Framework (SAFe) Program Consultant (SPC).

Before you continue reading this somewhat lengthy, multi-part blog post, let me lay out the prerequisites. Well, really just the one. If you are not already at least somewhat familiar with Dean Leffingwell’s Scaled Agile Framework (SAFe) then this post is not going to be as meaningful to you. The official website for SAFe is http://scaledagileframework.com, although there are others out there (Andrew Blain, for example) who have done a good job of explaining what SAFe is.

Last year Dean Leffingwell (and SAFe in general) had a significant presence at Agile2013. In response, Ken Schwaber wrote a provocative blog post entitled “unSAFe at any speed”. What Ken failed to accomplish was to produce criticism that was any more founded than your run-of-the-mill angsty hearsay. He did, however, manage to set off a civil war within the Agile community over whether or not SAFe should be allowed in the Agile club or beaten until silenced or killed. I have been rather surprised at how many “Agilists” have chosen the latter.

Agile has always appealed to my inclusive nature. The goal is outlined in the Agile Manifesto and its 12 Principles. Anything that strives to deliver within the paradigm of the Manifesto and its Principles can be considered Agile. All approaches have strengths and weaknesses, and all approaches focus more on some aspects than others. In the end, though, all approaches are well-intentioned efforts to elevate teams to their potential. I think that’s beautiful, I really do.

A roadblock that has existed for years is that of large organizations who are not already Agile. Getting these behemoths to shift the way they work, much less the way they think, is no easy task. Many have taken the “All or Nothing” approach – either adopt an existing Agile approach in its purest form, wholesale, with no alterations, or surrender yourself to your competition, wither away, and die. Neither of these options is particularly appealing to most of these organizations, so they ignore Agile and continue their status quo.

Along comes Dean Leffingwell and SAFe and, all of the sudden, you have an Agile approach that the organization can use to become Agile. Of course it looks different from the other options currently available, but that’s kind of the point. It aims to establish Agile Principles and Lean Thinking in larger enterprises in increments that are actually realistic. Just as every Scrum team is different, every organization that adopts SAFe does so in its own way. And, just like Scrum, a lot of the implementation details cannot be neatly outlined in a guide or abstract for anyone to pick up and repeat without putting in any of the effort.

The reality of the situation makes the Purists out there really uncomfortable. A lot of criticism has been published. I am going to attempt to address some of this criticism. My intent here is not to get everyone out there to use SAFe. Heck, I don’t even intend for everyone to like it. My intent is to clarify a few misconceptions, first and foremost the one that SAFe is not Agile.

I’ll be publishing my response in multiple parts in order to accomplish this intent. The number of parts depends, at least partially, on you. I want to know what criticisms or misunderstandings of SAFe you would like me to respond to. I would further ask that you communicate with me as a respectful professional (and I’ll do the same). I’ve seen this topic get out of control without ever getting to root cause. Not that I have delusions of grandeur or anything, but I’d like to think that I can help find and address the root cause of these criticisms without it turning into a shouting match. I guess we’ll find out.

Series Posts:
Part 2: 25% Scrum Master
Part 3: HIP Sprints

Muscle Memory vs. Muscle Confusion

The most popular Agile methodology in practice today is Scrum, which relies heavily on ceremonies. Any decent Agile coach working with a new Scrum team will drill these ceremonies into them in an effort to get the most out of the framework. They drive cadence, alignment, continuous improvement, transparency, etc. One of the big benefits of doing this is that it becomes a part of their routine. They no longer have to figure out how they're going to align on a daily basis; plan their work; communicate with their customer; inspect and adapt; etc. All of those things are "baked in" to the framework. Because there's so little prescribed, it's easy to pick up and repeat forever. By making those things rote, you develop a sort of Agile "muscle memory".

Wax on, wax off, stand up for 15 minutes

Muscle memory is a condition where a task is repeated so frequently that it can be performed unconsciously. Just think of Mr. Miagi and Daniel-san in The Karate Kid. Mr. Miagi had a lot of landscaping work to be done, and Daniel wanted to learn Karate. As luck would have it, the motions required of a Karate black belt are the same as sanding decks, staining fences, and washing cars - who knew? Right as Daniel is ready to throw in the towel, Mr. Miagi attacks him Daniel's muscle memory kicks in to save himself from being pounded by a Karate master. Likewise, those Scrum ceremonies become reflexive and help new Agile practitioners focus on the hard task of developing new software instead of thinking about how they're going to go about "Being Agile".

However, too much of a good thing can be bad. Once that muscle memory kicks in, it makes it harder for our Agile "muscles" to grow. The body has optimized how to do the repetitive thing, and doing it more doesn't really result in any added strength. This is a problem that strength trainers and body builders are familiar with. Your workout routine can't be too routine or you'll plateau. You have to introduce what's called "muscle confusion".

Muscle confusion is the concept of varying the types of exercises you do, as well as the number of sets and reps of those exercises, to avoid muscle memory and keep building muscle by tearing it and letting it repair stronger. If muscle memory kicks in then it becomes harder to tear the muscles. You see this concept manifest in workout regimens such as P90X and Cross Fit. One of the difficult things to get right, though, is the right amount of muscle confusion. Switching 100% of your exercises 100% of the time won't get you optimal performance.

I liken muscle confusion to a Kaizen mindset in Agile. You have to have an urgency about change, but it has to be small, incremental change in order to be effective. Change too little and muscle memory sets in - boring scrums, useless retros, tedious planning, etc. Change too much and the disruption causes everything to start falling apart.

P90X and Cross Fit are not for everyone. You will have to determine as a team how much change you can handle on a sprint by sprint basis. Some will change almost daily, others will be lucky to successfully adapt on one thing per sprint. As long as you're being honest with yourselves, that's fine. Just beware of muscle memory and muscle confusion. Optimize the change, and there are no limits to how much you can grow your Agile strength.

I Madge I'll - Agile Posers

When I meet someone who wants to talk about Agile I start by asking, "What do you know about Agile?" Most of the time I begin to hear those key buzzwords the newly indoctrinated are so proud to spout off: "It's where, instead of Waterfall," said with a grin and a wink, "your scrum has sprints and they stand up and there's no requirements and you demo and it's amazing!" I often think to myself, "Seriously? Why do these people think this?" So recently I decided to apply Occam's Razor and ask what the simplest answer is. My conclusion? Somebody told them this.

Consultant Speak*

Okay, so I don't think anyone told them something quite so incoherent as what I put, but they definitely started out with 1) a specific methodology in mind, almost certainly Scrum, and 2) an unholy amount of buzzwords and Agile vocabulary to accentuate just how different Agile is from the dreaded Waterfall. I get it - you're probably (relatively) new to Scrum and you're super excited about it and want the whole world to know how it changed your life. Unless, of course, you're a consultant who's trying to confuse a potential client into throwing money at you to turn their IT shop around. Tsk, tsk.

"...It's Not What You SAY, It's What You HEAR!"

The problem is these people don't know what Agile is. They don't fully understand what it is they're saying. All they know is that if they keep saying certain words with enough conviction then people will think they know what they're talking about. It reminds me of the game "Mad Gab". In case you're not familiar, players in the game read words on a card that don't really make any sense. They're not supposed to. The words on the cards, said with the correct inflection and pacing, are supposed to sound just like a commonplace phrase that your team is trying to guess. For example, these new, hopeful, and largely ignorant future Agilists are saying "I Madge I'll" in hopes that you'll hear "I'm Agile"! The problem is they aren't.

Agile Posers

I was recently working with a fellow Agile Coach (I know, I don't care for the term, either, but I'm not sure what else to call him) and we were collaboratively taking notes via Google Docs. On occasion we would have an impromptu discussion in the document due to a tangent that our notes took us on. One such tangential conversation was about Agile Posers. It went a little something like this:

"‘how to spot an agile poser’ (consultant-speak?)

1.one who pretends to be someone who's not. 2. who tries to fit in but with exaggeration
urban dictionaryl33t speakpwned you, you poser

'5. Someone whos acts like someone they’re not,but not realizing that there being fake, basically a loser trying to fit in.' - UrbanDictionary.com

'6. A poser is someone who tries hard to be something they arent. Usually, posers call other people posers because they are jealous that the person they called a poser is more skater/stoner/goth/punk/rocker/grunge/Agile/etc. than they will ever be.' - UrbanDictionary.com

posers often fool themselves first.  they aren't always (deliberately) not

ask probing questions.  why do you like it, what was good, test their belief."

On the off-chance any of my readers are Trekkies...

Our conversation went on to include things such as mining for conflict and Open Space sessions as means to help draw out and coach Agile posers. Take another look at definition #5. These are the people I'm talking about here. Those who want to be Agile, who hear about it and crave to belong. They'll ask anyone who claims to be Agile what that means and they'll cling to whatever they're told. So what's the take-away here? Tell them the right thing!

Being Agile vs. Doing Scrum

When people ask me what Agile is, I always go to the Manifesto and backing Principles first. I emphasize over and again that Agile is a way of thinking, a paradigm, a perspective, an approach. Yes, there are implementations and yes, Scrum is the most popular by far and yes, there are those who will tell you that the definition of Agile is Scrum. I'm here to tell you that it's not.

So what's the harm in people thinking Agile is just Scrum? Scrum's not all that bad. Of course it's not. I love Scrum, it's helped my organization tremendously. The problem with believing that Agile is just Scrum is it sends you on a quest to be the best implementer of a set of practices. Your Retros will eventually dry up because you can't get any more Scrum-like. But you'll keep doing them because "that's Scrum." You have to understand why Scrum is set up the way it is. Why you're asked to perform certain ceremonies. You have to know in what direction to Adapt when you Inspect in your Retros. And, most importantly, you have to be willing to break the rules like an artist once you've mastered them. You have to be willing to try things that are not in the Scrum Guide. You need Kaizen!

I'm Right!.. Am I Right?

As per usual, I don't have much to go on here other than my experiences and the stories I hear from others. So I want to know: What does being an "Agile Poser" mean to you? Have you experienced those "Mad Gab" Agile enthusiasts? Have I hit the mark on being Agile versus doing Scrum, or am I way off base? I want to know what you think, and I want to use your ideas to make myself better (being completely transparent here). Please leave a comment or shoot me a message on LinkedIn. I'd love to hear from you.



* I received some feedback that this post was offensive to consultants. I would like to clarify that I am not trying to group all consultants together and say that they are all this way. I am basing this on conversations I've had with people who were introduced to Agile by these types of consultants; observations from a friend who is a former consultant; and my first-hand experience with sub-par consultants. I know there are amazing consultants out there - I've met them, too, and admire the work they do - but there are an alarming number of consultants out there who do fit this bill.

Descriptive versus Prescriptive

“Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.” -Martin Fowler, Agile Manifesto signatory, from his October 2006 blog post, “Agile Imposition”

As a member of the SAFe community, I've heard and experienced a lot of concern and displeasure with what is perceived as a highly prescriptive Agile framework. However, having actually met and worked with Dean, Colin, and Alex, I have never felt they were trying to shove a framework down my throat. To me it felt more like "your organization is new to Agile and we come with decades of experience; try this framework on, including all of these recommended practices, see how it fits, then tailor it accordingly." Granted, that vibe came from face-to-face conversations, not websites and white papers.

This problem is not unique to SAFe. Pure Agilists have always pushed for a more "hands-off" approach. It's interesting to me how married some of agilists become to a certain methodology - conversations with these people usually boil down to "you should let people do whatever they want, but if you're a good coach and they really get the principles then they're most likely going to go with my favorite methodology." This is often coupled with, "I also offer Agile Coaching services..." The problem is, they've got a point about the coaching. You can't leave teams all to themselves; you have to support them somehow. I'm not saying all Agile teams need a dedicated Agile Coach, but they need the resources necessary to ensure the direction in which they adapt is in accordance with Agile principles and the environment that will support them when (not if) they fail.

Many of my thoughts on this subject have recently been affected by the information I was recently exposed to at OpenAgileAdoption.com. One of the references cited is Martin Fowler's "Agile Imposition" - an article written nearly seven years ago and more relevant now than ever before. Of course, Fowler and Open Agile Adoption are both focused more on organizational transformation than prescriptive frameworks, but I think the principles still apply. It all boils down to enacting change through influence but without mandate. It's a principle that every good Scrum Master is already familiar with - Servant Leadership. You've got to not only lead the horse to water but get them to realize just how parched they are!

So how do you do this within the context of a framework? My opinion: change the way you say what you're trying to say. More specifically, make it clear why you recommend certain practices, when they're relevant and highly likely to improve results, and when it might make sense to try something else. You're still going to lay out the recommended practices, but you'll be taking a descriptive approach to explaining them rather than a prescriptive approach.

The Scrum Alliance uses the term "Common Practices" instead of "Best Practices" to describe what would traditionally be considered "Best Practices". By changing the term they change the reader's perception. They're not saying "you need to do this or you can't be considered among the 'best'"; they're saying "this is something that a lot of people do in this situation, and here's why." That's the approach the entire industry needs to be taking. I would bet that many framework authors already think that way. The problem is that way of thinking is not reflected in their writings.

What do you think? Does this resonate, or am I way off base? How would you expect websites and other communication regarding what are typically seen as "prescriptive frameworks" to change to be more in line with a descriptive approach?

Taming the Wild West: the Differences between Agile and Cowboy Coding

One of the strongest arguments for Agile is that it’s not Waterfall. However, not everything that isn't Waterfall is Agile, a fact that’s not always understood. This misunderstanding hurts the Agile brand when people familiar with only Waterfall begin associating all other methodologies, including a lack thereof, as Agile. I want to be very clear about this: Agile is not Cowboy Coding, and Cowboy Coding is not unique to Agile teams. It is important both to understand how Agile and Cowboy Coding are different and what Cowboy Coding looks like so that you can identify it on your teams (yes, even Waterfall teams).

The Loner

One of the easiest signs of a Cowboy Coder is that he’s a loner. He may be working under the name of Agile, but there are no Agile methodologies or frameworks I’m aware of that support such behavior. In fact, the backing principles of the Agile Manifesto state, “Business people and developers must work together daily throughout the project”; “Build projects around motivated individuals”; “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”; “The best architectures, requirements, and designs emerge from self-organizing teams”; and “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” The manifesto, its principles, and all Agile methodologies and frameworks I know of are very human-centered with an emphasis on collaboration.

If you have a loner on your team that insists on working in a silo, there’s a possibility that you have a cowboy in your midst. Try to rein them in using mandatory meeting/ceremonies that promote meaningful conversations and practices like Pair Programming. If they absolutely refuse then you will likely end up spending considerable time managing the work around them – holding ad hoc conversations, formal code reviews, knowledge transfer workshops, etc. – with diminishing returns.

Straight to Production

Working directly with Production code or with a source code repository that isn't versioned is a bad idea. Don’t get me wrong, I love Continuous Delivery and working off the trunk, but a software development team must be very mature and disciplined to make this work. They use feature toggles and branching by abstraction to protect code that isn’t ready for Production. They build test suites around the code so that each commit is verified against regression. They do their due diligence to make sure that a change isn't going to blow up if it’s pushed to Production. Cowboys, simply put, don’t.

If you find yourself consistently in a situation where the same person or people are making changes directly to Production without due diligence then you might just be working with Cowboys. Have them read up on DevOps and Continuous Delivery so they can learn the right way to get changes to Production quickly. Emergency situations that require quick, non-vetted changes to Production should be avoided at all costs.

Wastes of Time

The Cowboy will often refer to Testing and Documentation as a waste of time. They may even commit the cardinal sin of Agile, reciting the Manifesto blasphemously: “‘Working software is the primary measure of progress’; anything else is just a waste of time!” To those people, I would ask them to define “working”. Does it pass the Acceptance Criteria associated to the work (or did you even bother to ensure you had Acceptance Criteria)? Can anybody actually use it, or is it too buggy or complex? Is anyone other than yourself aware of the assumptions made around input, output, workflow, etc.?

Without proper testing and documentation, you can’t prove your software works nor can anybody understand how it works. With that being said, if your tests and documentation don’t contribute to the value and usability of the software then they are, in fact, a waste of time. Focus your testing efforts on tests that actually stand a chance of failing and finding vulnerabilities. Don’t spin your wheels creating “write-only” documentation. This is the approach that Agile espouses; anyone who says tests and documentation are altogether useless is operating with a Cowboy mindset, not an Agile one.

“Emergent Architecture”

One of the backing principles to the Agile Manifesto states “The best architectures, requirements, and designs emerge from self-organizing teams”. There are those who believe this means “just make it up as you go.” That’s not entirely accurate. There still needs to be intelligent design, and that design needs to make the software as easy to comprehend and maintain as possible. As another principle clarifies, “Continuous attention to technical excellence and good design enhances agility.” This means having a thorough understanding of the latest design patterns and practices. It means taking the time to refactor working code into something better. It means taking a little bit of time up-front to design what you think will work and adjusting as you go.

Agile developers do not shoot from the hip. They take pride in their applications; they have a sense of ownership. They will throw research spikes, read books, build proofs-of-concept, attend conferences – do what it takes to build the right thing in the right way. You’ll spot a Cowboy by their purposeful lack of direction, sticking code wherever they please with the sole purpose of “getting something to work” so they can move on to the next thing. If they do it in the name of “emergent architecture” then call shenanigans. That’s not architecture, it’s just reckless.

Somewhere to Hang their Hat

The good news is that cowboys can be tamed if they can come to appreciate the practices, tools, and frameworks that Agile provides. Cowboys won’t jump on the bandwagon just for the heck of it. There will always be some that refuse to be tamed, but many will see the benefits and forsake their wandering ways once you give them a safe place to hang their hat.

One of the great things about reformed Cowboys is they are used to developing quickly and cross-functionally. If you arm them with XP practices, Agile tools, a Kaizen mindset, and continued training and development, they can become model developers that contribute quality software time after time.

Just don’t make the mistake of trying to get them to do something for which there is no tangible benefit. They don’t take too kindly to that.

Understanding the “Why?”

"Would you tell me, please, which way I ought to go from here?"
"That depends a good deal on where you want to get to," said the Cat.
"I don't much care where –" said Alice.
"Then it doesn't matter which way you go," said the Cat.
"– so long as I get somewhere," Alice added as an explanation.
"Oh, you're sure to do that," said the Cat, "if you only walk long enough."

I've written a couple of blog posts on understanding the principles of Agile, the “book version”, as it were, in order to achieve the success that is associated with Agile. If you've been in the Agile arena for any significant amount of time, you know there are a lot of disagreements as to the “How” of Agile. There are many different methodologies, frameworks, tools, and practices out there to support Agile teams. Some believe this is because people simply disagree on how to best implement Agile and, in some cases, this is true. Others understand Agile was never intended to be “One Size Fits All”. There are many options because there are many teams and each team must determine what solution works best for them – and evolve that solution over time in the spirit of Continuous Improvement.

This means you cannot determine “How” you want to implement Agile until you understand the needs of the team. “We need to have a Daily Scrum.” Why? If you can’t answer this then it’s not going to bring as much benefit as it should. If you understand the Daily Scrum as a touch-point to align across team members; identify risks and dependencies the team is encountering; and jump-start communication that will occur throughout the day then it becomes a stale and stagnant status update meeting.

My recommendation to Agile teams, and all human beings for that matter, is to not adopt something without understanding the “Why?” behind it. True Agile teams do not do things for the sake of doing them. They do them for a reason and nothing is sacred; if a tool or practice outlives its usefulness then it must be “put out to pasture” so as to not get in the way of the team’s continued growth. By regularly re-evaluating the usefulness of your current implementation, you also get the benefit of being open to new things. No matter how good your team is, they will never be as good as the team they could be.

People vs. Process ... vs. Principles

“Be firm on principle but flexible on method.”

-- Zig Ziglar

Until recently, I have observed the difficulties and issues manifested in the work environment and debated, both with myself and with peers, whether the root cause was the people being unskilled or unmotivated or the lack of a quality process. It was not until recently that I have come to realize that it is the founding principles on which we operate that makes the biggest difference in how successful we are.

When debating people versus process, the argument for people is that good people seem capable of producing amazing results regardless of process. However, I’ve seen great people time and again be suppressed by poor process, being forced into inefficiency for the sake of policy. In grass-roots meetings and informal conversations, both within my company and in conversations with others across the industry, I hear complaints of red tape, write-only documents, and wasteful tools and bureaucracy that dishearten and discourage talented people. At best, people are being forced to work below their capabilities. At worst, people are lost to another company that doesn’t include such roadblocks.

On the other hand, a good process can, ideally, bring a team to a hyper-performing state quickly and keep them there, while poor processes seem to only be good for shielding people from the ugly truth. Processes, policies, methodologies, and frameworks that emphasize value and seek to eliminate waste tend to bring out the best in people. The downside is that the best processes expose weaknesses within the team and force them to confront their demons. If the problem is the people are not skilled or committed enough then they may not be willing to put in the effort required to get the team to where they need to be. The best case scenario is the team members who are unwilling to change leave to free up the rest of the team to reach their potential, while the worst case is they stay and cause the team to drag and stagnate.

Neither of these seems to get to root cause, so let us consider the principles that form the foundation for people’s decisions and behaviors. When considering founding principles as the root cause, it is necessary to start with two assumptions. The first is that the people doing the work are genuinely doing the best they can with what they have. It may be somewhat altruistic, but I believe it is true for most people. The next assumption is that these same people are working with a process and in an environment that allows for and even encourages continuous improvement. Whether it’s explicit or not, people tend to adapt the way they work over time, based on their experiences and their guiding principles.

If my assumptions hold true, and my experience tells me they do, then those guiding principles that determine in which direction the process evolves are the most important factor in driving productivity, efficiency, and morale. The founders of the Agile Manifesto understood this. They came from various backgrounds exercising various forms of what are now considered Agile Methodologies. They did not define any specific process for success – instead, they defined a mindset, a paradigm, for approaching Software Development. They backed this manifesto with 12 principles, only one of which pertains to the type of people that are needed to be successful:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

The only qualification they state is that the individuals be motivated. Surely some people are inherently more driven than others, but, for the most part, motivation is something that can be fostered by the culture and environment that the individual is operating in. The other 11 principles provide great insight into how those people should work as well as what should be done to support those people in their pursuit of high quality Software Delivery. If people have learned and accepted these principles then they will recognize how important and urgent it is for them to improve individually, not just as a team. It is not a character flaw to admit imperfection – indeed; it is the manifestation of character that one can admit to room for improvement.

The Agile Manifesto is not the only source of correct principles. There are many books and courses in existence that focus on this very subject. The whole premise of Lean Six Sigma is there are solid principles that can be applied in any situation to eliminate waste and reduce delay. I think Lean, Agile, and Product Development Flow principles are the most crucial to our combined success, but I recognize that there are others. What I would like for you to ask yourself is, “What are my guiding principles? When things get uncomfortable, how do I evolve the way I work?”

Why is this important? Because too often we pick up a new process hoping it will be our Silver Bullet, the solution for all our problems, the answer to all our prayers. But we adopt these processes without taking the time to understand the principles on which they were founded. As a result, we bend the process to fit what we are comfortable with and lose much, if not all, of the benefit the process could have afforded us. This mistake of adopting a process without adopting its defining principles is what I’ve referred to previously as the “Movie Version” of that process as opposed to the “Book Version”, and the book is always better than the movie.

Only by taking the time to understand correct principles will we be able to govern ourselves most effectively. As Blaine Lee said, “The principles you live by create the world you live in; if you change the principles you live by, you will change your world.”