Tag Archives: Organization

Linking Team Modes to RightShifting

Estimated Reading Time: 2 minutes

What is Rightshifting?

When I looked at the program for Lean Kanban Benelux 2011 I found a couple of sessions talking about something I wasn’t familiar with – RightShifting. Since I had to speak at the same time, I didn’t have a chance to go check it out. Come Lean Kanban Central Europe 2011 I saw another session on RightShifting, again a conflict – this time with my Pecha Kucha talk. But I was curious enough to try and check it out, have a chat with Bob Marshall and think about it for a bit.

Yesterday, at home already,  a couple of thoughts clicked.

One of them was that my post about Lean/Kanban Team Modes might fit into the RightShifting model. I won’t go into what it is, if you’re interested go see the movie from Lean Kanban Benelux 2011:

Bob Marshall – Grant Rule – Understanding Effectiveness: Rightshifting and the Marshall Model from AGILEMinds on Vimeo.

Now, assuming you have some idea about RightShifting, here’s my thinking…

Team modes and RightShifting

Well, thinking about the ad-hoc phase I have in mind a start-up / small group where everyone is one big happy family, without any rules, hacking it out. No teams there for now.

At the dawn of the analytical phase, the group is too large, seems like we must introduce some discipline. Part of it is creating functional teams, and discussing the interfaces between the functions, roles and responsibilities, RACI, etc. This is the starting point for my previous post, and what I see in most organizations I start working with.

The synergistic phase seems to align pretty well with initiative/project teams and maybe work cell teams at it’s border with the Chaordic phase. These teams are more synergistic based on their cross-functionality and focus on business value purpose. Work-cell teams are more flexible, which is why I think they are a bit right-shifted from initiative/project/product teams. One interesting point is that some organizations wishing to go to “Agile”/”Scrum”/”Kanban” don’t always understand that this will pull them right dragging along the cultural mindset… They want this agile thing as a plug-in to their analytic mindset… That is always lots of fun to deal with 🙂

Where do we go from work-cell synergistic teams? Well, I think the return to on-demand teams, this time within a bigger group that already has wide any to any communication bandwidth so strong dynamic teams can be setup and tear down with minimal coordination cost, might be a good fit for a chaordic mindset. I have a few organizations on the verge of this transition, maybe exploring the framework with them will help formulating a vision / rationale for what is going on.


I’m no RightShifting expert. Far from it. Just some thoughts I’m putting out there, with the hope they will enrich the conversation, and maybe interest a couple of my readers in RightShifting.


How to use Kanban to help improve your recruiting process

Estimated Reading Time: 6 minutes


I recently had the opportunity to talk with a couple of HR managers who were interested in how agile can help the HR department become more effective. This was a context where the product development is well into their agile journey, and we are talking about a group of about 20-30 people providing HR services like recruiting, training, social events to an enterprise R&D organization in the 1000 people range.

What does agile mean for HR

Well, I tend to view HR as a service driven operation. There is demand of various types coming in. The HR turns this demand into a service that the organization consumes/uses. A classic example is recruiting. Demand is the hiring manager with the new open position. The recruiting department helps fulfill this demand, and the end result should be position fulfilled.

So the First thing we did in the session was explain how lean/agile aims to maximize effectiveness delivering value leveraging the following understandings:

  • Most HR Activities are knowledge work with high variability and learning. We are not sure about a candidate so we want to maximize early feedback. We want to understand whether a training we got a request for will REALLY be interesting to the people to the level they will sign and allocate their budget to it, to avoid spending precious energy on things that get thrown away / changed later.
  • HR groups have a certain capacity. When overloaded performance actually goes down, same like motorways, computers, or development groups. So we should try to use a system that lets the group limit multi-tasking to healthy levels.
  • Activities that are only half done are very dangerous. We call that inventory / work in progress, and the more of those we have, the harder it is to operate. It is harder to focus, context switches cost more.
  • There is a lot variability in the demand as well as the work required to deliver services. During ramp up times recruiting for example is overburdened. Versatility within the HR department is valuable to assist in dealing with this variability.


