A(nother) Response to SAFe Criticisms: Part 2

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

In the first part of this series, I explained my intent behind answering some of the criticism for SAFe and asked for concerns that you would like to see addressed. I haven’t received any direct feedback, but the offer still stands. In the meantime, I’m going to dive into some of the more common criticisms I’ve seen already published. I’ll try to focus on one concern or small group of related concerns per blog post.

25% Scrum Masters

Edit: I originally published that "This is something that I have yet to find on the SAFe website but did come up in my SPC training. And I can tell you that it was not well received! If you want to hear about exactly how well it went over, just ask Valerie Santillo. Here’s what I got out of it:"

It has since been pointed out that this guidance is on the main website. I'm not sure if this is a new addition or an oversight on my part. It can be found in the Scrum/Agile Master Abstract in the Details section, under the heading "Sourcing the Role: A Part Time Responsibility".

Accommodating Reality

The truth of the matter is that you can’t always get Scrum Masters that are dedicated to that role. This should absolutely be avoided if possible, especially when working with teams new to Agile. What they’re saying by 25% is that, if you absolutely cannot get someone to be a fully dedicated Scrum Master, you should expect the role to take up about 25% of their time. I’d say that should about cover the administrative aspect and keep the wheels moving, but that’s about it.

Four Teams

A better approach is to make Scrum Master a dedicated role and allow them to work with multiple teams. The 25% recommendation tells me that Scrum Masters can handle at most four teams. Again, if you can avoid it, I would recommend having fewer than 4 teams sharing a Scrum Master. The most I’d personally recommend is two, with a preference to only one. However, this guidance is supposed to accommodate reality, and sometimes you just don’t have enough SMs to go around.

Starting Point

The 25% justification really only works when you’re just starting out and trying to get organizational buy-in. If you can suck it up and make it work well enough then, hopefully, your management will see the benefit a good Scrum Master could make and will make it happen. They’ll remove the part-time role, reduce the number of teams per Scrum Master – anything necessary to continue the improvements the teams have started making. That was actually the case with my first team. They went through their “Sprint 0” and their first two regular Sprints without a dedicated Scrum Master. They were struggling, but they were showing management that they were committed to making Agile work. I was allowed to come in as their Scrum Master – and only as their Scrum Master – to see how it would work. The rest, as they say, is history.

Final Destination

Good Scrum Masters always talk about how it’s their job to work themselves out of a job. If that’s the case, then eventually you’ll have teams that don’t have Scrum Masters. In those cases, there are certain responsibilities or overhead that the Scrum Master took care of which will now fall to the team. In those cases, the overhead work will need to be accounted for. From a Sprint Planning perspective, I think that cutting the velocity to account for 25% of a team member’s time for Scrum Master duties is entirely appropriate.

Thoughts?

That’s my response to the “25% Scrum Master guidance” from the SAFe training. Hopefully I was able to provide some context to show that it’s not as evil as you might have thought. Whether I was successful in addressing this concern or not, I’d like to hear your thoughts on the matter.

Continuing the Series
Part 3: HIP Sprints

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

When NOT to Use Agile

When HealthCare.gov first rolled out, everyone experienced how terribly it was built. Many Agile enthusiasts cried out, “If only they had used Agile…!” We have since learned that HealthCare.gov used Scrum. It’s uncertain how superficial their adoption was. Michael Daconta has already done a great job describing their poor use of Agile methods in the GCN blog, and NPR has published findings from the McKinsley & Co. consultants who were brought on in March to do a progress report.

My focus here is not about the degree to which Agile was or was not properly used for HealthCare.gov. My focus is to debate under what circumstances, if any, Agile will not work. When would you NOT use Agile?
My assumptions for this debate are as follows:

1. Agile is any processes, practices, tools, and frameworks that comply with the Agile Manifesto and its 12 Principles.
2. In the spirit of healthy debate, I assume the audience to be open to the possibility of new and different ways of doing things. This applies particularly to both Agile skeptics and to those entrenched in a specific Agile approach.
3. The ideas in this discussion are not etched in stone. I encourage you to share your own ideas so we can learn and grow together.

Possible Agile Risks

I was recently invited to an introductory Agile presentation. The audience was Project Managers with varying Agile knowledge and experience. It facilitated a conversation for answering questions and resolving concerns around Agile adoption. About halfway through, there was a slide that had five “Possible Agile Risks”:

1. Business or management commitment
   • Agile requires an increased level of commitment from the business and IT management to be successful
2. Remote or distributed teams
   • Agile benefits from close collaboration on a consistent basis. Distributed teams pose a challenge in the effort to do this effectively
3. Remote product owners
   • The business must be consistently involved, so a remote product owner may be challenging to engage
