What I like the most about the Scaled Agile Framework®

SAFe® – A missing guest on this blog

A friend told me recently I don’t write here often enough (or at all?) about the Scaled Agile Framework®. And he was right. So, my resolution for the upcoming months is to try and fix that a bit. I already have a couple of ideas to write up. But let’s start with what I think of SAFe®.


Me & SAFe®

But, First of all what is my relation to SAFe®? Well I’ve been helping organizations with agile at scale since 2009 so was following very closely works like Dean Leffingwell’s Scaling Software Agility and Craig Larman and Bas Vodde’s Scaling Lean&Agile Development  and was trying/adapting/extending upon their ideas. Two years ago in Spring 2013 I took Dean’s “SAFe® Program Consultant (SPC)” class and since then experimented even more with the various concepts in SAFe® especially the approach to implementation.

What I like the most about SAFe®

One of the things I like the most about SAFe® is the approach towards implementation with its emphasis on engaging leaders/management from the start and attending to their needs. I’ve been trying to advance a “start with leaders/managers” approach for some years now and I believe SAFe is certainly one good way to go about achieving this. I like the fact that identifying Value Streams and Agile Release Trains (ARTs) drives you to think in cross-functional end-to-end delivery in true Lean style. Even if you choose to wait with moving to cross-functional feature teams and build your ART/VS out of component teams you at least have the team of teams that is cross-functional and value-stream oriented. That is a pretty important step forward for many organizations. This is also pretty well aligned with my “Product Stream Kanban” approach that worked great in the field so far.

Continuing with implementation I like the Agile Release Train Quickstart Week which emphasizes training the train together with a good mix of theory, practice and starting the actual work. When Inbar & Roni first came back from SPC training and told us (The AgileSparks team) about this approach it was hard to grasp especially the “training the whole train together” approach when we would typically split to training classes of about 20-30 people at a time. Since then I had a chance to learn more about this in the SPC class as well as try some of this style of event myself and I’m now a strong proponent and use this approach regardless of whether the organization is going for SAFe or another framework for scaling. I believe it is more effective and I love how it feels as the coach/facilitator to run one of these events. Actually running a quickstart week in Boston a couple of months ago was one of my best experiences as an agile coach.

The Release Planning event – PI Planning, ART Release Planning – I like the amount of attention to effective participatory facilitation at scale. I like the “PI Confidence Vote” as the catalyst to risk management (what we sometimes call futurespective). I liked these so much that I took these ideas into a lot of the workshops I’ve been running since the SPC class in 2013.
BTW I typically use a “constellations” based confidence vote to get people moving about.

I like the effective choice of engineering practices to focus on. Not too much of the crazy extreme practices that turn people off but just enough of the right ones.

I like the fact that Flow is considered the underlying thinking. (There are some principles I would use more, but that’s for another section/blog post…)

I like the fact that SAFe® has a pretty high barrier of entry – you need to be serious about it in order to go through the implementation recommendations. This tends to screen out the tire kickers for people who are actually willing to go through a serious change in their organization.

Lots of reason to like SAFe®… Stay tuned for “What would make SAFe® even better” from my perspective…


How I would improve SAFe® to make it even better

The Context

In my last post I wrote about what I like about SAFe®. Now’s the time to talk about what we do in AgileSparks on top of it and I think should be included as part of the official guidance.

Where’s the MMF?

SAFe® is very clear about a lot of things. I wish it would add MMFs/MVPs to its requirements taxonomy and help people map those to the hierarchy. I use the MMF (Minimum Marketable Feature) and MVP (Minimum Viable Product) a lot with clients and it helps them understand how to create smaller stories in hard complex environments. The MMF/MVP is the one that focuses on marketable/viable value, freeing the story to provide a more local learning/integration value aiming mainly at reducing technology/integration risk and SOME product feedback if possible. I find it really helps team iterate when they understand this aspect. In SAFe® I tend to map the MMFs to the Feature layer (The fact that there’s Feature in MMF is a pretty strong clue…).  But sometimes Epics or Stories are the Minimally Marketable entity. Anyhow, the guidance around MMFs and MVPs is currently lacking.

Looking forward to even more of that integrative style of Kanban/Flow guidance

If you’re a regular on this blog you probably know I’m a big believer in leveraging Kanban practices to improve flow. I was pretty happy to see the “Visibility and WIP constraints” slide during SPC training portraying a basic Kanban board to help a SAFe® ScrumXP team improve flow. The guidance around “Sprint Execution” covers that in more depth and is pretty aligned with how I see an effective execution at the team level.

