Dominique Stender Good software is only the beginning

The Effects Of A Stable Team

I'd like to talk about a few things I realized in regards of having - or not having - a stable team.

Me and my team went through a lot of instability for slightly over a year. No one got fired or something like that but as the company grows and demands shift, employees move between teams. Due to that I was without a permanent team for a while and just recently got back onto stable ground.

While being on the long road back to stability I realized many different aspects and nuances - some obvious, some not so - that come only with a stable team. I've come out of this with the resolution to prevent any further change to my team if by any means possible.

Estimations are possible

Without a team that doesn't know the technical environment, the project or product it is supposed to develop and last not least a team that doesn't know itself, forget forecasts or estimations. They'll be off.

Knowledge is one thing, experience is a whole different story. Our training phase for example takes three full months. After that new team members have seen more than 50% of the software components we use and understand a little less than that. How much experience with the whole shebang do they have? I'd say around 25%. So even after completing the training there's still a lot to learn.

So if your team doesn't know what's in it's toolbox, how can they possibly give you the right forecast in your product backlog estimation sessions?

Let's keep technical complications aside for a moment: Does your team have it's own jargon? I haven't met a team that doesn't. While that jargon might confuse outsiders, it helps the team to understand each other correctly. But jargon takes time to develop. With an ever-changing team, there'll be misunderstandings within and between you and the team with a direct effect on the quality of estimations.

Quality will skyrocket

In a way the difference between a stable and an unstable team is like getting the job done and getting the job done right. Remember that toolbox I mentioned above? Usually there is more than one way to get a job done with any given toolbox. Most of those ways work, but very few will be good. "Good" here implies maintainable, efficient, scalable, understandable and a few other things.

I've had a lot of review meetings with a user story being done but being done crudely. Here's the thing: I can't blame the team if they've been in that specific constellation for no more than a couple of weeks. If at all I can blame myself for not giving better support.

Who or what is to blame is beside the point: The solution is a stable team that has had time to get to know each other, you as their manager and equally important the frameworks in their toolbox. Take it for granted: No one actually wants to deliver sub-standard software. No one wants to have tasks fail in the review meeting.

Improved skills

In agile, a team is self-organized and self-sufficient in a way that it will be able to get any job done it was formed to do. Rarely you'll be lucky enough to form a team that already fills all roles from the start. In my case, developing an inhouse product, there is no way I'll find someone from outside the office who has even seen the code they'll be working with.

So naturally some skills need to be developed in the team, some others need to be improved. That takes time. Changing the team before the gaps are filled causes confusion.

On the other hand if the team changes after the gaps are filled, you start from scratch. Your new reshuffled team will have new gaps.

Either way you and your team both lose.

Work satisfaction

Growing together as a team and succeeding sprint by sprint is a very satisfying experience.

I'm not talking about any kind of measure here. Sure, the ever rising average velocity per sprint is nice. But actually I'm convinced the emotional aspects that happen when interacting with each other are much more satisfying. I've had very successful review and retrospective meetings only with team members that "got" one another. And hey, what better is there to go home on a Friday evening after a review meeting that didn't find any defects and only minor improvements?

Being able to trust your team (or your manager, if you're part of the team) is pretty darn cool. For the management it's quite simply a relief. For the team it's good to know that you can always go back for clarifications and that "bad" news are usually not a problem between the team and the management.

But here it is again, trust needs time to grow.

Next time you have a meeting with your team, pay attention to the atmosphere. Is someone cracking a joke? If so, I bet it's one of the more seasoned team members whose trust you've already earned.

Productivity rises

Back to the toolbox. The more familiar the team is with the frameworks of their work but also with the strengths and weaknesses of their fellow comrades, the more productive the whole unit becomes. Less time is spent talking, discussing, researching, coaching, debugging, R&D'ing etc.

Also, people will pick the right tasks for them. Usually tasks they like, in areas of the software they're familiar with. They can't make that decision if everything is new to them because they've just joined your team.

It's a little bit like driving a car or riding a bike: Once you stop to think about your hands and feet it all goes much much smoother. But then change from a manual shift to automatic in case of a car or from right foot gear to left foot when on a bike and you're in for trouble. You'll probably still reach your goal but you're just bound to have a few screw-ups on the way.

Closing thoughts

Like I said above in my case training takes no less than three month, and that is for people with 3-5 years of domain experience. After that I estimate another 1.5-2 month until new members have gained familiarity of some sort.

So in my case the team needs at least 5 months to mold. How is it for you? I bet if you're honest and realistic it won't be much less.

This implies that changing the team only twice a year will immediately prevent you from ever reaching full potential for any meaningful amount of time.

Whether you see it from a work-satisfaction point of view, from a ROI perspective or you have a longevity standpoint. Changing your team is a killer.

What are your experiences?

Enough of me, how about you? Did you experience something similar? Or do you have other experiences? Did I miss an important factor? Let me know, write a comment!

Related Posts:

• No Related Posts