Category Archives: Teams

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.