I wish we won’t see a KanbanXP training alternative to the ScrumXP training. I wish the ScrumXP training would just emphasize the right kinds of ScrumXPBan practices. I believe that would be best both for System/DevOps audiences as well as the core delivery teams. Our experience in AgileSparks certainly shows these sorts of hybrid trainings are much more useful to kicking off healthy teams. What I would probably add to that approach is the ScrumBan style planning/replenishment that enables teams to adjust the planning approach to their planned/unplanned context.

Between the Team level and the Portfolio level lies the Program level. This is a key aspect of SAFe and yet the flow is weak in that level at the moment. As I told Dean even during the SPC class I took back in 2014, I think Flow/Kanban-inspired visibility boards and charts should have a much more prominent role at the program level. In my experience managing the Program-level flow using Kanban is one of the biggest contributors to understanding and establishing flow in organizations. I think some of this is coming soon in SAFe 4.0 – I hope it will be good.

Living with Dependencies

SAFe® helps you deal with your dependencies and let’s you run an agile program even if you didn’t create truly autonomous teams. The PI Planning, Program Board and other aspects are actually very useful especially in the cases where the autonomy is at the level of the ART but not at the team level. That’s great. I just wish the guidance would be clearer on the fact that this is a crutch. A second best solution. Implementation guidance should be clearer on trying to create autonomous teams with minimal dependencies so that the program dependencies board would be very boring. Inspect & Adapt workshops should review dependencies and try to adapt things so some of the more painful ones will be brought down into the team level or gotten rid off altogether. I’m all for “Starting where you are” and “Respecting current roles & structure” as a change management approach and totally understand why big organizations would start with a dependencies-heavy structure. Heck, my “starting w/ product-stream kanban” starts the same way. I would love to see the disciplined prescriptive SAFe® machine help us drive a further evolution/revolution from that point on. In general, the guidance on Inspect on Adapt workshops should emphasize that they should leverage the power of bringing the whole train together to change deep stuff dealing with systemic constraints where structure, roles, and even the SAFe® practices themselves are all on the table for inspection and adaptation/experimentation.

Where’s the Management Workshop

In recent years we’ve become big believers in running Management Focusing Workshops as one of the first steps in AgileSparks lean/agile transformations (you can see it on the left side of the AgileSparks Way).  This is where we establish the energies and focus around the lean/agile transformation as well as educate leaders about their options and help them build a blueprint for what agile approach to go for as well as the implementation approach. I’m not clear on what in SAFe® achieves this. Is it the “Leading SAFe®” training for leaders? Probably that’s the closest thing but we’re not talking about training. We’re talking about a decision making workshop spiced with some training. We’re talking about choosing to go for the framework or aspects of it by the leaders/managers as part of the “Management Workshop” NOT by the consultants/SPC offline. This is key to testing early on that whether there is going to be commitment not just compliance to the change as well as drives more commitment by using a “fair process” participatory decision-making workshop.

So in our case for organizations that come to us looking for SAFe® implementation specifically we can certainly run a Management Focusing Workshop combined with a “Leading SAFe®” class. For organizations that are not sure what approach they want we will probably run a Management Focusing Workshop and then a “Leading SAFe®” if they choose to go SAFe®.

Leverage Flow thinking even more

Yes, SAFe® is probably one of the best things that happened to Donald Reinertsen’s “Principles of Product Development Flow” . It is certainly bringing Flow to a much wider audience than before. I wish SAFe® would go further than Cadence and Cost of Delay/WSJF though. I already mentioned how I would like to see Flow itself influence the program-level as well as the team-level. One of the first things I would is stronger guidance around effective batch sizes and their impact on internal and external cost of delay. Yes, the optimum batch size tradeoff curve chart is in the materials, but it’s not being explicitly used anywhere afterwards. I typically use this flow principle to help organizations choose effective starting points for their context as well as understand what they need to do to reduce their batch sizes even further. This applies to Planning batch sizes (Think PI Planning as a certain batch size compared to Sprint Planning), Delivery batch sizes, Integration batch sizes, Testing batch sizes, and several others. The thinking helps explain to people the role of pragmatic tradeoffs rather than fanatic extremism or maintaining the status-quo. It helps them decide which activities should be done in one-piece-flow (as part of working on a story), sprint-level, post-sprint in the System Team or left for the IP.

I’d like to see this tradeoff curve featured in the Inspect & Adapt workshops guidance as well to drive reduction of batch sizes for various activities throughout the value stream as well as identify the needed improvements to reduce the transaction costs/overheads and enable these reductions.

