SAFe Configurations

Estimated Reading Time: 5 minutes

I just shared my perspective that SAFe isn’t a hard-coded methodology and while it gives you a comprehensive and to some even overwhelming set of practices, there are still a lot of choices.

My old friend Sutap suggested: Would be great if you can share examples around how SAFe is not a one size fits all framework. Examples/ case studies will really help. From experience, enterprises typically have very different projects: from large programs running for years with say once in a quarter releases (say customer A) to enhancement requests released very frequently (but unsteady pipeline: say customer B) to fixed scope fixed timeline regulatory projects (customer C). Would love to hear how SAFe will handle such (and maybe many more) scenarios.

(Sutap and I worked on a scaled agile transformation in one very big enterprise where we saw all of those and more …)

So here are a couple of examples/case studies, some real and some semi-real. I’m not trying to explain every concept I mention here as the goal is to portray the optionality, not teach you SAFe. (If learning SAFe is your goal, come to an Implementing SAFe class or go read SAFe distilled…). without further ado – here goes:

When an enterprise like this implements SAFe they would probably have different Agile Release Trains (ARTs) for each one of those programs. All those ARTs would work on a Program Increment (PI) cadence like all Scrum teams work on a sprint cadence. But each of those ARTs might have a different style of PI.

The ART serving Customer A might naturally have a quarterly PI. The ART serving Customer B might have a quarterly PI or maybe a shorter 8-week PI or maybe even shorter (yes – despite the fact that SAFe says 8-12 weeks! herecy!).

The ART serving Customer C might have a quarterly PI. A would release every quarter. B might release every iteration, C might release to production only every 2-3 PIs.

The Program Kanban for each of them might look different to reflect the different budgeting/analysis/governance mechanism each customer uses and the different “road to production” downstream from development. For one customer a 3rd party SI might have developers/testers on the feature teams with the enterprise. For another customer it might be hard to integrate the SI’s people into the agile teams so a combination of internal Feature teams and a few Component teams with people from the SI might be the right approach at least initially. In other cases the SI might not even be willing/structured to collaborate at this level and would be considered a “Supplier” at the Value Stream level.

The infrastructure the enterprise has for customer A might be advanced enough that Continuous Integration (CI) exists and there’s no need for a System Team. For Customer C it might be too early and the System team is needed both for performing the integration as well as starting to figure out how to achieve CI. Maybe in Customer C the System Team is just focusing on improving the CI and is also working on achieving Continuous Deployment capabilities (CD). In Customer B it might be the case that there’s both a System Team and a DevOps enablement team each focusing on different stages in the delivery pipeline.

PI Planning itself might look different. The level of predictability needed in A is high and the backlog and ART  are stable enough to enable it so PI planning is pretty classic. In B it is not THAT important and actually much harder to achieve so PI Planning focuses more on main dependencies and projects saving significant capacity for emerging enhancements throughout execution while using PI Objectives to make sure the business and the ART are aligned on which enhancements to focus on as they emerge. In C due to the fixed scope fixed timeline the backlog SHOULD be even more stable than A and we would probably spend more time on estimating the features in the Program Backlog and building a roadmap to see whether we have a converging plan or need to invest more resources. Even earlier in this type of project, when doing the portfolio-level business case for this sort of epic we would need to do more analysis and estimation than for epics for customer A. And the features for customer B might actually not have any Program/Portfolio Epic above them.

For customer C it might make sense to have one roadmap for the 3 ARTs working on the project. For customer A it might make sense to have separate roadmaps since each ART is working with a separate business “tower”.

