A(nother) Response to SAFe Criticisms: Part 3

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.

HIP Sprints

One criticism that’s prevalent among SAFe’s detractors is the inclusion of the HIP Sprint on the Big Picture. This is another case of SAFe trying to accommodate reality for organizations new to Agile. HIP, by the way, stands for “Hardening | Innovation | Planning”. It definitely gives the vibe of “Waterfalling the Sprints” and deserves our attention.

Hardening

Hardening should, in my honest opinion, be done away with as soon as humanly possible. However, if you’re brand new to Agile and have not yet built up your technical practices and hardware, releasing to Production without a hardening period is a bad idea.

SAFe does a good job of outlining what may be appropriate hardening activities versus those that could/should be done sooner. This is a good resource for new teams to get rid of hardening. Teams should focus first on getting activities that should definitely be done before hardening included in their Sprint Definition of Done. Then they move on to those that could be done sooner out of hardening. Eventually, they should aim to have their Release Definition of Done match their Sprint Definition of Done. At this point they could, potentially, go to Production with the completion of each User Story, which is just a hop, skip, and a jump away from a continuous delivery team.

Innovation

I know, I know, having an “Innovation Sprint” is like having a “Kaizen event”. And yet, we hold Retrospectives as an opportunity to focus on improvement that should, in theory, be continuous. If your company does not support a culture of innovation then no framework will magically change that. However, if you have a team that has managed to eliminate hardening activities, they should be rewarded with a Sprint of unfettered innovation. Give them a couple of weeks to do what they want and they will surprise you with how much they accomplish! Heck, it may even help to transform the company’s culture to one that embraces innovation.

Planning

This aspect of “HIP” tends to have the least resistance as Planning is well-recognized as a fundamental component of successful Agile organizations. The final Sprint of the PSI should include the planning activities that will prepare the Agile Release Train for the upcoming PSI. These include the Solution Demo (PSI Review), Inspect & Adapt Workshop (PSI Retrospective), and PSI Planning (PSI Planning).

Most ARTs will get these activities done in the last 2-3 days of the PSI. The timing and duration are flexible, but the activities are essential, especially for new Agile teams. This may not make sense for continuous delivery teams, but neither do any of the other time-boxed meetings that provide the structure for time-based commitment approaches (a la Scrum).

Thoughts?
Given my experience with new Agile teams, the HIP Sprint is a powerful tool. Without it, making the transition to Agile would be near-impossible. Is it a mature Agile practice? No, of course not. But is it better than continuing with Waterfall until the teams magically reach a state where they can do Agile without a HIP Sprint? Most definitely. That’s what I think, anyway.

Agile Complements

I was recently asked to explain the relationship between Agile and Innovation. I was intrigued by the question as I've never really tied the two together. In thinking about it, I've concluded that Agile complements many things, but it doesn't necessarily drive any of them.

The Role of Practices

The Agile Manifesto clearly states that one who considers themselves Agile values "Individuals and Interactions over Processes and Tools". However, we know that there is some value inherent in Processes and Tools, primarily in the behaviors that they reinforce. Given it's popularity, let's take Scrum as an example. Scrum has a highly prescriptive process that still manages to leave a lot up to the team. Sprint Planning reinforces commitments and transparency; the Daily Scrum reinforces face-to-face communication and self-managing teams; Sprint Reviews reinforce feedback loops within the team, as well as with stakeholders and customers; Sprint Retrospectives reinforce continuous improvement; the Sprints themselves reinforce small time-boxes; and on and on and on.

If you want to reinforce something positive at work, whether it be innovation, elimination of waste, any of the items listed below, or pretty much anything else, you can find an Agile process, tool, or practice that will reinforce it. With Innovation, you can take the practices of Capacity Allocation and Spikes to explicitly include time and effort for innovation into your process. This is assuming we're talking about developing innovative things, in addition to a Retrospective or other feedback mechanism for innovating the process and team themselves.

However, it is possible - and happens all too frequently - that teams adopt these processes, tools, and practices superficially, thus obtaining little, if any, of the intended benefit. In order to effectively reinforce behaviors, those behaviors have to already exist as part of your culture.

The Role of Culture

I've blogged multiple times about the difference between doing Agile things and "Being Agile" ("Agile: The Book vs. The Movie", "Understanding the 'Why?'", "Descriptive versus Prescriptive", "I Madge I'll - Agile Posers", etc). To deliver the best results possible, your team has to be Agile - they can't just superficially adopt an Agile implementation. When asked to explain Agile, they should go to the manifesto first and the day-to-day second. At the risk of getting too theological, Agility is a state of being and influences all aspects of a person's life (at least at work). Simply put, you have to establish a culture of Agility, where the principles are embedded in your company's DNA.

The same is true of Innovation or anything else. When people think of innovative companies they think of companies that have a culture of Innovation. Innovating isn't something you do as much as it's part of who you are. Of course their processes, tools, and practices reinforce Innovation, but that's a byproduct of something deeper.

As I said before, you can use tools from the Agile toolbox to help drive Innovation, but it can't just be lip service. If your company was built on Innovation (and it probably was) then get back to your roots and tell that story; remind people where they came from. Make Innovating seem natural, like coming home and eating comfort food.

No Silver Bullet

I'm going to be going more in-depth in the coming months on the idea that no one Agile implementation should be seen as a Silver Bullet. Before you implement anything, ask yourself "Why?"; what result or behavior are you hoping to get from it? Understand that different Agile processes, practices, and tools have their own strengths and weaknesses. Sometimes you'll have to blend different solutions to make something new that fits your needs. Sometimes you'll have to invent something that hasn't been done before. Most importantly, you will always have to examine what you're doing and ask what you need to change to be better. Keep the mantra "Never Perfect; Always Better".

Can Agile help drive Innovation? Sure. But some approaches will do that better than others. Begin with the end in mind, but remember that this is a journey and you don't know what you don't know. Be willing to adapt, but don't lose sight of your vision. If it sounds hard, that's because it is; if this were easy then we wouldn't be having this conversation!

What do you think?

Seriously, what do you think? Please tell me! I really don't like the "thought leader in a vacuum" setup. What I've shared here is the result of my learning and experience, but I recognize I don't know everything. I crave the perspectives of others. I want your insights, suggestions, criticisms, reinforcements - all of it. Leave a comment or tweet me @MLCarey321.