4. Balance delivering new features with high-quality, sustainable code
   • Agile delivers new features frequently, but this should never come at the expense of creating low quality code
5. Team not provided adequate guidance as they implement Agile
   • Anything new will take time to get good at, it is important to supply the team with training and guidance so they can improve quickly

This disclaimer followed these risks: “These risks do not preclude teams from applying Agile; they just need to be addressed in the scenarios they are present.”

Before we get to my reaction, let’s walk through these risks. Let’s identify why they’re risky in an Agile environment.

Business or Management Commitment

A deep understanding of the business is essential to the success of the software that supports it. In Agile methodologies, this means a dedicated person who has a deep understanding of the customer’s needs, often called a “Product Owner”. Traditionally, this person is seen as “from the business side”. However, getting someone from the “business side” isn’t always possible and is, arguably, unnecessary.

In my area we have Business Analysts who understand the business needs. They are bilingual in business and IT speech. Our developers and testers have a deep business understanding of the business because they’ve been supporting it for a long time. Some Agile practitioners feel the Product Owner role is unnecessary; they believe the team should understand the customers’ needs better than anyone. The team can, therefore, manage the work themselves.

In Agile, management is not a clearly defined position. Managers may feel their job is threatened by a “self-managing” team. A manager must have the team’s best interests at heart. They must become Lean-Thinking Servant Leaders, not Command-and-Control Managers. This is a cultural shift from Waterfall. Agile teams without Servant Leader management will plateau until they are allowed to “self manage”. However, that doesn’t mean they can’t find some measure of success.

Remote or Distributed Teams

This is one of the first and most frequent challenges brought up when introducing Agile. A team is distributed when its members are not capable of frequent face-to-face conversation. Lack of co-location for an Agile team is a challenge, no question. However, modern tools such as IM-enabled ad-hoc video conferencing, digital code review tools, etc. make long-distance coordination much simpler. It may be hard to work out timing with time-zone differences, but it’s possible to have a time overlap for some real-time collaboration. This may result in having a tech lead that takes the brunt of the development’s complexity to reduce the need for collaboration among the other team members, though this will limit the team’s overall productivity.

Remote Product Owners

For this I say, “See my previous 2 sections.” However, perhaps there are situations where the team is new to the product? Perhaps the SMEs are remote? Even worse, what if those remote SMEs do not dedicate time to work with the development team? Wait, what on earth are you thinking? Seriously, this is a bad idea, regardless of methodology. You are stacking the deck against yourself and setting the team up to fail.

Balance New Features with Quality Code

One of the 12 Agile Principles states, “Continuous attention to technical excellence and good design enhances agility.” Delivering new features at the expense of quality is the technical equivalent of being “penny wise, pound foolish”. This may be faster short-term, but the long-term consequences are a slow-down of delivery. Without addressing the quality of the application, it will eventually be cheaper to replace the application than to fix it. This isn’t unique to Agile. This brings me to my initial reaction to ‘Possible Agile Risks’.

My reaction to "Possible Agile Risks"

When I first saw this list, my reaction was that the first four are not “Possible Agile Risks”. Instead, they are “Possible Software Development Risks”! The four risks of commitment, distributed teams, remote product owners, and quality are often associated with Agile development because Agile brings risks to light early. Agile makes it much more painful to ignore risks than to address them. They are not less risky with non-Agile approaches. In fact, the realization of these risks is more likely in a non-Agile approach. In Waterfall projects, risks manifest so late in the process that they are painful and expensive to fix. The first four are risks to all projects; but not necessarily the fifth and final risk on the list.

Agile Training and Guidance

Without proper training and guidance, it is difficult for those unfamiliar with the Agile paradigm to be successful with an Agile approach. Most people new to Software Development find the Agile way of thinking to be a more intuitive and human-centered. In those cases, there is less risk because less training is needed.

Those entrenched with Waterfall approaches will find it difficult to switch gears. This is the only risk I could concede as being a “Potential Agile Risk”.

Where’s the Risk?

So there are my thoughts on five risks commonly thought to make Agile less successful. I have yet to find a risk that is made any less risky by Waterfall. Does that mean Agile’s guaranteed to succeed? Absolutely not. In fact, Agile will push you to your limits. Then, right as you’re starting to feel comfortable, it pushes you some more. However, Agile will consequently turn your team into the best team they can be. Agile will expose risks and inefficiencies sooner. It will also make them more painful. As long as you don’t ignore the pain, taking care of those risks and inefficiencies will be less expensive because they are dealt with early.

But hey, maybe I’m wrong. What risks have you heard associated with Agile? What situations are wholly inappropriate for the basic tenants of the Agile Manifesto?