SAFe, done properly

SAFe is increasing in popularity and more and more companies decide to go through an Agile transformation and decide they want to invest in the SAFe framework. We might consider various reasons for this. First of all the visuals of SAFe appeal to organisation structure with various levels of understanding scope and responsibilities, although it’s not – it’s not a hierarchy of organisation, but rather a set of tools. Second of all, SAFe with it’s Implementation Roadmap gives a recipe for Agile transformation – a set of steps to undergo, a path at the end of which you are suddenly Agile. Again this is not the right approach as it’s a journey and you need to prepare yourself for the troubles of it. Third of all, SAFe created a training capability like few others – a number of trainings, and once more – you do a training and suddenly you are Agile, or you are no longer a command and control manager, but rather a servant leader. After a three day learning? Really?

---

Unfortunately it is not that easy. I am a strong believer that SAFe done properly can fulfil the need of Scaled Agile. I recently joined an already existing Agile Release Train and would like to describe how we work there. It’s not perfect and it might never be, but we are learning and improving, which is the key. So let me tell you a story about an ART with a good SAFe implementation.

Team

I will start with a team, my Team to be ex­act. If you know Scrum then I would say – nothing will surprise you. We are a borderline large team with 9 people plus Product Own­er and myself, as Scrum Master. Few devel­opers, few testers, one IT analyst.

Are we cross-functional? I would say so, or at least the team tries to be. I’ve seen really good initiatives from within the team how to deal with certain bottle-necks con­cerning automation tests.

We’re working within 2 week sprints with regular sprint plannings, daily standups, re­finements, reviews and retrospectives. Those are built-in into the teams’ life.

What I love about this team is their collab­oration. Working online is a struggle and we can see that on our refinements for example, however on our daily stand-ups there are al­ways people that ask and receive help. There is space for this and that’s because of how this team and the entire ART, approaches their PI planning, but more on that later.

Ceremonies

Have you ever heard on your daily: “Yesterday we did some pair-programming with John and I learned a lot!”? Well, I have and I can tell you the feeling was awesome. Some might think that it was a waste of time, some other work could have been done instead. If so – they couldn’t be more wrong. This is what motivates the team, making it more efficient, collaborative and cross-functional, not to mention self-organising than anything I, as Scrum Master, could organise for them as, for example, a team building exercise.

The team plans according to their estimat­ed capacity and historical velocity. They chal­lenge themselves to be better, to do more or do something differently. Every week we go over the backlog and check if there is some­thing we should refine more, estimate or go over the Definition of Ready. Sometimes it’s the next sprint, sometimes it’s the next PI, but our Product Owner and IT Analyst take care that the team has things in place at least for the next sprint. We don’t go farther than a sprint or a sprint a half in much de­tail. Features for next PI are discussed and refined just enough so any questions can be answered before the PI planning (Fig. 2).

Finally the retrospectives. This is the best part of the sprint. The team is honest and gives feedback, they joke around, keep pos­itive energy going. “I’m sorry we were so si­lent on the refinement the other day. Don’t get this the wrong way – we just have to dig deeper on our own, before we start asking”. This sentence from one of the developers showed how mature they are. They had the courage to say, we did something wrong, here’s why, can we talk about how to make things better in the future? And this start­ed off a very concrete discussion about im­provements that were put in place to the teams’ Ways of Working (Fig. 3).

Why am I mentioning this at all? I was sup­posed to talk about SAFe and scaling. Well, teams are the foundation of an ART. Without everything working well enough on this level there is no point in scaling and other good practices will just fail at the core. If you have too big teams. If you are not fostering their self-organisation and cross-functionality. If you don’t have space for them to experiment, fail, learn and grow. SAFe will not work, you won’t do it properly.

ART

As I mentioned improvement is what drives a successful Agile implementation, it applies on every level, both Team and Train. Lead­ership needs have this mindset of setting a baseline and creating space for experimen­tation and driving excellence.

So every Program Increment (12 weeks for us) we have a sprint dedicated to Innovation and Planning (IP Sprint). When I joined the ART it was already going through a DevOps as­sessment and transformation. I approached my RTE with a simple idea – let’s do a SAFe DevOps workshop with the entire train. I ex­pected and prepared myself for a fight, to de­fend the idea, all I heard was “Awesome idea! How can I help?”

We approached the business and manage­ment with the idea of spending 2 days with the entire train on a training “slash” work­shop. Crazy? Not really. Of course, we had to explain “why”:

Once we had everyone on board with the idea, we engaged the Scrum Master Com­munity of Practice and organised the event. Fully online with 5 teams simultaneously creating their DevOps Canvas and brain­storming on improvements. After the session every idea was gathered, put into our back­log and prioritized against the Business Fea­tures (Fig. 4).

RTE, PM and management leadership

Their key role is not to manage, but to sup­port and lead. From the given example above of not dismissing an idea, or pointing out flaws in the plan, to some more examples of PM or Architect focusing on the team for several hours on the PI planning to answer any questions, because they couldn’t move forward with planning a feature.

The key to being successful on a non-Team role in the ART is being a servant-leader. You might have an oversight of a bigger picture, but it does not mean you are right. It does not mean you have the responsibility. Listen to people, act on or support their proposals, give feedback and appreciate feedback given (Fig. 5)

Customer Feedback Driven Development

This is not a thing, or least not called exactly that, but it definitely should be and this is what this ART does.

Every 2 weeks we have a demo to which different stakeholders and actual custom­ers are being invited. We gather their feed­back and incorporate that into our backlog. What’s more there is a Customer Feedback Board where the Feedback Stories are being created – these are smaller improvements that don’t exactly connect to any of the prioritized Business Features. The latter are also based on customer feedback of course, however they are recognized as larger initiatives that will be catered across multiple sprints or multiple teams.

Sometimes we try to find capacity while planning the PI and sprints, sometimes these smaller stories cannot be exactly planned, however the teams are taking care of them, whenever there is a spare capacity for this. Small items that can quickly move through the pipeline for which we received some really good feedback.

PI Planning

“There is no magic in SAFe… except maybe for PI Planning.”

Creators of SAFe

This is not a thing, or least not called exactly that, but it definitely should be and this is what this ART does.

As always – I fully agree with that state­ment. It was an amazing ceremony when it was physical with everyone being co-locat­ed. Nowadays, with having them virtual we have to manage with what we have, howev­er new tools, new improvements and Ways of Working are helping us very much.

I would like to revert back to what I men­tioned in the beginning and conclude with that – space. Space to experiment. Space to fail. Space to learn. Space to be better. Space to help each other. Space to have fun. Space to provide quality.

Without that there won’t be time for an­ything. You will always try to catch up. You will be slower and slower, because you hav­en’t fixed or improved that issue that is im­peding your progress. You will build on your technical debt, because there will never be the time to go back and change. The pres­sure of delivery will suffocate the teams and discourage them to speak up, to have any initiative of their own.

Your PI planning can be the time where you have to create that space. It’s your respon­sibility, regardless of your role, to speak up. I recently heard a question: “Should we stop delivering this feature and focus on fixing the Continuous Delivery Pipeline?” I sensed that the question was uncomfortable, but no­body shied away and the decision was that this is exactly what we should do.

Agile is all about flexibility, improvement and customer collaboration. And so is SAFe, done properly. All you need to do, and it couldn’t be harder unfortunately, is not to forget the basics.