Here's some coverage of our recent deal with Akamai to use their DSA product. iProperty…
Being SAFe on the train
After two months, I feel that the time is right to talk a bit about SAFe (Scaled Agile Framework) and what it means to me and to my team. Two days after I started in my role I was thrown into the first release planning session for our agile release train (the train metaphor got a workout with our “DME” engineer hats, bags and water bottles). It was a new experience for everyone but even more daunting for me as I was also learning the people, the product and the places. I’ve read a number of derogatory comments and articles about SAFe and I wanted to address what I have found – both positive and negative.
I think the first thing to point out is that SAFe is not for everyone – it’s very specifically tuned for a certain type of organisation. Typically it’ll be implemented by large, complex organisations with many staff working in various methods and with legacy systems or large commercial systems. If you’re a small web shop with a handful of developers and a relatively simple technology stack, it’s not going to add much more than following a good, technologically sound agile methodology such as XP.
I’ve had the benefit of three iterations watching the teams pick up SAFe and having done a two day course on leading the agile enterprise. What struck me most is how familiar most of it is – at the team level, SAFe pretty much advocates XP. It talks about technical mastery and code quality, it talks in the usual terms of iterations, stand-ups, retrospectives and showcases. There’s really not much to argue with here.
When you get up to the program level, there’s more to learn but, as the training makes quite clear, if you know your Lean principles, you’re going to find it much more comfortable. The concepts of taking an economic view, managing queues, limiting WIP, decentralisation of control, etc all make appearances in SAFe. The one thing I’ll admit to struggling with is SAFe’s need to normalise story points between teams. While I understand the rationale, I can’t help feeling that it’s trying to force absolute time estimates onto developers which is never something I’d advocate. It’ll be interesting to see how this one plays out – especially with the rise of the #NoEstimates crowd.
On the flip side, the really positive aspect of the synchronisation of teams is that you get the whole organisation together regularly for release planning. We had around 140 people in one room all working on planning their next release. It was amazing to see the interactions between teams solving problems that usually would have taken multiple meetings to close off. There was a palpable energy from all the participants. We were also lucky to have an excellent facilitator who is one of the leading experts in SAFe running it for us (incidentally, he’s also written a very thoughtful and engaging post on his thoughts on SAFe and the criticisms levelled at it.)
As with any methodology or framework, the key is to understand what you’re doing and why you’re doing it. If it starts to resemble a cargo cult then action is needed to educate and guide teams. I do understand why some detractors fear that SAFe will get rolled out as a silver bullet to organisations with little understanding of what makes agile tick. You absolutely need to build engaged and highly skilled teams for this to work. Bad leaders will build bad teams and throwing any framework at the problem won’t solve that. But for a complex organisation with many moving parts, having a cheat sheet of answers to the common problems when scaling agile and one which is evolving and backed by some highly talented people can’t be a bad thing.
How does SAFe handle inter team story dependencies ?
There’s a few mechanisms – first is to try and set up your feature teams to be self contained to minimise any cross-team dependencies.
Of course, that’s not always possible and you’ll end up with features that have stories going to more than one team within the release train. In such a case, the dependencies are identified during the program-wide release planning session (see the diagram of the PSI program plan with the bits of red string). The dependencies are then managed during the Scrum of Scrums (we run ours every morning).