We would like to share with you a few tips on the journey of implementing Scaled Agile Framework (SAFe). Based on our experience there are a few things to watch out for when starting up your first scaled teams’ setup, your first Agile Release Train and then when it is already running full steam ahead. There are many things that can go wrong and the only thing you could be sure of is that some of them will absolutely arise sooner or later. The main thing is for you to be prepared for the worst-case scenario. If you won’t have it – lucky you! If you will face it, you can immediately react.
We would like to prepare you for some of the most common situations that you could avoid, at least partially.
First lesson of scaling – don’t scale
Tip #1 – Don’t scale unless you absolutely have to. Scaling adds complexity and makes delivery that much harder. You have to think upfront about large architecture, far-ahead looking roadmap, long-term budgets and stakeholder management. So instead of thinking about value you manage all of the above. There’s a concept called “Do things that don’t scale” introduced by Paul Graham which mostly applies to startups, but there are some good ideas on how to approach product delivery in general.
If you’ve come to a conclusion, after significant consideration, and you still feel that there is the need to scale, even then… start small.
Tip #2 – Start with one team, create value, evaluate and move forward. It’s always easier to define what is the next smallest step that you need to take, the next smallest business value to create, to check if you are going in the right direction when you have a small agile team. Experiment with one. Learn, improve and repeat. Once this team and you feel that they are ready (as much as any team can be as this is an improvement journey that might never end) start adding more teams. It’s generally a bad idea to mix the “old” and “new” team as you have spent a considerable amount of time to make the first team as high-performing as they can be at this stage and you don’t want to disturb that. Rather try making the new team learn from the old one, have them observe ceremonies, engage a bit in the life of the team, and then once they learned enough start a new team and new team members learn and start improving together.
The better you will prepare for starting your scaling journey, the more likely you will face less challenges on your journey. Key things which you should pay special attention to we will cover in this part of the article.
Tip #3 – Focus on backlog preparation and prioritization. There is nothing worse than ongoing meetings about requirements while you should already deliver the value. Make sure you reserve time for continuous backlog preparations. Make regular refinements and engage key business stakeholders that can answer your teams’ questions. For your first PI Planning verify if the top 10 features are really ready, definition of ready should be met if you want teams to gain first successes and deliver meaningful features. Before PI Planning, we highly recommend running a few backlog readiness sessions, so that we can prepare well enough to kick off the start of our Agile Release Train (ART).
What’s even more important is the time dedicated to preparing backlog for the next Program Increment (PI). The bigger ART you have, the earlier enough you should start preparing for the next iterations. There is no golden rule for how much time you need and when you start, you need to find your own way. One thing we can tell you is that, for sure time spent only during IP Iteration for backlog preps won’t be enough and it’s super risky to leave it for the end of PI. You can decide on some rules that may be a hint for people how to prepare well with backlog items, eg. in each iteration all Product Owners Product Managers, Analysts and Business Owners spend at least 15-20% of their time on backlog creation for upcoming PI and each team has minimum 2 hours of refinement in every sprint.
Tip #4 – Well prepared PI planning makes all the difference. Besides the backlog that is essential, you need to also make sure that Business Owners and Product Management are ready with ART vision & mission. It would be also great, if possible, to have an up to date Product Roadmap for at least next 3-4 PIs.
For good PI planning we also need to make sure all facilities are in place, no matter if we do the event online or physically, we should prepare them in advance. You can do a simple Kanban board with a to do list for PI planning and assign tasks to respective people. A few days before verify if all we need is done and ready. Last minute preparations may ruin your PI planning and people may be lost or stuck in unnecessary work.
Tip #5 – Agree who is who and how your calendar will look. Verify the roles and responsibilities with the people. Make sure the expectations are clear, and roles are defined. If you wish to receive some regular reports, agree on format, frequency and who is accountable for it. You can avoid misunderstandings and some conflicts if you do it properly. In some organizations we noticed something called a role card for people so that we knew what is required from us. Each and every project or product we deliver is different and it’s good to verify if we have all needed people with competencies and skills required. If not, we know who to look for.
SAFe is rather tough to implement, especially if we look at the number of the meetings whole ART and teams within it need to run. The complication could be even bigger if we have some people holding one role in more than one team. This could be mitigated if we decide to create our own ART calendar, where we communicate when teams have time for their ceremonies, such as Iteration Planning, Retrospective or Daily Stand-up. Those should be sacred hours, which no one else can book for other calls.
Train everyone, launch Trains
Tip #6 – Make it official. SAFe’s training sessions obviously go through theory of what the ideas, values, processes and ways of working will be when SAFe is in place. They make sure that all people on the teams now have the same level of understanding of what is going to happen. Their experience with working with agile methodologies might be different, however now they have the same naming for things and will be less confused when someone starts talking about sprints, story points and transparency. However having all people trained sets a milestone in everybody’s minds that this is it, now we have started – makes it official. Now we have standards to uphold to, both teams and leadership will be held accountable to those standards.
Very good approach to starting your first Agile Release Trains is to go ahead with the training. SAFe for Teams done for the whole group of people right before their first PI planning gives them a chance to learn first, experience in a safe manner the tools and practices, and then move forward to the actual practical implementation of the process.
Tip #7 – Create communities. Experience of a group is always greater than that of an individual. When we enter the mode of being a mentor for a person it is because we, or that person, feel that our experience is bigger and we can help that person by providing answers and proposing solutions. However, if there’s a group of people to be mentored, then we can safely assume that either they can share experiences with each other or they can come up with a solution they would experiment with. That builds true autonomy and helps achieve another level of teamwork.
In SAFe we have communities of practice (CoP) that help achieve what was described above. The first and usually most active community of practice would be that of Agile practitioners – Release Train Engineer, Scrum Masters, Agile Coaches, SAFe Programme Consultants. If this group of active people with good energy is working, then you can start creating with their help other communities i.e. for developers, testers or product management. Make sure those sessions will be regular and active, that will help everyone to grow.
For the results you need to wait. The biggest advice we can provide you with is to be patient, make sure you have stabilized teams, clear mission and vision and good process in place which you stick to and improve continuously.
Tip #8 – Don’t make revolutionary changes every PI or whenever you face challenges. ART should be a long-living team by definition. You may not avoid people leaving or simply changing roles as they want to grow. However, you can try to prepare for it. Create a safe and motivating environment, think in a long-term perspective about people and their growth, give them opportunities that will make them happy and satisfied. There are many ways of keeping people and boosting their motivation, sometimes listening to them and letting them do the work in a way they want can be enough.
SAFe in its name has a very meaningful word: FRAMEWORK. Make sure you stick to an agreed frame of your ways of working and adjust them if required. Doing agile doesn’t mean you can just change some of the critical aspects, which are essential for the rythm and execution. We witnessed a couple of situations when teams are moving dates of some main ceremonies, such as PI planning moved by a few weeks, please watch out and make sure you don’t do it. That kind of approach will not introduce the operating rhythm which is really required for the teams to work in regular intervals and be able to deliver and compare results from PI to PI. Another big framework related change is the length of PI. It should always be the same. Adding iterations when we do not deliver as expected is not a solution. If we allow this, our predictability measurements and other metrics, when we want to compare if we are getting better, will never be correct. Another thing is that we should aim at closer to 100% delivery and keeping our promises by other improvements within teams that will let us not repeat mistakes we have made earlier.
Keep calm and be agile
Believe us, you won’t avoid tough situations, but you really can prepare yourself for at least some of them. The more mature you and your team will be, the easier it will become. At the same time you should see more and more successful deliverables coming on time and within good quality. Isn’t it the thing you dream about? If yes, try some of our tips, apply yours, retrospect regularly, talk with your teams and be agile.
[ENG] Leader, Agile ways of working enthusiast. Has over 10 years experience with multicultural teams. Support teams achieving their goals, delivering projects and solutions that are focused on meeting clients needs. People doing the work are priority number one for her and she does her best motivating and empowering them. PMP® & SAFe SPC® certified, trainer and designer of interactive workshop. In her free time, passionate of active forms of leisure, crime stories, baking and cooking.
[PL] Liderka, pasjonatka zwinnej pracy projektowej. Posiada ponad 10-letnie doświadczenie w pracy w zespołach wielokulturowych. Wspiera zespoły w osiąganiu celi i dostarczaniu projektów lub rozwiązań, które spełniają oczekiwania klienta. Wierzy, że w pracy na pierwszym miejscu są ludzie i to ich wspiera w dotarciu do celu. Projektuje gry i interaktywne warsztaty szkoleniowe. Akredytowany trener PMP® oraz SAFe SPC®. W wolnym czasie fanka aktywnego wypoczynku, kryminałów, pieczenia i gotowania.
Agile Coach in Deloitte with over 10 years of hands-on Scrum Master and RTE experience. Started as C# programmer and later Dev-Ops. Now specializing in working with distributed, smaller, Scrum teams, and larger, scaled, SAFe setups. Involved in multiple agile transformation programmes, including one of the biggest in Europe – Nordea’s Core Banking Platform. Passionate about drones, archery and diving.