Here are a few other examples from other contexts:

  • How to deal with multiple small value streams – sometimes it makes sense to aggregate them into one Agile Release Train (ART) – especially when you want to be able to have one Program Backlog in which you prioritize those two value streams against each other and allow the ART to focus on a specific value stream/product for a while. Sometimes it makes sense to actually have a few smaller ARTs even if they are really small to the point of being mini-ARTs – in case the investment/funding for each value stream is quite stable/separate and the teams working on the different products are separate as well.
  • Should a critical core technology group that is common to multiple products be considered a separate ART? Should the different products and this core technology group be on the same Value Stream (VS) level to allow coordination in Pre/Post PI Planning? Should the products be in different VSs because that’s the only connection? Should this group be split into teams that each join a different ART? Sounds like the right “Agile” move but on the other hand what if prioritizing what this core technology group works on across the different products is a key portfolio-level decision? if so, having a team per ART actually decentralizes control of this key resource TOO much.
  • For some ARTs pair-working would make sense 20% of the time. For other ARTs that are currently scaling up their capacity by bringing in more people (Think the program working for customer C which just found out they need to add 3 more teams over the next PI to deliver the fixed scope project on time) they might go into pair-working 80% of the time initially to accelerate knowledge sharing and then go back to 20%.
  • In some cases the Scrum Master will be a technical lead inside each Agile Team. In other cases they will be one of the Managers working with the ART each covering 2 teams.

Enough questions, configurations, and options? I think so…

It would be great to have “one size fits all” for all of those. And maybe you can find some SAFe consultants that would tell you that’s the case. The good ones will at least make sure you understand there are open questions and multiple options. The best ones would be able to share from their experience what worked where, the upsides and downsides, and be able to help you figure out what configuration to try as well as guide you in inspecting and adapting on your way to figuring out the SAFe configuration that’s best for you.

 

Musings about “Hard-coded” Frameworks

Estimated Reading Time: 2 minutes

A recent discussion on the Scrum Alliance Linkedin group was around Mike Beedle’s claim that “Hard-coded Frameworks are neither Agile or Frameworks” which is clearly aimed primarily at SAFe.  

I admit to thinking something similar before really getting to know SAFe in depth. Over time I realized SAFe isn’t one size fits all. Far from it. 

It has many configurations and options. Do we need the Value Stream level? a System Team? at which level? How many ARTs? Component teams or Feature teams? Which metrics? Which ART to start with? Even if you don’t follow my Invitation-based SAFe implementation approach that is now a formal SAFe guidance article, you still have a lot of options at all levels and it is hardly a hard-coded methodology. Yes, not all practitioners understand this. But that’s a familiar problem from the Scrum space isn’t it. “Though shall do tasks”. “Though shall estimate in story points using planning poker”. “Though shall stand up in the Daily Scrum”.

Scrum was and is a powerful tool. SAFe, Enterprise Scrum, Nexus, LeSS, Kanban and others are powerful tools as well. A powerful tool is typically also dangerous at the wrong hands or the unexperienced hands without good guidance.

Besides – it IS funny to hear about the danger of force-fitting a hard-coded framework from leaders in the scrum community that have been telling us about SHU and following practices and the danger of scrum-but all along. And rightly so! Sometimes you do need to insist on a practice/change even if it feels hard! Agile IS about challenging your comfort zone.

Can we all agree that the real art/expertise is to figure out the right set of practices that is the goldilock between too much force-fitting and too-easy “common sense that is somehow too close to the status quo”?

(Updated) Oh – and also can we also agree there’s a huge difference between force- fitting practices to challenge your comfort zone (which is healthy change management done right) and forcing people to do something vs inviting them to consider trying it? 
 

Speaking at Lean/Agile US 2017 – February 27-28th

Estimated Reading Time: 1 minute

Lean/Agile US 2017 is a new conference taking place in south Florida on February 27-28th. It is an interesting attempt trying to “reboot” some of the missing Lean-oriented agile community.

I was invited to speak about approaches to Scaling Lean/Agile from my perspective and experience as well as give a deeper half-day introduction to SAFe workshop.

The program looks very interesting with lots of long-time friends who happen to be thought-leaders in our small world of post-agile thinking.

If you’re interested in going beyond the classic treatment of Agile/Scrum (And I’m guessing you are if you’re reading my blog…) you’ll find the program and the discussions very refreshing I’m sure.

So – see you in Fort Lauderdale later in February?

LeanAgile US 2017