With this context in mind, I outlined Kanban as a Method to drive for improvement in this context. What does this mean?
Kanban starts with the processes you currently have. You agree to pursue evolutionary improvement, and to respect current state but be open to change it.

What you actually do is take the following steps:

Visualize the Work

Visualize the process/workflow of fulfilling the demand. For example if we continue with the recruitment example – raise need for position -> create position description -> publish > filter candidates > best and final between a few top candidates > prepare offer > send offer > signed offer > prep for onboarding > onboard > 3 month – successful hire. With this workflow we draw a kanban board. I recommend starting with a simple board with a few steps – see below…

Now we populate the board with the current work, in each of the phases. A card represents a piece of work that when Done will mean fulfilled service ( eg one open position)

We can use different indications to show different kinds of work, work states such as blocked, who is currently working on what and more. The idea is to visualize as much of the state of work as possible. Ideally in a big physical board visible in the workspace of everyone or in frequently visited public space. This creates transparency that will in and of itself spark interesting discussions, raise problems to the surface and start creating a list of problems we need to handle ( which is good… )

We want people to use this board in their day to day activities. The board should be the main tool used to track work and synchronize. Lots of teams use daily sync meetings in front of the board.

Limit the work in process

Next step is to recognize that there are limits to capability, and work should be governed by capacity. What we actually do is assign limits to numbers of cards/items in process. The most common way is to say “no more than 3 cards in this board lane” or “no more than 3 positions we are currently writing descriptions for”. This creates a pull system, because it means that once that limit is reached, no new work can be pulled in, until some work has been pulled by the downstream process. This has the effect of “We’re all in this together, concerned about delivering value, rather than just doing our job”. Very quickly some slack will be created by the pull system. The magic is to divert this slack to help the work flow right now, but more importantly find ways to improve the capacity of the bottleneck that caused the flow to stop.

An example is probably in order. If it seems like many positions are in “sign” it might be interesting to use slack time to help create better templates or easier access to salary tables to reduce the effort it takes to prepare offers. If it also seems like a lot of offers are rejected since the candidate is not really serious, it might make sense to find a cheaper way to verify seriousness before spending the effort to prepare an offer. What you actually do will be context specific of course. The Kanban Method WIP Limit will just waive the flow problems in front of your face and beg you to deal with them, more intensively than before.

Manage the Flow

Start caring about the flow, the time it takes from start to finish, from request/demand to finish. Care about the mean time, the promises you can start making, the corner cases and what they mean and how you can improve by learning from them. For example if a typical position is handled start to finish in 4 weeks, and you see a position took 1 week, look at it and try to think what makes it a “Bright Spot”? Was the job description crisp and sexy? Was the hiring manager devoted to making it happen? Was the recruiter using some new sourcing technique? Same for the opposite case – what went wrong with that position that took 8 weeks?

Make your process policies explicit

This is a very interesting step. On the surface, this is very mechanistic. Seems like “Document your process”, what’s new here? And what’s Agile about it?

First, just to make sure we understand, these policies are the rules of the game. Things like the WIP Limit, the conditions for cards being done in a certain phase and ready for the next one, the policies for expediting work if necessary.

Explicit policies enable empowerment. They improve the level of coherency of the system among all people working on it. They can safely make local decisions that are aligned with the rules of the game.

Beyond that, Explicit Policies are not static. They should evolve based on new understanding and learning. You should experiment with them to see what works. The policies will be painful. You will sometimes feel you are hitting a wall. That they are creating constraints for you. That is good. Constraints drive creativity. And if the policies are constraining you in a way that’s driving you towards better and better flow, that’s great. It means the pain is part of the gain. The discussions you will have about what to do to make the policy work for you, will drive the improvement action items. Sometimes you will relax policies that went too far too early. Sometimes you will tighten things up to drive for more improvement. This is one of the key practical ways Kanban drives learning and Continuous Improvement – Oh that holy grail…

Improve Collaboratively using Models

Finally, with the system in place, after you start using it, there will be opportunities to use models that apply for Flow systems. I will not go into this. Suffice it to say that although the Kanban system might seem simple, there are a lot of ways to look at a system and improve it. If you’re interested in this area, I can refer you to more material on the subject.

