TL;DR — As waterfall survivor I understand concerns over SAFe®. That said, I don’t think it’s necessary to toss the baby with the bathwater.
I’ve also survived enough ‘Death Marches’ to know such slavish devotion to process and tools — especially in large enterprise endeavors — often creates situations similar to the one depicted in the above Dilbert offering.
Perhaps this is why I found myself recently intrigued the following article by Juha-Markus Aalto titled ‘6 SAFe® practices that make sense also for S sized teams.’
The author’s basic assertion being there are areas of the Scaled Agile Framework® that are as effective for organizations of less than 100 as they are for 1,000 plus.
Like many waterfall survivors, I too am concerned with ‘overly decorated Agile’, but not so much that I’m inclined to toss the baby with the bathwater when applying SAFe® principles to a small software endeavor.
So let’s take a look at Mr. Aalto’s six points from my own perspective as a practicing product person and recovering software developer.
- Strategic Themes — I think the important take-away from this point is to avoid putting the cart before the horse.
In the pursuit of building the right thing, I’ve found more value delivered when approaching the big picture from a Vision → Strategy → Tactics → Activities workflow.
Whereas I’ve witnessed increased risk and occurrences of delivering of the wrong thing — in both waterfall and Agile contexts — those times a product strategy was confused with an ‘always be busy’ Activities → Tactics → Hope It All Works Out philosophy.
- Program Epics —I don’t necessarily agree with the author’s assertion “Scrum teams typically interpret ‘epics’ just as really big user stories that don’t fit in one sprint …” Moreover, I’ve enjoyed good results taking a page out of Lean Startup in defining value stream and program class epics.
In setting-up such epics with a measurable hypothesis, we in turn equip stakeholders with the validated learning they need to either stay the course or pivot.
I suspect such an approach would be just as useful to an ‘S’ sized company as it would for a mammoth enterprise.
- Program Kanban — Given the start-up nature that often defines ‘S’ sized organizations, what’s not to like about a “pull” approach that balances demands for work with available capacity?
For example, the next time you’re working with a team new to Agile, why not start them off in a Kanban setting as an incremental stepping stone to Scrum? It’s worked for me, three times now. Four if you count a team that opted to continue with Kanban.
Similarly, I’ve found Kanban far more productive in approaching new projects than instituting a ‘Sprint Zero.’
The real trick with Kanban is establishing executive buy-in on the wisdom of WIP limits instead of treating the cautionary tales contained in the ‘Mythical Man Month’ as a “how-to” guide.
- Features — I don’t know of any sized company that doesn’t like features. Let’s just guard against the “12 Signs You’re Working in a Feature Factory.”
- Program Increment Planning — This gets into the area of SAFe® that describes releasing features on a cadence, and deployments on demand. This is one area where a good dose of prescriptive process is not a bad thing.
For a smaller company, I’d suggest agreeing on a repeatable and reliable release process; like Gitflow. I might then align this process with an agreed upon & rehearsed set of responses to various factors — be they scheduled or otherwise — that serve as a catalyst for ‘potentially releasable features’ to ship into production.
One very small, implementation related example of tooling that supports PI planning might be coupling feature toggles with domain rights triggered by a client willing to take an early iteration on a limited basis.
- Innovation and Planning Iteration —Here’s where I wish the author of the article had stuck to a handful of suggestions, especially where he asserts:
“Sprints tend to be hectic, and for an S-sized team, it’s likely to be harder to find time to work on some more risky, seemingly lower priority, yet innovative ideas …”
The writer then citing “… system integration and testing activities, such as performance or security testing …” as examples of such work that might be pulled in as unplanned work the end of a sprint.
You only have to get burned once by ‘that which is what’s unlearned’ to find yourself prioritizing those items known to have the greatest risk higher in the backlog. And it rarely hurts to validate that learning and/or know what we don’t know sooner than later.
That, and I’ve had to rip-out integrations of too many third party vendors whose services go belly-up because they were too focused on front end features to deal with ‘low priority’ items such as scaling or security (ahem).
If you haven’t guessed by now. I’m trying to avoid aligning myself with either side of the Scaled Agile Framework® debate.
I suspect a good number of y’all are similarly inclined and have some ideas those elements of SAFe® that might scale well in a smaller context.
Why not share?