Scaled Agile Marketing

Estimated Reading Time: 2 minutes

It’s Agile Marketing Time

One of my interesting engagements these days is with a corporate marketing group in one of the top global enterprise technology companies. They have a very serious agile initiative in product development and their CMO basically said “I think I need Corporate Marketing to become agile as well”. Continue reading “Scaled Agile Marketing”

Making Agile Teams work in real life – The quest for Stable Feature Teams?

Estimated Reading Time: 5 minutes

Context

This post is inspired by ongoing discussions in the AgileSparks team based on our experience trying to help organizations make agile teams work in real life. It is heavily inspired or can even be called a revision of a post from a couple of years ago on the Lean/Kanban approach to teams.

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

Scrum, the most popular framework for implementing agile 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 productivity.”

The scaled agile frameworks popular today (SAFe, LeSS) also put high value on Scrum Feature Teams. All of this is with good reason.  As Al Shalloway writes Cross functional teams eliminate waste and manifest lean. I fully agree. So where’s the problem?

One of the big problems with cross-functional teams is that they require structure changes. Let’s assume though that we overcame this challenge. We get to the another big issue. As teams spend time together they gel and mature and get a chance to achieve higher performance levels (assuming we are doing the right things to nurture this performance and not kill it, but many have written about it before so let’s leave it aside for now). See for example Tuckman’s stages of group development model.

This is why Scrum recommends stable cross-functional teams. So, again, what’s the problem?

Well, if we have very high staff versatility meaning everyone on the team can do everything and all teams can deal with whatever is on the organizational backlog, we don’t have any problem. We can create stable cross-functional teams and they will just deal with whatever we throw their way (or whatever there is to pull from the backlog when they have capacity for it, if you want to look at it that way…). Very high staff versatility is a great idea. Extreme Programming calls it collective ownership. Others call it “Full Stack developers”. For some reason, I rarely see it in the trenches though. Maybe it is just the contexts I’m working with but the variety of technologies and specializations is such that there are very few “full stack developers” around. And as a networking/kernel specialist in my background I’m not sure I would have liked to spend lots of time coding mobile application UIs or SQL statements for that matter. So the reality we encounter is that of at least some variance of skills.

We can deal with this variability, right? We can simply build the teams in a balanced way that is tuned to what’s coming our way. Each team will take features of a certain “work mix”. Essentially this means we will have a product backlog for each “work mix”. The problem with that is that now we are dictating priorities based on the team structure. Let’s say we built a team that is Server-heavy (3 server guys 1 client) and a team that is Client-heavy (3 client guys 1 server). Both are cross-functional able to deliver end to end features but of a different nature. This constraints our capacity allocation to be 50% Server-heavy features and 50% Client-heavy features. Now what happens if we suddenly need to deal with a big need for features who require same amount of work in client and server? Yes we can force-feed teams this work and expect server guys to work on the client side and client guys to work on the server side, on both teams. Yes, this will be a good investment towards Collective Ownership and versatility. Hopefully it is something these guys will find interesting and useful individually. Hopefully they will feel it is a worthy cause. Hopefully the ramp-up time will not be too long. This picture becomes more complex the more skills we need to work on improving. This leads to many people finding it hard to create stable Scrum teams. They find it creates wastes.

Now, let’s pause for a second. In many cases this is just a symptom of fear of change. The difference between Stable Scrum Teams and Dynamic Scrum Teams can be dramatic from the perspective of management (especially those team/line managers managing people directly). In Dynamic Scrum Teams and surely when continuing to work without Scrum/Feature teams altogether people these team/line managers continue to “control” what is going on. They continue to “own” the people and move them around. They can continue to live in the illusion that their old style of management is the right style of management. The move to Stable Scrum Teams, even if it doesn’t change the formal organizational structure, leaves no room for doubt. The team/line managers are not in the loop of day to day work the same way anymore. They have to do things differently. They need to focus more on attending to the bigger picture, to the capabilities of their professional teams/lines (What Spotify call chapters/guilds and others call Community of Practice/Professionals). So one shouldn’t be surprised that they rationalize however they can the downsides of Stable Scrum Teams. (Thank you Chris Matts for sharing some thoughts about this topic of Staff Liquidity during our Feature Injection chat today).

With this in mind, maybe you are saying, the hell with it, let’s do this change. It is all political change resistance. We need to strongly communicate the need for it, manage the change correctly, sell people on being “full stack developers” and have the patience to deal with the lower productivity while we are investing in our liquidity/versatility. And in many cases this will be the right approach.

Maybe you are talking the “Start with what you have” approach of starting with dynamic cross-functional teams that are created and dissolved on demand with the rationale that it is a smaller change but is still a step in the right direction. And in many cases this will be the right approach as well. A word of caution though – Remember your goal in the long haul though – make sure that you are investing in improving versatility along the way and building the capability for improving the stability of teams without reducing the business flexibility. Invest in management skills and style that is more and more oriented around the “Community of Practice” and “Capability Building” so that managers don’t associate that strongly the “daily allocation” responsibility with their identity as a manager.

And one more thing – Regardless of whether you go to Stable or Dynamic teams but especially if you go for Dynamic – let people finish something before they start something else. Don’t put people on too many teams. Ideally a person should work on one team. There are exceptions. But if you find people are working on too many teams they should either work as a “shared services” team and not as members of all these teams or you need to stop some projects/features and wait until people actually have the attention for them. The fact that the Capacity Allocation Excel can find a way to squeeze that project in with fragments of a Full-time-equivalent to be there supporting it just in the weeks they are needed is a surefire recipe for overloading the system and affecting motivation, quality, velocity and cycle times. Jim Benson’s new book “Why Limit WIP” has a great section (Eldred’s story from chapter 7 onwards if I’m not mistaken) about this BTW. I loved the introduction of Learned Helpness as a result of this situation.

 

PS Sorry for not providing a clear-cut best practice. But hopefully I gave you some ideas about how to choose the right approach to start with in your context…

 

 

 

 

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.

Disclaimer

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.

 

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 
productivity."

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.

Conclusion

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?)

My Large Scale Kanban talk at Lean Kanban Central Europe 2011 Conference

Estimated Reading Time: 1 minute

Here is my talk, together with a great visualization provided by the conference organizers.

My main points were:

  • Classes of service do apply when developing products.
  • Classes of service don’t cover cases when you need to give different Treatment to different kinds of work, so I introduce Classes of Treatment for context-specific policies for “how to do the work” not just “when to pull what”
  • Kanban doesn’t prescribe teams, but what kind of team formation / organizational structure works best? Explored several options and their attributes and effect on Flexibility, Resiliency, Performance.
  • Kanban principles and practices scale, in a fractal way. You can zoom in and out as you wish.
  • The higher you go, the tougher it is to feel a day to day flow, which is the main challenge of Kanban at higher levels IMHO.

 

PS If you were at the talk, I’d love your feedback!