SAFe Mix-ins
At Agile Open Northwest I invited folks to a conversation that I called “Radical SAFe.” The idea was to look at ways to mix-in some of the more radical agile practices with a conventional SAFe transformation. By radical, I mean some of the more advanced practices that people have been experimenting with in our community. Examples that come to mind are things like dynamic re-teaming, mob programming, no estimates, and so on. You may or may not feel these practices deserve to be called radical, but they are recent innovations that we have been exploring with agile teams.
I feel this is necessary because my own experience has been that many SAFe transformations are very cookie cutter implementations. That’s not necessarily a bad thing (some customers insist on that), but sometimes I think we miss opportunities to customize the SAFe framework to better fit our customers needs. That, and frankly I get a little bored doing the same thing over and over. I’m looking for a little creativity in terms of the tools and practices that we use to guide typical transformations. I find myself wondering, what can I do differently when I do my next SAFe transformation.
This session truly was an inquiry. I walked into it with a few ideas of my own, and I was curious what other ideas people might have. I really wasn’t sure how it would go. I know that in the agile community there are a fair number of folks who really dislike SAFe, so I knew that any conversation like this could be very emotionally charged. My feeling was that conflicting opinions might actually add some constructive energy to the conversation. It turns out I was right.
As we got into the conversation, folks were very engaged and curious. As I listed some ideas, they jumped right in with their own. We started with:
Fast Agile – Incorporated Ron Quartel’s ideas for using Open Space to create a light weight, self-organizing agile organization.
Open Space – Using open space to run Quarterly PI Planning and other collaborative events.
Mob Programming – have the entire team working on the same problem together in a ‘mob’.
Dynamic Re-teaming – allowing people to pick which teams and products they want to work on a periodic basis (perhaps every PI).
No Estimates – Drop WSJF and story points and use radically lightweight estimation practices.
Making roles transitional – perhaps SAFe roles like RTE and others can go away over time.
Roles by election – Rather than executives selecting who fills each role, we have the teams elect the people they want to the roles of RTE and Product managers, etc.
Radical co-location – Perhaps we insist that all teams must be co-located.
Role deprecation – Maybe rather than adding roles, we eliminate roles. At the end of a SAFe transformation the organization has fewer roles than when they started.
All of these options are available to us to integrate into a SAFe implementation.
It’s worth mentioning that one of the reasons that SAFe is so popular, is that SAFe is so prescriptive. We do things the same way every time. For traditional, large organizations that are first adopting agile, mixing in a bunch of exotic practices probably isn’t a good idea. I wouldn’t even try. At least not to begin with. However, with some organizations, key stakeholders are ready and interested in some innovative techniques, so we should feel free to use them where it makes sense. The mix-ins I list here are just a small subset of possibilities. There are many more options for us to experiment with.
At the end of the day, SAFe is just a framework, and even though it is more prescriptive than most, it doesn’t specify everything. There is more than ample room for enhancement and modification that can help change the character of any SAFe rollout. It allows us to fine tune our approach for a given customer. Whether in small ways or large, this can benefit many of our customers.