Tag Archives: scrum

Be succesful and productive – know your values

To be productive and successful within a team, make sure you know what’s important to you – know your values, know what drives you.

In my previous post, I explained how you can become successful as an individual when the organization you for is organized around teams. A simple model is the basis for individual success in teams, consisting of three circles: 1. you and your talent, 2. you and the team you work with, 3. you and the organization you work in

Model by Menno R. van Dijk

In this post, I’ll zoom in on the inner circle. In the center of the model for individual success in teams is you.  With the help of some practical tips and exercises, you can become “The I in Win”.

There are three elements in the center:
1. your values that define success to you (what drives you)
2. your talents that you can use to be successful (what makes you unique)
3. your experience that you have built up in using your talent (what you know and did)


Let’s start with Values. Understanding your values can be very useful in making important decisions in your life. Your values are like an inner GPS-navigation system, that guides you towards the right way. You can choose not to listen – but you will probably not get to where you want to go.

Some of my core values are being creative and making things better. These are the values that helped me in writing my book on Super7 Operations.

There are several simple and effective exercises available to help you to get a clear view on your values. One that I particularly like is this one:

  • Imagine that you get € 50 million. What would you do? Think about this for a minute. Then take your time to write this down, so you can read it back later
  • What makes the things you wrote down so nice, important or valuable? Write this down too
  • After you did the first two steps: it’s not about the money, if you’re honest. What you’ve written down is what’s important to you, and what you want to achieve. This helps you understand your values

Change is needed on how individuals and organizations see and reward success. You as an individuals need to know what defines success for you. You can do this on your own, or with the help of specialized coaching. And organizations need to recognize unique talents within teams, and reward them proportionally.

Menno R. van Dijk

Improvement Kata for Agile teams, Squads, Scrum and Super7 teams

Improvement Kata for Agile teams, Agile Squads, Scrum teams or Super7 teams: the Improvement Kata is an excellent tool for all forms of autonomous teams.

Agile teams can use Improvement Kata in their start-up phase, to quickly get to the next step of team maturity. They can use the improvement kata to solve issues, impediments and problems.

Improvement Kata is also an excellent method for their support staff: Agile coaches, Scrum masters, Lean coaches and Lean Six Sigma Blackbelts.

Similar to how Agile develops, Kata improves in small steps and doesn’t plan the whole path to the desired improvement. The desired end state or ‘definition of awesome’ is known. But only the first achievable target condition is determined in advance. No further milestones.

Additional to how Agile develops, Kata Improvement put even more emphasis on learning. An experiment may fail, as long as the team has learned from it. Agile does this to some extent, by working on minimal viable products that can be tested in practice. The experiments in the Improvement Kata are even more frequent. Many small experiments ensure continuous learning and continuous improvement.

How does Improvement Kata for Agile work?

Traditional improvement is project based – see figure 1.

figure 1 - the old way of improving

figure 1 – the old way of improving






The Improvement Kata doesn’t plan the whole route: only the next target condition is clearly defined. See figure 2.


Figure 2 - the Improvement Kata

Figure 2 – the Improvement Kata





The Improvement Kata doesn’t tell you how to get to the next target condition, let alone how to get to your desired situation. It doesn’t tell you which steps to take to reach this year’s target. The Improvement Kata lets you discover the route as you go. See figure 3.


Figure 3 - finding the path to improvement

Figure 3 – finding the path to improvement





More theory and examples of Kata coaching can be found on www.lean.org/kata or in books and you-tube posts of Mike Rother.

The improvement Kata shows strong similarities to Agile and Scrum. This makes it the best improvement and problem solving method for Agile teams, Squads, Tribes, Scrum Teams. And it has proven itself for Super7 teams, also. It’s the best way to get to a true learning organization and continuous improvement. This enables you to cope with the ever changing demands of customers and regulators, especially in the current market for Financial Services.

Menno R. van Dijk.

Hoshin Kanri for agile: align Squad backlog with mission and purpose

Hoshin Kanri for Agile – Toyota’s lean policy deployment translated to Agile – is also an excellent tool to align Squad backlog with their Tribe’s purpose in an Agile organization. In my previous post on Hoshin Kanri for Agile, I introduced an innovative way to apply Hoshin Kanri to align the mission of squads with the purpose of their tribe. But the effect carries on even further: the entire backlog of the squads will remain in line with the mission and purpose. Again, this requires a slightly different use of the principles of Hoshin Kanri.

Agile squads work in sprints. At the end of each sprint, they deliver fully functional solutions for their customers. These solutions should be in line with their mission. And this mission should be in line with their tribe’s purpose. Innovative companies like Spotify use this Agile way of working to continuously deliver improved user experiences. Their product range is relatively simple, and their services are fully digital. But how will this work when traditional companies, banks for instance, transform into digital agile companies? Hoshin Kanri is the right tool for the job.

Hoshin Kanri Policy Deployment starts at a strategic level:

  1. Formulate break-through goals for 3 to 5 years ahead. These are the goals that will make a real impact on the purpose of the tribe.
  2. Translate these break-through goals into one-year goals. This is the annual plan for the tribe, with challenging but achievable goals.
  3. Translate these goals to Squad Missions. These missions describe the processes that need to be improved.
  4. Determine which metrics will show the progress of the improvement.

Then, the squad gets to work. But not by creating a backlog directly from their mission. The mission should be used as a starting point for improvements. The squad has a set of proven Lean improvement techniques at their disposal. From large scale to small scale (and from low to high frequency):

  1. (Re)design, e.g. Value Stream Mapping, Design for Six Sigma or Washing Lanes
  2. DMAIC projects, executed by green- and blackbelts
  3. KAIZEN improvements, team improvement sessions
  4. Kata improvement, weekly improvement as a habit
