Tag Archives: agile

Principles of Agile and Super7 compared

Many companies are adopting the principles of agile, nowadays. And they often find that their operations departments are ahead in this field. This is because of their experience with Lean and autonomous teams – their experience with Super7 Operations.

So, how do the principles of agile compare to the princples of Super7 Operations?

The agile principles (source: www.agilemanifesto.org):

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change or the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The principles of Super7 Operations:

  1. The Super7 team has a goal that is relevant for the customer. The Super 7 team can help each other in achieving this goal. The goal is translated daily to a goal for that day. The Super7 team is committed to achieving the daily goal. When problems arise during the day and the daily goal can’t be met, the Super 7 team responses by doing what they can to come as close as possible to the goal. When that isn’t enough to reach the goal, they ask for help from their team manager.
  2. All Super 7 team members have the skills for all types of work. The Super7 Skills-Matrix shows who can do what, and at what skill level. The Super 7 team members are sufficiently flexible in working hours to be able to meet customer demand on busy days.
  3. Team manager steers on output. Manager stimulates the Super 7 team to come up with solutions. Manager is available and helpful when the Super7 asks for help.
  4. The daily rhythm is tuned to the rhythm of the customer requests. There is a fixed schedule for Super 7 team stand-up meetings, focused on achieving the daily goal.
  5. Super 7 team is autonomous in work distribution and who does what. There is a standard way of working. The team can deviate from this standard, as part of an improvement experiment.
  6. The Super 7 team is stimulated to continuously make the daily goals more challenging. Standard norm times are improved and planning is made tighter. This is done though Improvement Kata and Kaizen. As an Improvement Kata habit, a Super7 conducts small experiments, aimed at achieving the next target condition. For larger improvements, they plan a Kaizen event. There is a constructive performance dialogue, based on facts and figures, on all level of the organization.
  7. The Super 7 uses visual management. Daily goal and progress towards this is visible on the Super7 team board. Performance of last period is visible, as is the trend. Running and planned experiments and improvements are visible on the Super7 team board.                                                                                

The similarities are clear:

  • Delivering value to the customer is the main priority
  • Teamwork is key
  • Self-organization
  • Flexibility over planning
  • Face-to-face is the best way
  • Continuous improvement based on reflection on performance

Because of these similarities, experience with Super7 Operations will facilitate the transition towards agility.

Menno R. van Dijk.

 

Transformation to Agile benefits from LeanSixSigma experience

When traditional organizations transform into Agile, they can benefit from their LeanSixSigma experience.

Many traditional companies are looking with great interest at how innovative tech companies are organized. Even in banking, an industry that is known for being conservative, experiments are taking place with Agile Organization:

  • multidisciplinary squads instead of functional teams,
  • tribes instead of departments
  • IT development and business management in close cooperation
  • Continuous delivery of small changes (sprints) instead of big projects

LSS
Lean Six Sigma has been applied in banking for more than a decade. Many banks have their own pool of Lean Experts or LeanSixSigma Blackbelts. As Agile is based on similar principles as Lean and the Toyota Production System, this experience may be very valuable in this transition.

 

Agile organizations use Agile Coaches, to help the team in the use of the Agile and Lean principles. LeanSixSigma could add to that. For instance:

  • Put focus on the Voice of the Customer. Challenge the Squads to determine and measure the customer impact of their work.
  • Make sure the quantitative results of every sprint are visible
  • Achieve alignment between squad missions, tribe purpose and company vision. This can be done through Hoshin Kanri – a method for policy deployment developed by Toyota and an important Lean method
  • Accelerate problem solving by applying the Coaching Kata to the squads Improvement Kata, and by applying Analytical Problem Solving techniques from LeanSixSigma

 

The transformation of classical Back-Offices to Lean Super7 Operations has been an exciting journey so far. The transformation from a top-down functional organization to an Agile organization promises to be even more so.

Menno R. van Dijk.

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 www.cooperationalexcellence.nl).

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

Making Agile Squads work

To make Agile Squads work, you can make specialists multi-skilled to enable the Squad to prioritize across all disciplines within their squad – an important lesson from our Super7 experience.

Many companies are trying to emulate the success that Spotify has had with their Agile engineering culture (see YouTube: part1, part2). Traditional companies are now considering reorganizing into Squads, Tribes and Chapters. Let’s recap first:

A Squad is a small, multi-disciplinary team, much like a Super7 team, but more focused on developing and managing a product or product feature rather than processing customer requests.

A Tribe is more-or-less what we used to call a department, but again, focused on a related group of products or services.

A chapter is the ‘matrix-layer’, a group of similar specialism from different tribes.

As Spotify explains in their second video, strong growth has made the Squad & Tribe organization more complex. So how do you get this type of organization to work?

My observation is that the matrix of Chapters running crisscross through Tribes creates 2 potential problems.

1. Less autonomous problem solving power for the Squads because different specialists can’t help each other.

– Squad members are all specialists in their own field
– Each specialist will have their own list of priorities
– When one specialist’s highest priority is really critical, the risk is that his/her squad members can’t help this specialist, simply because they don’t know enough of the subject.
– Instead, they can only focus on their own priorities, sub optimizing the squad results

2. Requirement of more management because of complexity

– In the situation as described above, the specialist in need of help will turn to his/her chapter-members.
– This requires cross-squad or even cross-tribe prioritizing
– And this will require a lot of talk, compromising, decision making.
– In short, this will increase the need of management.

For these 2 problems, our experience with Super7 could hold the solution:

Use multi-skilled specialists, and enable the Squad to prioritize across all disciplines within their squad. A graduation study has shown that Super7’s that can rely on help from within their own Super7 are more effective and have better team-spirit than teams that need to lend a hand to other Super7’s on a regular basis. This emphasizes the importance of multi-skilled specialists.

How would this work for Squads?

  • Super7 shows us that specialists need to be able to help at least 2 other members of their Super7.
  • Translated to Squads: every squad-member needs to be a specialist in at least 2, but preferably 3 specialisms that are needed within the squad.

This will demand a lot of the people involved. They need to be trained. But as Toyota puts it: “we build people before we build cars”.

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