A dedicated sprint only for Innovation and Planning – no way, that’s too expensive

Can you imagine that every 8-12 weeks your teams stops working on the MVP of deveoped product and spend another two weeks only on innovations and further planning? If you can’t at all or you believe this is way too expensive for your organization this is an article for you. Sit calmly and let us introduce you to the concept of IP Sprint, and its main benefits. We would like to share with you some best practices as well as tips and tricks from our own experience.

---

What is IP Sprint?

IP sprint stands for Innovation and Planning sprint which is part of the framework of SAFe® (Scaled Agile Framework). Before we dive into that specific topic let’s bring closer a few important terms and rules of SAFe®.

We need to synchronise with other teams every Program Increment (PI), which typically is four to six sprints long. We all meet… (We would like to pause here for a brief moment – face to face communication is crucial to Agile development: Agile Principle #6 says: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. However current times and COVID-19 outbreak will change our understanding of the world in many aspects, one of which is face to face communication. The investment numerous companies are now doing into enabling us to work remotely and virtually will have an immense impact on that).

…and align ourselves into the same direction and goal for our product. We do that by recognizing the priorities, dependencies and creating goals taking into account the future capacity and historical velocity for the upcoming Sprints. If our PI is five sprints long we consider and create plans for the next four.

Wait… what just happened? 4 sprints out of 5? Yes, everything is ok, maths is correct. And we now delve into a magical fifth Sprint which is the IP sprint.

For Innovation – this is the time where the teams figure out how can we improve our Product through new technologies, gaining on technical debt, work on something else then MVP, maybe at the same time – fun? For Planning – this is the time where we look back and see how previous PI went, what could we have done better and improve and prepare ourselves for the upcoming PI planning.

Why do we need it?

The answer to this question is quite simple – without innovation you die. On the market, against your competitors, of course. It’s important to add new features, new value to our product, but it’s also equally important to add the less obvious value. To make our product faster, maybe more secure, maybe add that extra pinch of flavour by making your app actually NOT to crash every now and then in very mystical circumstances.

It’s hard to get that time unfortunately as few people really understand what will be the consequences. Most projects have strict deadlines and people who have committed to deliver a product against those timelines. These are their KPIs – to deliver on time, on budget, within agreed scope. And that Ladies and Gentlemen is extremely short-sighted and proves that we don’t learn.

That’s why if you truly want to see into the future and deliver what your customer needs, to implement SAFe®, you need to embrace the Relentless Improvement aspect of the framework and have the IP sprint. The way it is suggested by SAFe® is probably good enough and the only thing you need to do, to succeed, is to follow the practices and suggested approach.

Reflect on the past. You also want to regularly check and know if the whole solution build makes sense and you act on the feedback received from your customers. When working on big, complex products with multiple teams you want to show what was achieved in the last couple of iterations and check if it brings expected value and desired outcome.

Check the trends and metrics. The IP sprint is also for showing how we are progressing as an ART (Agile Release Train), which usually consist of 50-125 people. Release Train Engineer (RTE) together with Scrum Masters collects the metrics and presents them to teams and stakeholders to show what is current situation, how predictable we are and if we constantly improve or are stable with our deliverables.

Lack of IP sprint

No time for checking out new technologies – remember that the world outside of the project is evolving. You are delivering value to your customer, but you are also a customer for someone and they bring value to you. New libraries, new frameworks, new automations, AIs, new processes that open up new paths for your product development. If you won’t use them your competitors might.

No time for technical debt – technical debt is almost as entropia, always growing. Fortunately you can, and want, to do something about it. Negotiate with your business how much time you can spend during the PI on working on technical debt, and depending on these negotiations, at the very least carve out a portion of the IP sprint to work on it.

No slack time – with SAFe® we are building high-performing self-organising and cross-functional teams. Sounds like a Superman and to us – they are, but even Superman needs to be Clark Kent from time to time. A lot of people understand slack time as coffee time, and while you might think – “let’s brainstorm on this design over coffee”, some might think “let’s lay on the couch and do nothing… over coffee”. The second one is obviously wrong and this isn’t what the IP sprint is for. The time is to reset our brains and try to creatively think of some other problems, learn and grow. This helps the team to not burn out and be a long living entity, be the heroes we need.

Low morale and motivation – out of the lack of slack time you will find that people are less motivated as well. What we, as leaders, need to bring out is the intrinsic motivation of knowledge workers (SAFe® Principle #8) which comes out of: Mastery, Autonomy & Purpose. I might be oversimplifying, but you can fulfill those three with innovation, hackathon and Solution Demo, respectively.

No time to prepare for PI planning – all RTEs know preparations for the next PI planning probably start already after previous one finishes, however there are some actions that need to be taken directly before the actual event:

• double check Prioritisation and Backlog Elaboration is in good enough shape,
• printouts or Jira dashboards are in place,
• post-its, duct tape, brown paper, markers and other necessary materials are in sufficient quantity or means to create and visualise the solution board virtually,
• rules of the game are aligned and agreed with Scrum Masters & teams.

No reflection and no improvements – during this time you want to do an ART-wide retrospective, problem-solving workshops, add to backlog, items and actions, that cannot be fixed on team level. Please note that IP sprint doesn’t mean that in regular sprint during PI execution teams don’t have their own regular retrospectives. IP Sprint is the time to retrospect with whole ART.

All of the above are part of the IP Sprint – this is something you want, and need, to have if you work in scaled agile approach. It’s never a waste of money and time, it’s totally opposite. This is a great opportunity for you, your teams and your product. It’s time to brainstorm new ideas, focus on new solutions, prepare properly for next Program Increment. Doing Innovation & Planning iteration will allow you to become even more successful.

How to run a successful IP sprint?

At the end of the article you will find a calendar card template suggested by SAFe®. You do not have to follow it exactly as it states, but some of the events are mandatory and it’s worth to make sure you would have them planned and executed during IP iteration. We would like to share with you some of the ones which are the key ones based on our opinions and experience and provide some tips how to run these.

Hackathons

One of the events you might find interesting to run during your IP sprint is Hackathon. Every employee-friendly IT company is advertising how many hackathons they are running, it’s trendy. There’s nothing wrong with that. It’s fun and it’s fruitful for organizations as well as individual employees.

Usually hackathons are run over 24h where programmers work on some idea they have. It might be connected to your product or your continuous delivery. For example checking out new programming frameworks or metric platform. In other cases these might include automating a process that we never had the time to do.

Within SAFe® framework I believe we want to get out of the boundaries of having that event for programmers only as everybody else will feel excluded and our purpose is to unite people, create a tribe. For that reason, when we run this event, it is always for all the people on the programme – IT and business alike, for developers, testers, agile coaches, Product Owners and Product Managers, business and IT analysts, architects, managers – the whole lot. And people come up with some cool ideas and useful stuff from cleaning out the post-it cupboard to new ways of working with requirements to automatization frameworks. Every idea is valuable, each person participating is appreciated.

Some practicalities:

1. Make sure the event is advertised well in advance, depending on the scale of your train it will be easier or harder to get to everyone.
2. Engage your Agile Community of Practice to encourage and engage everyone else to participate.
3. Gather ideas beforehand, make them visible, create space for people to collaborate on someone else’s idea if they don’t have their own this time.
4. Make sure the participants are not disturbed over 24h (if they choose they can work on the idea overnight!).
5. Make it fun and structured – opening ceremony, food and drinks if ran locally, “Pizza Party”, evening beer, prizes for the most funniest presentations, etc.
6. Last fundamental rule – everyone demos at the end of the event.

Inspect and Adapt Workshop

We cannot imagine proper Program Increment without Inspect and Adapt Workshop. Timeboxed session that should last minimum half of the day and should consist of three parts: System Demo (a separate chapter below), Quantitative and Qualitative Measurements and Retrospective and Problem Solving workshop.

After a System demo is being held, we should gather feedback and our Business Owners should assess what actual business value was delivered versus the one which we planned for already passing Program Increment, as it is being shown on the Figure 2. That would be a key input for a quantitative and qualitative measurement, as thanks to this, we would be able to create our ART predictability metric and show the trend, looking as well at previous PIs. Besides this one, we also present data we collected throughout the PI and present them how overall we worked in passing increment. Ideally, if those are metrics which we all agreed with the teams that we want to see and based on those parameters we want to measure our progress and checkout the trends.

We can look at number of features delivered successfully vs the one planned, number of defects, teams velocity, % of teams deliverables per sprint vs their commitment, etc. While presenting measurements we also should reserve some time for reflecting upon them, have some space for people to ask questions, share comments or explain what stands behind the numbers, especially when we see some significant improvements or drops. Numbers and metrics can be powerful, but we need to remember about extra commentaries who would be supportive and make sure that we all are on the same page.

The next step is to have a retrospective of the whole ART, it is similar to the ceremony that teams at the end of every sprint, but as we talk about scaled approach – here it’s a time where all teams are together in one place and share what went well and what could be improved from the whole ART perspective looking at the whole passing program increment. It is also a time for sharing what we are proud of and whom we would like to thank using the opportunity that we gathered altogether and ideally have all team members with us.

Crucial output of the retrospective should be a list of most burning challenges to be solved. That we would need for the third part of Inspect and Adapt session, which is so called Problem Solving Workshop. It consists of six steps and is a powerful tool to make sure we improve and work on resolving the biggest and most critical issues that we face.

As it is being shown on the Figure 3. we start with agreeing which problem we want to solve. If we are a big ART we may decide to take more than one issue and divide people into smaller groups so that we can actually improve in more than one area. We may also consider another approach of facilitating the session by choosing one problem and still have different teams and at the end try to combine action items based on different groups outputs. Before staring we may decide what approach we would choose and how we are going to facilitate the session. RTE together with Scrum Masters may be here more creative and decide based on where the event happened (face to face, virtual meeting) and how big it is by looking at the size of the ART (in bigger ARTs one, huge session may not allow many to participate actively).

Properly phrased problems to solve would be already a huge success, make sure that you practice a bit earlier with some of the people, especially Scrum Masters who should coach and help with naming the true problems. Once decided we move to the root-cause analysis. Good way to do it is an Ishikawa diagram (aka fishbone diagram). The most often seen behaviour with doing it is the fact that people have a tendency jumping straight to solutions. Make sure while facilitating that this is avoided and firstly we focus on the question: “Why is it so?, Why it is happening?”. After this part teams vote for the biggest root-causes so that we can create a Pareto diagram that would show us what is actually the biggest one. Having that we can restate the problem to solve including the biggest root-cause.

With the restated problem we can finally move to brainstorming part and start creating a list of potential solutions. Remember that proper brainstorming means we do not look only at the obvious resolutions, but we can be creative and think about all possible ways of resolving the problem, even if they seem to be not possible, funny or weird. All ideas matters and sometimes it happens that the one which was at the beginning even unrealistic can turned to a winning one after some further discussion. This step we finish with choosing (most often by voting) the best ones and these we would change into improvement backlog items that we take to next PI to do as part of our continuous improvement journey.

PI System Demo

System Demo is a culmination of your PI. You need to invite every stakeholder for sure, but inviting everyone is far better option. Broadcast the event as largely as possible, so that everyone sees how awesome your product is. This gives a chance for the teams to shine brightly, be proud of their accomplishments. Make sure that it would be a moment of celebration of your teams’ achievements.

Proper System Demo should be also advertised in advance. Besides ordinary Outlook invitation you may think about some nice posters that you will hang in the office space you work in. Make sure you have agenda in place and you plan it properly and stick to agreed timebox. Let your teams be creative in the way they present, role-playing or some funny scenarios that they would show. In order to avoid any issues with the accesses you may also prepare a backup plan and record sessions just in advance. In case something will not work, you can always play previously recorded session. Trust me, you may need it sooner than you think. And you really do not want to fail with demoing when stakeholders appeared to your session. Some of them have really busy calendars and rescheduling is not always so easy.

PI Planning & preparations

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

Scaled Agile Framework

PI planning is an immense event with a lot of going on. As mentioned before the purpose of this is to align ourselves towards the same goal. Teams discuss and try to resolve dependencies between them. It is pure chaos and yet it creates structure and understanding. The output of this event is a high level plan for the next Program Increment with the business goals towards which teams commit to. As the PI planning session is a huge event and it requires special attention more about it we would cover in the next article together with the tips for proper preparations for this session.

Do you need SAFe for it?

Definitely not. This is not about SAFe, it is about innovation. Answer yourself a question – do I want to invest in creating a legacy system? Probably not, so you need to keep up with the outside world. Realising electric bikes, while everyone is roaming in flying cars will not bring any value. Realization of importance of innovation is paramount to product development, be it IT or otherwise. You can implement it how SAFe does (Figure 5) or however it is best for your situation, but do so immediately. Trust us, it will bring long term benefits for all and it’s worth every single minute invested in having it.