PI Planning is great – but what about Inspecting & Adapting the plan every sprint?

PI Planning is a great activity to kickoff a PI. In most of the organizations I worked with though the plan changes even within a 2-3 months period. I’m missing some activity at the ART level that inspects and adapts the plan throughout the PI. Yes, the Scrum of Scrum CAN support adjusting the plan but I think this is important enough to explicitly mention and support through some activity. A mini PI Re-Planning after the System Demo maybe? Before Sprint Planning? Many people feel the PI Planning is “Big Planning Up Front” or even “waterfall” and in many cases that is a huge turnoff for them leading to avoiding SAFe altogether. I believe guidance that emphasizes the role of PI Planning as “SOME Planning up front” and mainly a lot of collaboration/engagement/fair process that sets the train up for successfully executing using the PI Plan as the blueprint/map but not necessarily the actual route to be taken is more useful.


You can see I have lots of thoughts. Some of them are more concrete at least in my mind – I will try to elaborate on them in future posts. Others are more of an open question around what direction to take – I need to find the opportunity to experiment, discuss with other SAFe practitioners and then maybe write some more about them. I’ll be using this post as a “backlog” of options for exploration. If any of those questions/areas seem interesting to you or if you’ve solved those problems, I’d love to hear back from you!

It IS about individuals and interactions (Even though it seems to be about process and tools!)

Once in a while I hear a comment saying something along the lines of:
“Isn’t it kind of ironic that you agile people talk about Individuals and Interactions but what you give us is processes and tools?”. This comment typically comes after people are exposed to SAFe, Scrum, Kanban, whatever. All of these frameworks/methods LOOK like they are about processes and tools. I’ve seen people even mistake “Lean Kanban” for “LeanKit Kanban” associating it with a specific electronic tool and not the framework/method of how you manage flow using that tool. (To look at the bright side – I guess the LeanKit folks should be proud that they’ve become a “google it” in some circles …)

This comment is understandable – I think it is actually unavoidable. Why? The way I look at it the processes/frameworks/tools we use are DESIGNED to resonate with the comfort zone of people which is work at the processes/tools level (and not the values/principles).

But the processes/tools like Sprint Planning, Relative Estimation, No Estimates, Kanban Boards, WIP Limits, Scrum, PI Planning, Open Space Technology are not just processes. They are “Culture Hacks” in disguise.

We can speak all we want about Anthropology, Cynefin, Sociology, Complexity Thinking, Autonomy/Mastery/Purpose, Fearless Change, Invitation, Creating a game culture, RightShifting, Anti-Matter principle – and if you’re really serious about helping organizations improve their overall effectiveness you should probably be familiar with most if not all of those concepts.

But when I about these concepts most people in the real world look at me funny or fall asleep. Which is where the concrete process/tools come in. They help bring the concepts to life. Ideally people should both understand the concept/value as well as the example of how to use it. (BTW Many coaches teach people the concrete example/process/tool without initially discussing the abstract/concept. That’s not how I do it, but sometimes I feel they have a point…)

The risk is that without fully understanding the connection between the concepts/values/principles and the processes/tools that implement them it might SEEM like we are following a cargo culture or some mechanistic shallow simplistic approach. What we owe to ourselves as the community of people aiming to help organizations REALLY improve their effectiveness is to keep discussing this connection and scrutinize each process/tool to make sure it is really aligned with solid underlying theory of what makes human systems effective.

I’m sure some of you might have a different opinion about this. Discuss!

Boosting agility through Invitations

As you probably notice boosting agility is a key theme in AgileSparks these days. We saw it as a key interest area for people in Agile Israel 2015. We are seeing lots of interest in our “Agile Boost Camp” workshops. And we are seeing more and more clients that come to us seeking help boosting their agility.

A repeating concern that came up in many of those situations is that the “spirit isn’t there”. People are running the “usual suspects” set of agile/scrum practices but it “doesn’t feel natural yet”. When looking deeper it seems like there’s a two-fold problem. The practices need to be tuned, some deeper practices need to be adopted to support agility. And when wondering why people don’t run engage into an “inspect & adapt” learning cycle it turns out that people are disengaged from this “agile thing”.

In Agile Boost Camp workshop this week I actually heard from a group of Scrum Masters something along these lines: “We see things are broken and we have some ideas but the teams are simply not willing to play along. They are resisting any change/experimentation“. This prompted me to introduce the concept of Invitations, Pull-based change, and Open-space Agility. This resonated with people so much that it was the strongest epiphany/takeaway they mentioned in the workshop summary.