This is it

Yes, might seem simple at first, if you’re looking for the revolution it is not here. On purpose. Kanban is an evolutionary method. It aims to provide an alternative to classic shock and awe change programs that many organizations had bad experience with. With Kanban you change at the pace that works for you. You can accelerate pace of change as you become more proficient in identifying the problems and experimenting with solutions.

What did the friendly HR managers think? Well, they liked this method, found it very applicable to various processes in the HR department, and can’t wait to start. We are meeting in a couple of days again to play some Kanban games and setup their boards. I will report when there is more to tell…

Note that nothing here is very specific to HR of course. This simple approach can be used to introduce change in many knowledge-oriented services. Many Kanban practitioners are reporting Kanban boards popping up in other departments when the IT group starts using it. It’s quite viral…

To be continued…

Lean/Kanban approach to Teams

Estimated Reading Time: 6 minutes

To Team or not to Team?

If you look at the definition of Kanban or Lean, you wouldn’t find teams anywhere there.

If you look at the Agile Manifesto, you can find “The best architectures, requirements, and designs
emerge from self-organizing teams”

Scrum is quite clear about the topic (Quoting the Scrum Guide 2011)

"Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to 
accomplish their work, rather than being directed by others outside the team. Cross-functional 
teams have all competencies needed to accomplish the work without depending on others not 
part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and 

So, if you are a manager of an organization on the Kanban train of evolutionary improvement, what does it mean for team structure? Should you keep the current structure? Adopt the Scrum Feature Teams concept? Do something else altogether? How should you organize your people to be as effective as possible in delivering value for the stakeholders?

Teams as an emerging property?

I personally believe that even if kanban the tool doesn’t talk about teams (obviously since it’s just a visualization and process-driving tool), despite the fact that the Kanban Method for evolutionary change doesn’t talk about teams (obviously since it starts from where you are, respecting your current structure, letting changes be pulled from actual need), more effective patterns for team formation will emerge when Kanban is really used.

At their core, Teams affect communication bandwidth. They partition the organization to enable increased communication bandwidth among people in a team, while counting on the fact that communication bandwidth to people outside the teams is not that important. Since we are talking about people, not network nodes, teams also allow the communication bandwidth to increase, the longer the team is working together, due to the team formation model. I recently read “The Talent Code” where the behaviour of our brain around learning new skills using myelin to wrap neurons to increase bandwidth reminded me of how teams behave.

So it seems like teams can really increase our effectiveness, and everyone in a reasonably sized organization cannot even bear to think about getting rid of the partitioning, right?

Well some of the Kanban thinking says that since Kanban massively reduces coordination costs via hyper-visualization and the pull system, the size of teams can increase significantly. Since we advocate using classes of service to allocate capacity to demand, thereby maintaining flexibility, we shouldn’t allocate people to demand.

The main reason not to go to teams is that teams might be local optimization. If our workload/demand was certain, and the uncertainty as to what effort/speciality is needed to deliver it was low, we could build the teams that optimize our performance. If that workload/demand didn’t vary over time, we could maintain the same teams and still have optimal effectiveness. But since in most environments we are facing a complex system with uncertainty/variability in the workload/demand, as well as the implementation effort/speciality required, it seems like sustaining stable teams will cost us in some optimization.

Team Modes

