Catch Up, Clean Up, & Move Up!

Mitch Malloy
Mitch Malloy

The Scaled Agile Framework (SAFe) recommends an Innovation & Planning Iteration, often called the IP Sprint. The practice isn’t completely unique to SAFe, but it’s an important part of the framework. The IP Sprint is when planning and preparations for the upcoming Program Increment (PI) occurs, and it helps build predictability for PI commitments serving as an estimation buffer for anything that had to spill over. Once a team’s PI commitments have been met, the IP Sprint is a great time to see some extra magic emerge. Instead of just delivering the value that others have envisioned, teams are empowered to build the value that they’ve envisioned.

It’s a great practice, but as important to SAFe as the IP Sprint is, I still hear some common questions and misconceptions. So I’ve put together the following FAQs.

How can we trust the teams to use this time wisely?

This question indicates a lack of trust in either the character or the capabilities of the team members. I hear this so often, and in my more brazen moments I respond directly: “Why would you hire people that you don’t trust?” Although said with a smile, it points to the root issue. In this situation, I believe the best way to build trust is to become vulnerable and extend some trust: give the teams a chance to prove they are the competent professionals we thought we hired. I have yet to be disappointed in how teams steward this responsibility. Often, they choose to do something that is very much needed and would otherwise remain hidden until it became a problem.

Isn’t this just supposed to be a tech sprint?

It’s not a tech or engineering sprint; it’s an Innovation and Planning (IP) sprint. It is when both the Inspect & Adapt (I&A) and PI Planning occurs. It serves as a buffer for teams that have not already met their PI Commitment and helps build predictability in the PI Objectives. Assuming teams can meet their commitment prior to the IP Sprint, the developers pick activities that they believe will add value.

Does the Product Owner need to be involved in the IP Sprint?

Why wouldn’t they be? Do you want them to feel like they are part of the team? What are some ways that they can enhance the IP Sprint by their participation while also (1) maintaining focus on the finishing the PI well and (2) preparing for the next PI? SMs, POs and Dev Teams should talk to make sure everyone’s voice is heard on how to approach the IP Sprint and make the best use of this time.

Do we need to do all that “Scrum Stuff” during the IP Sprint?

Why would you NOT use the same rigor? There may be a reason, but for teams new to SAFe (e.g. – Agile Team has been practicing SAFe for less than 3 PIs) I don’t recommend trying something new; seek to improve upon the ScrumXP or Kanban practices already being applied. There may be good reasons for more mature teams to try something different. However, they will still want to apply an empirical rigor to what they attempt in the IP Sprint: enter the Iteration with a hypothesis for what will happen if you do something differently, then evaluate that hypothesis in the retrospective and determine how to respond.

What do teams do differently during this sprint from any other iteration?

Developers may choose to refactor code, develop the next killer app for their company, remove tech debt, or explore a new way of doing something.

It can be a good time to upgrade skills with formal training, exploration enablers and process improvements. For example, the team may want to take an innovative idea and implement it while experimenting with mob programming. Or maybe it’s a good opportunity to build T-shaped skills within the team.

How Can the Team Use the IP Sprint to Upgrade Skills?

Continue to apply the same rigor in the IP Sprint as with any other Sprint. Be sure to understand the value of the activity and use clear acceptance criteria that creates something demonstrable. You can’t demonstrate that you’ve read 5 chapters in a book, but you can tie the knowledge to something concrete. For example, you could present the applicability of a technology or practice for future initiatives. You could also prototype using a new language or tech stack, or you could summarize findings in a white paper. Product Owners should help the teams develop User Stories that explain the value of what they are doing. Scrum Masters should challenge the team to make it tangible / demonstrable / practical — and not just an abstract exercise.

What else should the team consider?

  • Teams will want to adjust their Sprint commitment to adjust for the additional Program Level ceremonies.
  • Developers should write stories that describe what they want to accomplish (User Story Voice including value statement and clear acceptance criteria), and they should approach it with the same level of rigor as any other iteration, including the communication of IP Sprint accomplishments. Otherwise the perception will grow that the IP Sprint is a non-productive period.
  • Consider how and when to communicate the accomplishments of the IP Sprint. Even better, consider how to celebrate the accomplishments and leverage the innovations so it never feels like throw-away work.

Ultimately the IP Sprint is a time to catch up, clean up and move up. Do it well and leadership won’t question why you’re doing it. Instead, they’ll wonder how they ever survived a rapidly changing business environment without an Innovation and Planning Iteration.

The Scrumban Spectrum

Scrumban Spectrum
Mitch Malloy
Mitch Malloy

I read article on Scrumban that caused me to look more closely. The author advocated implementing every aspect of Scrum when standing up any Scrumban team. In that author’s opinion all three roles and all four ceremonies of Scrum were needed if a team used Scrumban. Scrum is a widely accepted and (mostly) understood Agile practice so it makes sense that people will gravitate to what they know and lean upon practices that they both understand and feel comfortable with.

However, as Agilists we should always be pushing the envelope of what’s known and experiment with techniques that can help us relentlessly improve. Looking at the 6 practices of Kanban, we can see many aspects of Kanban that have already made their way into common Scrum practices:

  • Visualize Workflow
  • Limit Work-in-Progress (WIP)
  • Measure and Manage Flow
  • Make Process Policies Explicit
  • Implement Feedback Loops
  • Improve Collaboratively (Using Models/Scientific Method)

The Scrum board imitates a Kanban board and helps teams visualize the workflow, often with WIP limits so that teams can optimize the flow. The Review and Retrospectives create a mechanism for timely feedback. Many Scrum practices find their origin from the Lean processes that birthed Kanban. So implementing all the roles and events of Scrum and calling it Scrumban in my mind says you just want to merge the two more.

But when I consider the values and principles of the Agile manifesto, I tend to go a different direction. Think of processes and tools the way we think of documentation and product: what is the minimum that’s necessary to deliver the desired value. Keep the processes lightweight and implement the minimum practices needed to achieve the desired result, adjusting as necessary with each iteration. Understanding all the Lean and Agile tools that are available is good but trying to implement them all in tandem without a clear need is not something I would recommend.

I think of Kanban as a tool that can be used in a more responsive fashion than Scrum, where classes of service are understood and continuous flow is desired. Scrum techniques can be applied where the class of service is less defined and timboxes applied to keep focus and to adjust course in small increments. Some teams deal with challenges that neither tool by itself is fully prepared to address, so they blend the two in order to strike the right balance between the Scrum and Kanban.

Rather than trying to implement everything, I suggest trying to implement the minimum that is needed with a hypothesis for how the techniques that will deliver results for the team. Then assess the outcome in a planned retrospective where the team can further tweak and hypothesize their practices. In this fashion, a team may discover that they really have a new class of service and no need for the other Scrum structure. Likewise, they could also find out that they do in fact need all the overhead of Scrum with a mechanism for addressing ad hoc requests. More likely, they will simply land at a lightweight set of practices that wouldn’t work for any other team but optimizes the value delivery for them using a blend of Scrum and Kanban.

In short, think of Scrumban as Spectrum that may lean toward Scrum or Kanban, borrowing practices from both. Every Scrumban team will find themselves somewhere along the spectrum, and the really nimble Scrumban team will adjust where they are on that spectrum to meet their evolving needs.  

I’d like to hear your thoughts or experiences with this. Reach out to me either through with website or via my LinkedIN profile.