Acting as the Scrum Master for a financial content publisher of the digital product team, we were set up to run on a monthly Sprint to match our major release timeline. We practiced the traditional Scrum ceremonies to the book for the most part. When we groomed our product backlogs and planned our Sprints, we were treating the time-boxed Sprint like a project, in that it had a defined scope of work which maxed out every team member to their capacity which we didn’t want to add to because heaven forbid our burn-down chart would look off.

I was so focused on making the metrics of achieving higher team performance look better and better Sprint over Sprint that I failed to realize that this was an unnecessary self-imposed constraint that wasn’t really adding value. The problem with treating the Sprint as a “Waterfall” project in and of itself is that it didn’t allow for the agility that the team needed. A Waterfall methodology is where a project is pre-planned and doesn’t provide the flexibility to pivot due to changes in terms of size, costs and timeline (triple constraints). Waterfall approaches are more commonly used in familiar projects that have been executed before, such as manufacturing or construction where the triple constraints are more fixed.

To paint the picture for you, I will share my story. One of my product managers who was beholden to the whims of the product owner was having difficulty planning a whole month of work in advance. When she did fill the Sprint, half of the work ended up getting cancelled or pushed back for later in the year as new priorities surfaced and took precedence. The scope of the Sprint was constantly changing and the burn-down chart looked terrible. It wasn’t until we sat down to have one of our backlog grooming meetings that she told me that she literally could not schedule anything because she had no idea of what new project was next in the pipeline as decisions were still in the process of being made. This made me realize that we needed to be more agile. But how? We were already following an Agile methodology; how much more agile could we get?

I had heard of Kanban in my studies of Lean Six Sigma, which is at the furthest end of the project management methodology spectrum, with Waterfall being on the other end. Kanban is where you plan as you go on a day by day basis. My challenge with switching over to the Kanban model was that I didn’t see how I could maximize team members’ capacities if there was no time box around the work to calculate against.

This is when I realized that focusing on “Work-In-Progress” or “WIP,” an idea that meshes nicely with Kanban, rather than worker’s capacities would allow me to still maximize a team member’s time. As a general best practice, you want your team members to be working on 1 thing at a time. The reason being is that it allows you to deliver items faster to market. When you are working on more than one work item at a time, there is wasted energy switching back and forth between them. Even when one item is blocked, it is a better use of your time to help facilitate getting the item unblocked so you can continue working on it. Knowing the benefits, I implemented this policy with my team. When team members gave time estimates on their current work in progress and logged time against it, I could easily see how busy they were and how close they were to wrapping up a deliverable so that I could ensure that they had another assignment lined up ready to go.

Working in a WIP focused environment forced me to do more day to day management, but the trade-off was well worth it. The reason being, when I planned everything a month in advance with the team, 1) It would take the team away from their work for a large chunk of time, which was not ideal, and the expense of those large meetings became very obvious and 2) Once everything was planned, I would disengage for a month with my team’s work as I worked on other projects which was not ideal either. By changing to this style of work it keeps me engaged as a manager with my team, let’s me to know what’s going on much more intimately, allows me to have more communication touch points and most importantly allows for re-prioritization as it’s called for.

Now, instead, of facilitating a Scrum process, what we do is more of a Scrum-Ban approach, where we plan as much in advance as possible for a targeted release date and then add in other work items as we go. The work is still time-boxed, but using the WIP approach allows me to still maximize my team’s performance. When it comes time to look at the burn-down chart, all I really need to look for is when the work line stays static. If it goes up (meaning more work was added to the Sprint), that’s fine and expected. As long as the work line continues to burn downwards then my team is performing.

In conclusion, I recommend to not treat a Sprint with a waterfall mindset and use Scrum-Ban to bridge the agility challenge of Scrum, yet still commit to longer term projects. Using the WIP approach in conjunction with Scrum-Ban will also help to maximize your team’s performance as well as be a more engaged manager.