Help, My Organisation is Doing SAFe!
Survival Guide for Agile Coaches
You have given everything. You have shown in countless meetings, conversations and intranet articles why it makes sense for an organisation to become agile, what being agile means, why defined process protocols don't make sense in a complex context. You have assisted agile teams to formulate a challenging Definition of Done, and helped alleged Product Owners, to contribute as requirements specialists on a team. You insisted that the management take Lean thinking to their heart, you have put a lot of effort into our change, transition or transformation team. Finally everybody agreed that organisations need to become agile nowadays. There even was a big talk by your management with images of oil tankers and speed boats.
And now that: External consultants convinced your management that SAFe - Scaled Agile Framework - is exactly the right solution for your company. You do not just want isolated Scrum or Kanban teams - agile needs to me the measure for the entire development. Instead of starting on a blank page, you rather should take an approach that already contains instructions for any kind of challenge. Aligned planning? Release trains! Reasonable architecture? Architect roles! Many projects? Portfolio Kanban! Isnt't it correct that SAFe is built upon Lean and Agile? Everything is there: Sprints, user stories, product owners, meetings with sticky notes...
Isn't it reactionary and counter-productive to listen to this small voice inside your head, that tells you that you do not become more sportive by building a fitness center? That SAFe with all its contents and fancy posters just appears like an oil tanker with lots of speed boat pictures on the hulk? SAFe experts, often classical project management consultants who managed to stay awake through a three day powerpoint marathon, ensure you that this is not the truth about SAFe. You do not have to use everything from SAFe. The most important things are alignment and compliance to the shared approach, the focus on delivery capability.
It everything was so easy. SAFe lends heavily towards planning. If we just knew what to produce, and planned it extensively, the rest would just fall into place. SAFe is so good, that it does not requrire empirical process control - although this is the fundamental element of many agile approaches like Scrum. If necessary, you can update SAFe to the latest version. This does not only sound like a classical approach like RUP or SAP. It is the same business model. Promise an organisation a clear, simple solution for their complex problems. Place loads of consultants. Make the organisation dependable on your approach. If it does not work in the first place, bring in more consultant. Rinse and repeat.
And now you're deep into trouble. You consider looking for a new job. This is not the flavor of agility you have been dreaming of. No fun. As agile coach you surely find another company where you can place your talents and skills. But not everything is lost! There are three ways that might lead to more understanding and readiness for being agile. I call these ways resistance, conformity and responsibility.
Form a resistance group. Whenever management introduces a new role, be ready to question it. Tolerate what makes sense to you, and fight what does not make sense. If you can't fight it, find workarounds. You want overall retrospectives? An improvement backlog? Communities of practice? Just do it! Agility arises inspite of the introduced processes. Breaking the rules becomes the valid rule. Just like in Waterfall before, you as agile coach ensure that your teams can deliver, that they are in close contact to the business experts, that learning is put into the foreground. You just need to be aware of one thing: If your counter measures actually work, people will claim that SAFe is working. If your counter measures fail, it is your fault. Be prepared to look for a new job.
Just as capitalism destroys itself, SAFe will eventually fail and collapse. All you have to do is to ensure that SAFe is played by the book, according to the blue print. Oh, there is a role missing? Not all developers joining the planning meeting? Enact as process police that you reach a 100% alignment to the SAFe framework. Avoid all inoffical communication relationships. Only do as prescribed. This will eventually expose the dysfunctionality of SAFe. And cause your projects to hit the wall. Or you could actually cause SAFe to work as intended. If not, your management might not blame SAFe but the people. Everybody prepare to look for new jobs, then.
"Come on", you might say, "I am not responsible for introducing SAFe, that was our management!" Are you sure you're not talking about "blame" here? Opposed to popular thinking, the way of responsibility is not about finding the responsible person. Also not about reproach for yourself - "I could not stop them from chosing SAFe". And especially not just to put up with the conditions and enact work-to-rule. Taking responsibility means that your continuously reflect about your own position, intention and possible contribution. If you are responsible, you are able to find the best reaction or response to a given situation. Taking responsibility opens up opportunities you might not have thought about before. For yourself, your team and your environment. Use your influence, your voice, your experience and the respect for your people around you. Here are some examples:
- Facilitation: Ensure that your meetings are not dominated by electronic tools. Bring in a high level of collaboration. Collaboration fosters agility - better relationships improve actionability.
- Simplicity: De-scaling is more difficult than scaling. But you can help to simplify your organisation. For instance by reducing roles outside of teams. That works by conviction, practice and results.
- Transparency: Remember the Scrum foundations. If one agile rule gets violated by the outside, make the effects visible. Radical transparency is the natural enemy of dysfunctional decision making.
Take responsibility. At the end of the day, what counts is how much your organisatzion has internalizied the principles of focus on people, real value creation and continuous improvement. Do not get sucked in pointless trench fights, but do not give up your passion for real agile work and life. SAFe will eventually pass.
About the author
Andreas Schliep is a founding member and executive partner of DasScrumTeam. He is a Scrum coach and trainer. He studied at the technical university of Bremerhaven, and worked as a software developer, project manager, team lead and group lead. Andreas has worked with Scrum since 2003. He became a full-time Scrummer in 2006.
Since then, he has helped to introduce and improve Scrum and agile practices in numerous companies all over the world. His favorite topics are quality management and scaling.
- Experienced ScrumMaster, Product Owner, Coach and Trainer
- Introduced Scrum at WEB.DE
- Coaching of internationally distributed teams
- Transition from RUP to Scrum at UOL Brazil
- Scrum Trainings and Coaching in Germany, Switzerland and Austria
Immer informiert mit dem DasScrumTeam Newsletter
Das Beste in Sachen Scrum. Einmal im Monat. Jeden Monat.