If you’re not familiar with the concept of Invitation – basically the idea is that people are much more inclined to play along with any change if you’re inviting them to play rather than forcing them to play. (I’m using the term play on purpose – the more change is like a game the more engagement we will get. See Mezick’s Culture Game or an interview on InfoQ for a deeper discussion/explanation)

I started with pull-based change inviting groups to go agile instead of mandating an organizational-wide agile transformation a couple of years ago. I talked about this in several conferences including an interactive workshop sharing some tools and techniques. But I’ve only recently started to go the full range and explore the power of open space with the whole group in driving this pull-based change deeper.

For example – Last week I introduced the same Invitations/Open Space Agility approach to a management team that was looking to refresh/tune their agility after a big change in their product focus and organizational situation – namely the need for more teams to work together on a single bigger product area to provide more business agility. Next week we are running a combination of short introduction to a couple of key concepts (If you’re interested – it is a mix of “Large Scale Scrum”, MMFs and tiny stories, No estimates at the story level, Cycle time instead of tracking tasks/invested effort, Tech Safety/Autonomy/Mastery/Purpose focus and ScrumBan Flow) and later on a mini-open-space event to see which of those topics resonate, which other issues/ideas/challenges come to mind in face of the new business agility requirement the group is facing.

PS If you are in Agile 2015 this week try to find Erez Tatcher AgileSparks CEO to talk about our experiences boosting agility…

Interesting Trends surfacing at Agile Israel 2015

My “Trends Keynote” is becoming a repeating feature of the Agile Israel conference. This year I chose to involve the audience by using a Kahoot survey combined with some insights that we (AgileSparks) have seen throughout the year.

First of all it was very cool to see more than 300 participants in the survey (out of ~600 in the audience). Kudos to Kahoot as well as the Israeli 3G network for surviving this onslaught :-)

Some interesting patterns/trends that are worth sharing:

The average agile experience among the participants was 2.4 years (with a healthy spread throughout the novice-expert range)

The time has come for the Agile Boost?


The majority of participants considered themselves to be already running some stable form of Agility (what we call Stable/Recharge) and the almost 40% of them considered themselves to be in the Improve/Boost zone – meaning they were looking to extend the benefits/depth of their agility.

60% actually said this was why they came to the conference – to find ways to Boost their agility and see how others have been doing it. There was still a healthy representation for people looking to learn how to lift-off towards agile as well as how to stabilize their new agile way of working.

The Glass Ceiling

The vast majority acknowledged there was a glass ceiling to their agility. Half could point out the specific glass ceiling and half couldn’t say exactly what was blocking them. Management Culture was pointed out as the main glass ceiling – Structure, Legacy Technical Practices/Tools and Real Customer Collaboration didn’t get nearly as many votes here. There’s a chance that this vote was influenced by David Marquett’s keynote which preceded my talk…

The Scaling Landscape – Only in Israel…

The majority of participants were working on agile groups of around 30-100 people.

When asked what Scaling approach they were using the majority actually voted “E2E flow using Kanban” with “SAFe or similar” coming in second and “Spotify style” coming in third a bit above “LeSS or similar”. This was a surprise but as I mentioned in the talk, Israel is probably one of the only places in the world where such an answer is even possible. And having many conference participants from one of the largest Enterprise Kanban implementations world-wide didn’t hurt either…

Preferred agile approach at the team level – A Usual Suspect with a strong contender…

Going down to the team level the results were more typical – around 56% said they were using mostly Scrum. 25% mostly ScrumBan and just 13% mostly Kanban. This is more or less what we’re seeing with clients that we’re helping. Scrum is still the mainstream but most of our new or boost engagements are either starting with or switching to ScrumBan these days.

Agile and Engagement/Motivation

When asked what was the impact on the level of employee engagement/motivation most said agile either helped or they weren’t sure about the impact. The reason we asked this question is because we’re seeing more and more interest in the humane aspects of agile and we love to work with organizations that care about these aspects. We also see a great connection between engagement/motivation and areas like Sustainable Pace, Technical Safety, Purpose/Mission and of course Decentralized Control/Autonomy. We even have our own modern take on Maslow’s hierarchy of needs to reflect that…


So – how different are those trends from what you’re seeing in your region?
If you’re interested to have a deeper discussion about these trends and others, you can leave a comment here as well.

PS If you’re interested in the presentations and videos from the conference – they are now available. Note that while all of the slide decks were in English some of the recorded talks were in Hebrew…