In my recent conference talks (GOTOCPH, LKBE11, LKCE11) I provided my view on this question of team formation and Kanban. I described the following progression:

  1. Functional/Component Teams based on specialization
  2. Teams On-Demand – whenever pulling a new Feature for work, associate the relevant people with it. They will deliver that feature, and after a few weeks return to their home teams. This approach provides lots of flexibility, but typically has relatively high coordination costs. It also doesn’t really benefit from the improved communication bandwidth among the team members that you get from persistent teams. This is very similar to the Feature Driven Development team mode by the way.
  3. Project/Initiative Teams – whenever pulling a new Project/Initiative for work, associate the relevant people with it. They will work together as a virtual team for the duration of that project/initiative, and after a few months, return to their home teams. The benefits of this approach is lower coordination costs as the teams don’t change that often. In addition the people working towards the same business goal are working together. The communication bandwidth increases as well over time, as well as the feeling of purpose and alignment. On the other hand, flexibility goes down. It is harder to shift people into projects/initiatives. It is harder to shift people out. If there is significant variability in the specialization required along the life-cycle of the project, selecting the right team becomes hard. If you work on versatility of your people, or already have a great group of generalizing specialists, this will be less of a problem. It can also be addressed by keeping a slack of several people working outside of project/initiative teams, that can be easily shifted in and out of activities on demand. It makes even more sense if those people are your experts/heroes. I’m seeing this mode in action in several organizations.
  4. Teams pull work – The next mode is where you create stable work cells that are able to handle almost everything you throw at them. These work cells stay together as the main organizational unit, and pull work based on the next business option the organization wants to exercise, regardless whether it is to accelerate an existing initiative or start something new. Here the communication bandwidth grows stronger and stronger. The flexibility and agility to shift business priorities and help swarm to work in process remains quite high, but the internal team flexibility remains an issue. The same slack of people not associated to teams can help here as well. I’ve seen this specific mode in action in several organization, and it works great, assuming you are ready for the change.
  5. On demand teams – Wait, didn’t I mention this one? Yes, I did. The difference here is that assuming you somehow have a tightly knit group which already managed to create lots of communication bandwidths among the WHOLE group, you can have a win-win. Total flexibility and global optimization. This should be the holy grail of any manager of about 20-40 people I would imagine. A force to reckon with…

Mixing it up

You don’t have to decide on one model. Not all work is created equal, so not all teams should follow the same structure. Some interesting examples:

  1. 80% on-demand, 20% focused on an initiative
  2. 80% on-demand, 20% cross-functional work cell (A-Team)
  3. 80% project teams, 20% on-demand able to swarm to a team in distress and help, or join a team to teach them some new skill as appropriate.

Evolutionary Change

Some organizations will jump in, create work cell teams, and start working. I’ve seen it in action, and when you REALLY have enough energy in the organization to make this maneuver, by all means go for it.

Other cases you will not have enough energy. Or you will THINK you have enough energy, but reality will hit you in the face when all the middle managers / team leads that led you to believe they are on-board are not that supportive once it is time for action and for supporting the actual new structure.

So think hard about what is your case. And if you want to go for a more evolutionary change mode, consider the following:

  • Start with on-demand teams
  • Pilot one initiative/project team – especially useful when you have a risky initiative with a lot of uncertainty and dependencies, that is mission critical. Assign the success of this team structure to one of your best and most trusted people, if not yourself. Whether he is the Coach, the actual Lead, or something else is secondary. The important thing is that he will be in charge of making the team structure work, and together with the team make the learning from that available to the rest of the organization
  • Move to more and more initiative teams as necessary
  • When a project/initiative finishes consider turning the team to a work cell to pull more features in that area, or more features in general
  • Ideally, teams will have the capabilities to take almost all work on. If not, use a talent matrix showing what teams can do what and gaps to invest in. As well as talent matrix inside a team that will help teams grow some internal versatility (note not everyone on a team needs to know everything at the same level)

Cautionary Notes:

When creating teams be careful not to spread yourself too thin. If you have too many small teams it might be an indication you are not managing flow effectively at the Initiatives/activities level. I love teams of 4-5 people by the way.

If you find many people need to be on many teams, you have a real problem. It is ok for a minority of the people, especially specialists, to be needed by many teams. Maybe they should stay as auxiliary on-demand, while spending some of their capacity offloading knowledge to the teams. But if it’s not a minority, then you really need to work on versatility, or the on-demand might be a better fit. The whole point of the teams is to create the communication bandwidth. Without that, they’re just overhead.


I presented a couple of team modes here, as well as one way you can use them. This is really context-specific stuff, so I cannot tell what will work for your case. But I hope the modes help you relate the Lean/Kanban effectiveness principles to the options of team formation. In upcoming posts I will try to relate this to a couple of thinking frameworks I grew fond of lately (RightShifting? Cynefin?)