More SAFe Mix-ins

February 9, 2019

Based on the popularity of the first post on SAFe Mix-ins, here are a few more ideas for practices that you could mix and match with your SAFe implementation:

  • No Coaching – Train the managers and leave them in charge of the transformation
  • Sociocracy – introduce Sociocracy
  • No Prep PI Planning – Do a quick half day of training and then go straight into the PI Planning event
  • Agile Chartering – Integrate concepts from Diana Larsen and Ainslie Nies book, Lift Off!
  • Disciplined Agile Development – are there more document centric practices that might apply, especially in highly regulated industries?
  • Lean Budgeting – can we incorporate concepts from Lean budgeting or beyond budgeting?
  • Agile HR – Can we bring HR into the big picture in a meaningful way?

As you can see, there really are no limits to the elements that we can use to enhance or refine our SAFe rollouts. I want to thank all the folks who attended this session at Agile Open Northwest this year. Their ideas were amazing!


SAFe Mix-ins

February 8, 2019

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.


On Human Thought and Planning

January 3, 2010

Over the holidays I’ve been reading “The Design of Everyday Things” by Donald Norman. It’s a wonderful read, but dense – it’s definitely “armchair and a pipe” material – you can’t rush it.  I came across this interesting quote regarding the nature of human thought:

But human thought – and its close relatives, problem solving and planning – seem more rooted in past experience than in logical deduction. Mental life is not neat and orderly. It does not proceed smoothly and gracefully in neat, logical form. Instead, it hops, skips, and jumps its way from idea to idea, tying together things that have no business being put together; forming new creative leaps, new insights and concepts. Human thought is not like logic; it is fundamentally different in kind and spirit. The difference is neither worse nor better. But it is the difference that leads to creative discovery and to great robustness of behavior. [p.115]

In this paragraph Norman is talking about the fickle nature of human thought. When he refers to planning as a close relative of human thought, I couldn’t help but think of project planning. As Norman suggests, human thought is not the orderly process we might like it to be. If that is the case, then project planning is not the neat and tidy system that some people would like to sell you. If thought and planning are truly akin to one another, as Norman suggests they are, then I would suggest that any system that attempts to turn planning into some sort of logical, deterministic process is destined to fail. The intriguing idea here is that planning needs to accommodate creativity, intuitive leaps, non-linear processes.

I think there are a lot of people who grasp this notion, and I think there are many others who have a great deal of difficulty with it. Those who don’t accept this notion tend to try and wrap more and more layers of process around the problem. Those who accept the need for creativity and intuition in planning – people who are more comfortable with uncertainty – are more likely to treat the planning process as a dance: You know what the steps are supposed to be, but you are prepared to change at any moment.


How I Discovered “Gordon The Guided Missile”

June 18, 2009
Alastair Cockburn gave the opening keynote speech for the conference. He mentioned that the conference was a product of a local user group called the Salt Lake Agile Round Table. I looked it up and here is where you can find more information if you are interested:
If you live in Utah, you are very lucky to have a high powered group like this around. You can also find likes to other agile groups in the area as well as their mailing list. There are a whole bunch of them in the Salt Lake area. I’m thinking I may have to create another one here in Seattle just for the fun of it!
Alastair started off with a story called “Gordon The Guided Missile” that was originally told by John Cleese. It is a marvelous tale and you can find it here: http://www.contextmag.com/archives/199806/innerGame.asp?process=print
The point of this funny little yarn is that making many little mistakes is OK. In fact it is necessary in order to make the adjustments necessary to succeed. As Cleese points out, you can’t say, “Well, I got that right, so now I’d better fix it.” It’s ridiculous. Cleese urges us to rediscover a sense of playfulness with our ideas that will allow us to be creative.
Now I don’t consider myself a particularly playful person. I can be downright stodgy at times. But I love creativity. Maybe that’s why I like software development so much. Writing code, what I like to think of as creating “castles in the mind”, requires us to create dazzlingly complex logical structures using only 1’s and 0’s.
So for me it comes down to this: If these ethereal software structures are a product of creativity, and if creativity is a product of playfulness, then we software developers need to get out and play more! And John Cleese, in his own wonderfully silly fashion provides some tips on how we might do this:
1) Admit mistakes freely. In our particular community of development process fanatics, this means that we need to create a safe environment where this can be accomplished. Scrum, XP and other Agile methods have “built in” this support for discovering and admitting mistakes.
2) Fight the tendency to identify with ideas. This is essential for fostering collaboration on a team. When we identify too closely with an idea it becomes harder to share it with others.
3) Create an atmosphere of tolerance of mistakes by becoming a model. Discuss your mistakes. Share them with others. Who knows? Your mistake could be the genesis of the next great idea.
The rest of the keynote was quite good, but  “Gordon The Guided Missile” was definitely my favorite part!

Fireworks_Rocket

Alastair Cockburn gave the opening keynote speech for the Agile Roots 2009 conference. He mentioned that the conference was a product of a local user group called the Salt Lake Agile Round Table. I looked it up and here is where you can find more information if you are interested:

http://alistair.cockburn.us/Salt+lake+city

If you live in Utah, you are very lucky to have a high powered group like this around. You can also find links to other agile groups in the area as well as their mailing list. There are a whole bunch of them in the Salt Lake area. I’m thinking I may have to create another one here in Seattle just for the fun of it!

Alastair started off with a story called “Gordon The Guided Missile” that was originally told by John Cleese. It is a marvelous tale and you can find it here:

http://www.contextmag.com/archives/199806/innerGame.asp?process=print

The point of this funny little yarn is that making many little mistakes is OK. In fact it is necessary in order to make the adjustments necessary to succeed. As Cleese points out, you can’t say, “Well, I got that right, so now I’d better fix it.” It’s ridiculous. Cleese urges us to rediscover a sense of playfulness with our ideas that will allow us to be creative.

Now I don’t consider myself a particularly playful person. I can be downright stodgy at times. But I absolutely love creativity. Maybe that’s why I like software development so much. Writing code – what I like to think of as creating “castles in the mind”, requires us to create dazzlingly complex logical structures using only 1’s and 0’s.

So for me it comes down to this: If these ethereal software structures are a product of creativity, and if creativity is a product of playfulness, then we software developers need to get out and play more! And John Cleese, in his own wonderfully silly fashion provides some tips on how we might do this:

1) Admit mistakes freely. In our particular community of development process fanatics, this means that we need to create a safe environment where this can be accomplished. Scrum, XP and other Agile methods have “built in” this support for discovering and admitting mistakes.

2) Fight the tendency to identify with ideas. This is essential for fostering collaboration on a team. When we identify too closely with an idea it becomes harder to share it with others.

3) Create an atmosphere of tolerance of mistakes by becoming a model. Discuss your mistakes. Share them with others. Who knows? Your mistake could be the genesis of the next great idea.

The rest of the keynote was quite good, but  “Gordon The Guided Missile” was definitely my favorite part!