Why a wedding cake, of all possible comparisons? Well, most of you have been to a wedding and I am sure you know what a cake at one of these usually looks like: it is large enough to be shared by a lot of people, it is finely detailed and has to be prepared right on time. And it has many layers. And it had better be tasty.
Baking is similar to product increment
Making a wedding cake is quite a challenge for a confectionery team. They have to be well prepared, have a plan and synchronize their work to deliver. A pastry chef friend of mine once said that a good wedding cake is created many days before the wedding. First you need to have an idea, then you have to think the process through, and finally you must spring into action and put it all together.
The same is true for IT projects. A successful completion of an IT project requires planning, sharing responsibilities, implementation and, above all, teamwork. Plus, if the project is large and complex — like a wedding cake — your team needs SAFe — Scaled Agile Framework (you are probably familiar with it, but it is a system of workflows, a repository of knowledge, a combination of several tools, such as Scrum, XP, Kanban, and Lean. Added to this is the Kaizen philosophy. Find out more here). After all, that’s what the methodology was created for (large-scale delivery, not baking).
The theoretical assumptions of the scaled agile methodology are quite widely known, and learning them, even though challenging, is not the hardest thing IT experts have to do. But the first encounter with SAFe can bring a lot of surprises for someone who has not dealt with it before.
Confusing even for a SCRUM veteran
I first encountered SAFe a few months ago. I was involved in a project that enabled one of the global pharmaceutical leaders to develop an efficient COVID-19 vaccine production process. Having worked before with a large (Forbes 500) Life Science client, I had experienced first-hand not only the benefits of working in this methodology, but also realized the importance of preparing for the project at hand.
I had experience with agile project development, but not with Scaled Agile. I vividly remember my first steps on a large project in SAFe, and there’s no denying that I was a bit lost at first. Looking back on these couple of months, I can draw one conclusion that I want to share, because it might be valuable for someone who is just getting started with SAFe.
If you start well, you have nothing to fear. What’s more, you will quickly appreciate it.
What does it mean to “start well”?
- The most important thing is to work out an onboarding manual in such a way that it can be easily shared and adopted. It should be a document that can be changed, updated.
- Forward thinking is very important. It is better to anticipate and prevent problems than to solve them.
- The onboarding manual is a must read for everyone! Don’t start work on the project until everyone has familiarized themselves with it (even though I know this is against the very nature of many programmers).
In our project we have multiple work streams working at the same time on different products which are closely interconnected and interdependent — Source Systems, Common Data Repository, Reporting and Analytical Layers, ML and AI solutions. The client’s expectation is that each of these teams should deliver value in increments.
My team is responsible for the Common Data Repository. Our product development cycle consists of several main stages as part of the philosophy of continuous delivery and improvement:
Just a reminder: it deals with a vaccine for a dangerous disease that threatened millions. Thus, we had only 4 weeks to prepare for the first PI planning. We were also asked to deliver a team of 30 experienced experts. What is more, we needed to be aware that our team could scale up or down in the future, and people would migrate between projects.
In an ideal scenario, we should have prepared the onboarding manual before starting the project. But in this case, we wrote it in the very beginning of the venture. The work put into onboarding document paid off, because otherwise the implementation would have taken about a month.
Ideal onboarding manual
It should be:
- Prepared before the project begins, or at an early stage of the project. This saves a lot of time in the onboarding process.
- Frequently updated.
- Focused on the broad perspective. It is useful to prepare an onboarding manual that will be the basis for future projects.
- Easy to read. It is important to use simple, understandable language. Avoid ambiguity, this is supposed to be a manual compregensible for every member of the new project.
What should the ideal manual consist of?
- A list of useful contacts,
- A list of essential applications and tools,
- A manual for, and list of access credentials, Internal training information (as in many large companies internal training is required at the beginning),
- Description of established project standards, i.e., database object naming convention, ETL object naming standards, etc.
- Description of development life cycle,
- Basic instructions on how the online calendar should be used (for example. how to announce OOO — “Out of Office” in the calendar),
- Introductory meetings and workshops, recorded and attached to the onboarding manual,
- And probably a lot more useful information,
Wedding cake — reception day
As the vaccine project has shown, SAFe is effective when working on large projects and when there’s a lot of time pressure. If you want to know more about the SAFe methodology, its work organization, roles and ceremonies, read the article by Dariusz Wojtas, my colleague from C&F who is a certified SAFe expert: CLICK