Hoshin Kanri for Agile
Hoshin Kanri for Agile


Finally, the backlog is filled from each of these improvements. As each of the improvements are focused on the same strategic priorities, the backlog will be completely in line with mission and purpose.


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

Creating the right culture for Super7 Operations

How to create the right culture for Super7 teams?

Creativity and autonomy florishes within a culture of trust, support, stretch and discipline. Traditional companies often rely on constraints, compliance, control and binding through contracts. This is explained excellenty by Prof. Sumantra Ghosha.

Recently, I was given a tip to watch a short clip form Prof. Sumantra Ghoshal, called “the smell of the place”. To my opinion, this clip is very relevant for autonomous teams, scrum, agile and Super7 Opertions. Below, you’ll find his brilliant speech from the World Economic Forum about corporate environments and the faults of management in creating a positive work place.

The smell in which creativity and autonomy – and therefore Super7 Operations – will florish

  • Stretch (environment in which everybody wants to take that extra step)
  • Discipline (self-discipline, be on time, agree to disagree and committ to decisions)
  • Support (managers change from exercisers of control to coaching, guidance, support)
  • Trust (act on the presumption that people act in the best intrest of their company)

 In contrast, the smell traditional companies often create:

  • Constraints in stead of stretch,
  • Compliance in stead of dicipline,
  • Control in stead of support,
  • Contracts in stead of trust.

Important lesson from this video is that the smell can be changed. You can convert the smell of the place from “downtown Calcutta in the summer” to “a forest in spring”. It has been done before. And, you can use the smell metaphor in explaining and visualizing this change.

One department I recently visited had a brown paper on their Scrum-wall, on which all teammembers rate the smell they are smelling on a scale from 1 (Calcutta) to 10 (Forest). This way, they can monitor the culture, and address issues that cause ‘bad smells’.

Menno R. van Dijk.

ShuHaRi as a way of implementing Super7

Implementation of Super7 Operations can benefit from ShuHaRi, the Japanese learning-technique that is often used to introduce Agile Scrum. This way, you can give the team the responsibility for how to apply the principles of Super7, as soon as they are ready for it.

Should we ask the people from the shop floor to participate in the design of Super7? As Super7’s are supposed to be autonomous, why not give them autonomy in how Super7 Operations is applied in their teams? These questions often arise when organizations are planning to adopt Super7 Operations.

I feel that it is a very good idea to give the Super7 teams full autonomy on how they apply the principles of Super7. However:

  • People can only be expected to master the principles, and apply them to their own view, when they first fully understand them;
  • And, they can only fully understand them after they have experienced working with them;
  • And experience isn’t gained through explaining and training, but through doing.

My approach to implementing Super7 Operations is based on ShuHaRi, a Japanese teaching philosophy. So, a bit of theory, then:

ShuHaRi describes three phases that you go through when learning a technique:

 Shu: As a student, you follow the teachings of the master precisely. You don’t have to know the underlying principles. You practice the standard way that the master teaches you.

Ha: You are now able to execute the new technique, and you start to recognize the principles and theory behind it. The teacher may help you by explaining the principles to you. You now start to experiment with applying the principles, not only the standard that you have been taught.

Ri: You are now able to improve on the standard, by applying the principles. You use your experience to make the technique better for your situation. The principles are so clear to you that you can apply them without help from a master.

The ShuHaRi method is now widely used within Scum and Agile software development. Alistair Cockburn translated this Japanese martial arts best-practice to a way to learn techniques and methodologies for software development.

In our most recent Super7 Operations implementation projects, we’ve applied ShuHaRi in combination with the Improvement Kata. See my previous posts on the subject of Kata for more information. ShuHaRi and Improvement Kata are combined to give the team weekly target conditions that they can experiment towards, where the focus shifts from instruction towards freedom to change the method as seen fit. But this is perhaps too abstract, too much for one blog post. I will go into my approach to implementation in more detail in the near future.

Menno R. van Dijk.

New White Paper: optimal team size

Lean and Super7 Operations work with small, autonomous teams. Exactly how small should our small autonomous teams be?

This is the question the manager of the central back-office of a large Dutch retail bank asked me, when I proposed the idea of autonomous team to him. At the time, I was working on a project to introduce customer focus and to realise same-day processing in his organisation. I came up with an innovative organisation design, in which small teams are responsible for their work for that day, i.e. all customer request of a certain type that the bank had received that day. After successful pilots, the organisation wanted to introduce this way of working for all (ca. 400) employees. That’s when this question came up…
From experience, I knew that the teams shouldn’t be too big: the pilots were done with teams of 5 – 7 persons. However, factual substantiation was needed. A quick search showed me that a lot of research had been done on Agile / Scrum teams, so that’s where I started. And this article is the result: a literature search on the optimal team size for autonomous teams.

My conclusion is: Organisational design isn’t an exact science. As an engineer, I would have loved to have found statistically sound measurements on the effectiveness of teams of different sizes – but in truth, I think that team size isn’t the main driver for team effectiveness. However, if your customer, the type of work your customer asks you to do, requires your organisation to work in small teams, I would suggest – as I did to the manager of the banking back office: small teams consist of 5 to 9 persons. Or, If the flexibility of your workforce allows this, as it did in the case of the banking back office: flexible team size, ranging from 5 on slow days to 9 on a busy day.

At the moment of writing, the banking back office has implemented the new way of working, and has asked me to do a ‘check-up’ on effectiveness of the new organisation. I can’t wait to start: Ï wonder what I will find, but I bet that it will be inspiration for several articles on CoOperationalExcellence.nl!

White Paper: Optimal Team Size