Yes, SAFe 4.0 includes kanban. But does it include the beauty of Kanban?

Estimated Reading Time: 3 minutes

One of the things I like in SAFe (Scaled Agile Framework™) 4.0 is the fact that is includes kanban visualization and flow management so explicitly as part of its recommended practices/building blocks at all levels ranging from the Portfolio (which was part of earlier SAFe versions) through the Value Stream and Program all the way to the Team levels.

Together with the explicit and up-front discussion of Lean-Flow principles and Reinertsen’s work that is indeed great news for kanban fans.

A recent comment from one of Yaki Koren my colleague at AgileSparks that “He’s reminded of the beauty of Kanban” (Reading Mike Burrow’s “Kanban from the Inside” while spending most of his days knee-deep in SAFe/Scrum engagements) sparked a realization that has been bubbling up for me though. SAFe 4.0 might include kanban but it doesn’t necessarily include Kanban.

What do I even mean by that? Capital-K Kanban refers to the change method not just the visualization/flow management technique. That method that “Starts with what you have”, “Respects the current way of doing things” and uses flow visualization/management, WIP limitation, and making your current policies explicit together with evolutionary experimentation and feedback loops to help you improve your fitness for your purpose.

Regardless of whether you want to follow the Kanban Method as a change management approach in your context, I think it is important to REMEMBER what it is about, and discern what sort of kanban/Kanban you’re using and what’s the purpose when you use it as part of SAFe (or Scrum or Agile Marketing or whatever). Too many people out there including some Agile Coaches and probably most SAFe Program Consultants probably can’t tell the difference.

If we don’t do anything about it, I’m afraid over time the Kanban definition that is part of SAFe 4.0 will join the Kanban as defined by Scrum practitioners (both miss more or less the same points) to be the canonical definition of Kanban that Lean/Agile practitioners are aware of and the Kanban Method will become a secret/lost technique. You know what, there’s a good chance that’s already the state of affairs.

And it’s a shame. Because even as part of a SAFe implementation it might be very useful to leverage the Kanban Method and use the Kanbans you have at every level as an engine for that “Inspect & Adapt” you’re seeking.

Even with SAFe Start with what you do now; Agree to pursue incremental, evolutionary change & Respect the current process, roles, responsibilities & titles can all make sense. SAFe takes a slightly different approach about it but it actually respects the “project manager” role for example and fits them into the “Release Train Engineer” role. It can live with component teams even though it prefers Feature teams. Many extreme agilists call it “safe” and closer to waterfall with its approach to periodical planning. That can be seen as a form of “start with what you do now” or “Respect the current process and needs of your surrounding stakeholders/clients”.

And because SAFe starts safe, we need SAFe practitioners to “Agree to pursue incremental, evolutionary change” from their starting point. We want them to ascend beyond the “Essential SAFe” in an effective focused way. We want them to use flow-focused experiments to evolve towards a better fit-for-purpose. We want them to understand and harness the power of WIP limits to drive not just collaboration but also uncovering your impediments/bottlenecks and dealing with them systematically.

We want SAFe practitioners/consultants to consider how Kanban can help them deal with SAFe theater – with those organizations that follow just the “easy” parts of SAFe, for which PI Planning is just a meeting of managers/stakeholders, where planning is push-based rather than pull-based (Where “No we cannot fit it into this PI”), where dependencies abound because they stayed with the “easy” siloed component teams or even component trains that actually make life really tough when you try to create flow.

Let’s see how this message resonates. If it does, I have some ideas what to do next about it…

 

 

My Agile 2016 Talk – How to make SAFe really SAFE Scaling Agile using Pull/Invite rather than Push/Mandate

Estimated Reading Time: 1 minute

Here are the final slides (including live session polling data) from my Agile 2016 talk last week. If you want to read deeper into this I suggest you look at my blog series from earlier this year.

PS Sadly enough the session wasn’t recorded. If you’re interested in to see this talk leave me a comment here. If there’s enough interest I might do a webinar/periscope/whatever at some point.