At the Amsterdam WebPerfDays 2013 in May I listened to Andy Davies talk about Are Today’s Best Practices, Tomorrow’s Performance Anti-Patterns? He was talking about potential anti-patterns in Web Performance and it got me thinking: What are tomorrow’s agile anti-patterns? And the foremost candidate in my mind was “stable teams”.
[“Stable teams” = Teams that are meant to stay together for years without a change in members. When members change it’s only a single person that leaves or enters.]
When I learned about agile the following was driven into my head: Stable teams are absolutely essential if you want hyper productive teams, because of Forming, Storming, Norming, Performing. After that I’ve heard it repeated many times. Heck, I’ve repeated it myself, because I’d bought into it. (The Forming-Storming part, not the hyper productive part.)
But over time, I’ve witnessed a couple of problems with stable teams:
In Company Acme there were 5 cross-functional teams, all pulling from the same backlog. It was a great setup, with a small caveat regarding Epics: Many Epics weren’t balanced. There were epics that needed lots of new backend written, with only little user interface. And Epics with lots of user interaction, that only needed minor backend updates.
As an Epic sometimes took month, teams regulary pulled stories, that didn’t appeal to half the people in the team, because there were not enough balanced stories / Epics to go around for all the teams (and you don’t want teams to constantly switch Epics).
[Some might think that the stories were just badly split. They weren’t. The imbalance came from the nature of the valuable Epics.]
In Scrum theory the people skilled in the currently less needed field would “just” start to learn the other field. Here’s how I’ve seen this pan out:
Early in the agile transition: Web people usually love web development and want to work on web stuff. Backend people think that web development is beneath them. They probably also love their backend stuff, but phrase it in a way that comes across as rather snobbish.
Later on: They did learn and now have some overlap. On the one hand, you now have a few people who are equally happy with any type of development. On the other hand the majority of people still prefers a certain area and doesn’t enjoy the other areas. Yes, they will work on them, but have a high tendency for procrastination, be it gold-plating what little work there is in their area, be it acquiring “urgent” other work in their area, … It’s human to procrastinate work one doesn’t enjoy.
Even if we’d leave out the procrastination part and people would work on less-liked stuff just as efficiently as on liked stuff, do we really want people to be bored and unhappy with their tasks for extended periods of time? I don’t.
This was a murky feeling I’ve had for a while and then came Conway’s Law.
Conway’s Law
Allan Kelly wrote an excellent piece about Conway’s Law. This law states:
“Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.”
Conway, 1968
Allan elaborates on this by saying:
For example, if a development team is set up with a SQL database specialist, a JavaScript/CSS developer and a C# developer you they will produce a system with three tiers: a database with stored procedures, a business middle tier and a UI tier. This design will be applied whether it is the best or not. Indeed, the system might not even need a relational database or a graphical interface – a flat file might be quite adequate for data storage and a command line interface perfectly acceptable.
It is a little like a children’s cartoon where the superheroes need to rescue somebody: Superman says “I can use my super strength to lift the ice boulders out of the way”, while Fireman says “I can use my fire breath to melt the ice” and Drillerman says “I use my drill hands to make a rescue tunnel”. Once added to the picture each specialist finds a way to utilise his or her special powers. For a software team this can lead to poor architecture, over complicated designs and competing modules.
So the “stable team”-setups that I’ve seen would often have resulted in bad architecture decisions, because team structure and Epic needs were not matching. And yes, we’ve often tried to create tasks to keep everyone busy, during planning.
All of the above made me question the “stable team” approach. I’m wondering, in which context it was recommended. If there were 1000 developers, I can totally see why a stable team is desirable: I would slow everyone down work with complete strangers all the time. The advantages of stable teams outweigh the disadvantages.
In contrast, the companies I’ve worked in employed about 30 devs each. 30 is not that much. With just 30, each developer can know each other developer – know what areas they are good at, their pet peeves, their children’s names, etc. You can hit the ground running walking pretty fast.
In such an environment a more fluid approach, where you build teams tailored to each Epic might work better. Such teams would typically exist a few weeks, depending on how long the Epic takes. In a small enough company this wouldn’t be a huge strain on developers. At least it’s my impression that it generally works great, e.g. when one developer is “borrowed” by another team for just 1 or 2 sprints (self-organized and in agreement with all involved).
What about left-over people?
When I made the case for more fluid teams at my Agile Meetup, I got an excellent question: What about the left-over people? The ones, whose expertise is not in demand at the moment?
First of all, “left-over” has a bad ring to it. Let’s call them “available” or better yet “free agents”. That sounds much nicer and is just as accurate.
Well, you have those in both approaches of setting up teams. Seeing them in stable teams is what made me explore this topic in the first place.
I’m speculating that they’d be better of in “fluid team” land, because then at least they are explicitly free to do something more valuable than making up busy work. I envision tidying up, improving the dev infrastructure, fix bugs, research if library X is suitable, etc. I often see that stories dear to the developers – typically about infrastructure, such as build processes, testing environment, … – never have enough perceived business value to make it into the backlog. Those stories would be perfect for the free agents.
Learning the other disciplines will probably occur less than in stable teams, though I’d still expect it to happen within the fluid teams…
I realize that this doesn’t fit well into Scrum environments. How could the free agents organize? (Personal) Kanban? I’ve read somewhere of an IT dept using Kanban in which people assign themselves to Epics once they’re free…
Do I smell “traditional”?
Now that I’ve written it down, my “fluid” approach has suspicious similarities to the chaotic pre-Scrum, “no process whatsoever”, days at Company Acme. Not what I have in mind! The (fluid) teams that do exist at any given moment do follow some transparent process, e.g. Scrum. And membership is also for complete iterations. The free agents would also follow some process. Not necessarily the same as the fluid teams. Does that make sense?
Or have I just made a full circle and arrived at a traditional project management method, just without saying “ressources” and “pools”? If it is a rather traditional way to approach things, does that make it bad? Even in a small company?
Maybe the “either frontend or backend heavy Epics” that I seen in 2 companies are outliers and this is not a common problem. Then no one else even needs an alternative to stable teams…
So, what’s your experience with either approach and with Epics? What worked for you? And do you happen to know the context of the original “Stable Teams”-recommendation? Is it Tuckman? I’d like to read up on it …