Agile Armi

View Original

Scaling Scrum

Far too often I have seen scaling Scrum become an overly complex endeavor which actually does two things, either it crushes the empowerment of the Product Owners and the innovations of the development team or it adds needless time and dependencies across teams delaying the delivery of value to the customer, or both.

 Scaling Scrum is really quite simple in my view but, there is a necessary pre-conditions which are critical to have in place first. Before I get to that how do I recommend scaling? Simple, SoS (Scrum of Scrums), the least defined, most open to interpretation version of scaling that I know of. Because it is so simple it lends itself to modification depending on circumstances which allows it to be ultimately adaptable, if somewhat informal. If something more formal is required for any reason I would recommend Nexus because it is the closest to SoS in nature and therefor performance.

 These methods of scaling would fit all situations I have ever seen in my career (which is a lot of them) if again the necessary pre-conditions are met. This includes every SAFe implementation which companies have struggled with.

 The necessary pre-conditions are, one, that you truly have cross-functional teams and are not deploying siloed teams (one team doing data, one team doing architecture, one team doing anything but full-stack feature development). Siloed teams are the bane of scaling, they build in complexity, time and dependencies which are a nightmare to manage and why something like SAFe even exists.

 The second pre-condition is determining that you even have to scale in the first place. Too often I have seen major programs with many teams trying to scale something that could have been solved with one or two truly cross-functional teams in less than half the time and one tenth of the cost of the scaling solution in terms of human hours on the project.

 The third pre-condition is that you stay out of the way of teams and empower the Product Owners to say yes and more importantly no to features and you allow the development teams to innovate on how they deliver the requested features.

 If you can do these three things you will rarely and barely have to scale with Scrum. I have seen this proved to me time and again and would highly recommend you actually try it.