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!