Monthly Archives: March 2015

Improvement kata to implement change

The principles of the Improvement Kata can be a powerful and effective way to implement any change, including the implementation of Super7 Operations.

The Toyota Improvement Kata, or Lean Kata, is a powerful and proven method for solving problems and driving continuous improvement. And, it can also be applied to implement the change from classical operations to an agile way of working. Recently, I’ve applied the improvement kata for implementing Super7 Operations in an operational back-office.

The Toyota Improvement Kata, or Lean Kata, starts with having a vision. Some companies use the term “Our definition of awesome” for this. Others use policy deployment or Hoshin Kanri to translate the companies purpose, mission and vision to yearly goals. When you implement a different way of working, e.g. autonomous lean teams or Super7 Operations, your vision could for instance be to have your teams achieve full autonomy.

The next step is then to implement the basics. For Super7 Operations, the teams need to learn how they can plan and organize their work. The 7 principles of Super7 Operation need to be introduced. You don’t have to explain everything, learning by doing is very powerful in the first phase. This is in line with the Shu phase of the ShuHaRi approach (see my earlier post on

Then, we don’t plan the transition in the classical way. No milestones. Instead, define the next target condition. For Super7 Operation, this translates to the next level of maturity, on all seven principles of Super7 Operations. For this, we’ve developed a high-over description of each of the 5 levels of maturity, for each principle of Super7 Operations. Next to this, the level of autonomy is also taken into account.

Finally, the team managers and implementation consultants decide on what experiments may help the team to reach the target condition. The actual action will depend strongly on the level of autonomy of the team. Immature teams benefit from instructions, mature teams will come into action when the right coaching questions are asked.

As you can see, this weekly cycle is based on the Improvement Kata. The results so far are very promising indeed. I will certainly continue experimenting with it myself.

Menno R. van Dijk.

Agile risk management – from portfolio to scrum

Agile risk management could mean that risks specialist let go of their own account portfolio and start working as a scrum team. This is how this could work:

When a traditional bank transforms into an agile organization, its risk management department need to become agile as well. Risk management is often organized as a team of individualistic specialist, each with their own portfolio of accounts or cases.

Agile organizations are flexible in adjusting priorities and reassigning capacity. Teamwork is often the quickest way to introduce this flexibility. A team of specialists can set priorities across all of their portfolios. When one portfolio requires more capacity than its owner can deliver, the team can reassign capacity.

Cooperational ExcellenceOne way to organize this is to create risk management Scrum teams.

There is a downside to this approach – the reason that Scrum isn’t widely used in risk management today. It takes time to get to know the details of a complex case, and it would be a waste of time when a running case is transferred from one specialist to another. However, the benefits could very well be greater:

Scrum teams will work in weekly sprints, delivering ‘fully functional’ deliverables in each sprint. This is the first benefit of this way of working: transparency on what will be delivered each week. In the old way of working, throughput times could get quite long from time to time. And the weekly rhythm gives the organization the agility to adapt to changes. What exactly ‘fully functional’ would mean will depend strongly on the type of risk management.

Second benefit: optimal priorities. The sprint deliverables are made up from the priorities (must haves and nice-to-haves) of all individual risk managers for that week. However, after this first round of collecting priorities, a ‘product owner’ will decide which of these individual priorities are most important. Priorities can be given to where the highest impact can be made on reducing risk. In the old situation, focus would always be on the highest risks within one portfolio. Scrum would give priority to a nr 2 or 3 priority from one portfolio when the related risk is higher than the nr 1 from another portfolio.

Third benefit: the power of teamwork. A team of professionals knows more and can make better decisions than individuals. Our experience with Super7 Operations shows this, also in highly specialist organizations like arrears management.

It’s going to be interesting how a truly agile bank will organize its risk management. I’m looking forward to learning what works. Menno R. van Dijk.

Similarities and differences between Agile Squads and Super7 teams

What are the similarities and differences between Agile Squads and Super7 teams?

Many traditional companies are adopting an Agile way of working, inspired by innovative companies like Spotify, Zappos or Google. In financial services there is also inspiration from within: the transition from classical operational management towards Super7 Operations.

 Similarities Agile Squads and Super7 teams

  • Small team of 5 to 9 members
  • High degree of autonomy
  • Steered on output
  • Team has one mission, one common goal
  • Workload and progress is made visual
  • High degree of flexibility in skills and capacity

Differences Agile Squads and Super7 teams

  • Super7 Operations for ‘customer requests’: operational work, at least in part repetitive
  • Agile Squads for ‘customer missions’: customer services or enablers involving any combination of product development, marketing, product management, data management and IT
  • Super7’s have daily goals (e.g. TITO): daily processing of all customer requests for that day
  • Agile Squads work in weekly sprints, weekly releases of customer-ready solutions or improvements

My conclusion is that both Super7 teams and Agile Squad are manifestations of the same Lean principles. For example, both apply visual management, flexible resources (capacity and skills) and customer centricity.  I expect that the Agile trend delivers the same break-through results in product development and product management as the Super7 trend has delivered in operations.

Menno R. van Dijk

Super7 teams benefit from Lean Operational Management

Super7 teams benefit from having the standard processing times and performance dashboards in place. These elements from Operational Management help a Super7 team in steering itself. When these basic elements from Operational Management are missing, implementation projects tend to take more time. It takes longer before the Super7 teams become autonomous.

Super7 Operations claims to be the next step for Lean in financial services. But how much does it owe to the previous Lean wave in financial Services? Which elements from Lean Operational Management are essential for the success of Super7 Operations?

The Next Step for Lean builds on the previous step

The way I see it, Super7 Operations is the logical next step for Lean in financial services. The first lean waves in financial services were often aimed at introducing standardized work,  standard processing times, and making performance visible in performance dashboards.

Standard processing times make the work plannable. In Lean Operational Management, managers use them to plan the work for their teams. And afterwards, actual production is compared with planned production to calculate performance*. The manager then retains control through performance dashboards.

As I explain in my book, Super7 teams are steered on output. And, in Super7 Operations, the teams get the freedom and responsibility to plan their own work. However, both output steering and planning your own work becomes much easier when standard working times and dashboards are in place.

In Super7 Operations, the customer determines what needs to be done: the workload is based on the actual demand from that day. The manager sets the boundary conditions: that all requests are processed the same day (Today In, Today Out, or TITO). Work is often planned on forecast. But, to make planning decisions, the team needs to be able to match the forecasted workload to their planned capacity. And this can only be done when the forecasted number of customer requests can be translated into hours of work with the help of standard processing times.

Dashboards are equally important in Super7 Operations, but primarily for the teams themselves. They need to be able to see if all their Continuous Improvement efforts are paying off. And dashboards can be used to constantly raise the bar, both by the team itself and by the manager. Too many green lights become a red light, as the saying goes. This means that when the daily targets are met every day, this should lead to a more challenging target. More service in the same time for instance, or doing the same work with less capacity.

When standard processing times and performance dashboards, two basic elements from Lean Operational Management, are missing, implementation projects tend to take more time. It takes longer before the Super7 teams can make the decisions that make them truly autonomous.

Menno R. van Dijk

*Performance in Financial Services is often expressed in Total Team Effectiveness, a derivative of Overall Equipment Effectiveness (OEE) which is the standard within manufacturing.