Well, this is for the advertising part 🙂 because in reality, many things can go wrong while scaling i.e. having multiple Agile teams working on one product or a solution.
Very often, teams go for scaling when there is no need to. The idea behind a product should be tested and validated e.g. MVP before going full scale. See what you can do with one team first, deliver value, get feedback from stakeholders, improve as a team and then only decide if scaling will help. You may also check if an iterative and incremental approach is the right fit for you. See when NOT to use Scrum for more info on this.
#2- Not getting the basics right
No matter what Scaled Agile says, SAFe is based on Scrum. If you do Scrum bad at team level, it will be worst at scaled level. Make sure that teams understand Scrum well before going into a scaled model OR make sure that experienced and skillful Scrum Masters will join the Agile teams to support them in this organizational change.
#3- Set up the wrong structure
SAFe advocates the usage of red threads between teams and features/enablers to manage dependencies during iterations. The best way to manage dependencies is actually to avoid them! How do you that? By setting up cross functional teams working on features (feature teams) rather than components (front end, back end, integration…). Setting up component teams in your program will likely resulting in increasing dependencies between team and waterfalling your PI (Program Increment). With feature teams only, dependencies are reduced to a minimum.\
#4- Thinking that partial roles will do
Very often with SAFe, we see internal members of an organization having key roles e.g. RTE, PM, POs, system architects, etc…and developers being outsourced. This system can work, no issue there. However, having such key roles only partially allocated (20-40%) is a recipe for disaster. Being a PO for example is a full time AND demanding job. Consider less roles but fully allocated instead of many roles partially allocated.
#5- Using SAFe by the book and not evolving
SAFe can be a good model when starting a scaled initiative – the problem is if the teams and the program do not evolve from it. They need to inspect and adapt the events, roles and artifacts on a regular basis.
Some example coming to mind:
1- PI planning of two days. The PI planning is a long event (2 days) and can be either an exhilarating or terrible experience. Actually, the PI planning does not have to be two days – 1 day or a few hours may actually be enough. How to make this happen? Preparation with backlog refinement with teams prior PI planning is key.
2- Scrum of Scrums. When teams have a need to synchronize, only having a sync once or two weeks as mentioned in SAFe is just not enough. Communication should be happening as much as necessary without waiting for an event, at a minimum once a day e.g. use of Slack/Google chat channels. Encourage developers from one team to talk to another.
3- Product Managers vs Product Owners. More cooks in the kitchen make it difficult to steer your boat! If not working closely together, POs and PM directions and views on the product may differ. So less is best in this area e.g. one PO for multiple teams rather than one PO per team. A different scaling model (LeSS) advocate that a PM act as a PO for 4-6 teams. This ensure that the team members takes ownership of the product and grow in maturity e.g. talk directly to customers to understand needs and clarify requirements.
4- System Architecture. One person cannot know it all – it is therefore key that the developers have the possibility to express their requirements and more importantly, to own the architecture. The system architect should be seen more as a supporting role rather than a leading one. You can consider an alternative model with key members in each team discussing, documenting and owning the architecture.
Those are a few thoughts I observed over the years – what are yours?
