Continuous Team Switching?
Douglas Squirrel led a session at CITCON Budapest 2012 about Continuous Rewriting, summarizing many ideas I've heard before from Dan North or Fred George presentations into a really coherent evolutionary progression, and took the concept even further.
Like other Continuous practices, this would be as much a technical as an organizational-cultural change. It got me thinking about how this would change the team dynamics - not just inside a team, but in the context of the bigger organization.
The various Continuous practices always came about the realization that when something is rarely done, people will be bad at it and thus it will be hard, ineffective and error prone. Thus if we simply do it more often, we would get better at it.
Joining a new team and becoming an effective contributor is a process that is in need of improvement (on most teams). Getting to grips with the inherent domain complexity and the piled on technical complexity, learning the tricks and workarounds, etc. can hold back someone from being efficient for quite a while. On the other hand, having a fresh set of eyes can provide a new perspective and expose much of the technical debt the team has.
All the continuous rewrite examples so far have reduced the code size, making it understandable (though often this reduction came thanks to better understanding of the domain).
Assuming the reduced code size enables speedier onboarding of new team members, while still benefiting from the new perspective it brings, what would more frequently rotating in and out rotation team members (while never completely replacing any one team) result in?
Like other Continuous practices, this would be as much a technical as an organizational-cultural change. It got me thinking about how this would change the team dynamics - not just inside a team, but in the context of the bigger organization.
The various Continuous practices always came about the realization that when something is rarely done, people will be bad at it and thus it will be hard, ineffective and error prone. Thus if we simply do it more often, we would get better at it.
Joining a new team and becoming an effective contributor is a process that is in need of improvement (on most teams). Getting to grips with the inherent domain complexity and the piled on technical complexity, learning the tricks and workarounds, etc. can hold back someone from being efficient for quite a while. On the other hand, having a fresh set of eyes can provide a new perspective and expose much of the technical debt the team has.
All the continuous rewrite examples so far have reduced the code size, making it understandable (though often this reduction came thanks to better understanding of the domain).
Assuming the reduced code size enables speedier onboarding of new team members, while still benefiting from the new perspective it brings, what would more frequently rotating in and out rotation team members (while never completely replacing any one team) result in?
- Could this make spreading of ideas and practices within a company more effective and faster than the current silo'd, departmental setups?
- Would it speed up the on the job, just in time learning of every
developer in the company? - Would it improve the skill level of every developer, or would it drag everyone down?
- Would it strengthen the company culture, simply since each person would know more other employees (given that many of us only socialize within our own team)?
- Would it spark more cross-departmental improvements - unlike accountants or marketers, developers can jump between various areas and domains of the company with relative ease, and thus could see potential improvements. Would this make crazy IT processes (where the data passes through, without enhancement, several different teams and applications, modified effectively by only one at the middle, then be loaded back into the original source) extinct, making IT governance easier?
-
Steven on 2013/01/19 15:42:41: There are studies found that stable teams can improve as long as 3 years. From that I would recommend stable teams over switching team members in and out.
-
Peter Zsoldos on 2013/01/19 17:08:12: Steve,
thanks for the input! Could you give some pointers for these studies (titles or links)?
I don't understand your second sentence (not a native English speaker) - you suggest that based on these studies, having a stable team is better/more effective/etc. than having constantly changing team members (the thought experiment of this post)?
-
Peter Zsoldos on 2013/01/19 17:08:12: Steve,
-
tamasrev on 2013/01/21 21:22:23: Wow, this makes sense.
Let me add some anecdotal evidence: Every time I'm joining a team, I start to see tons of technical debt. Later I'm getting used to it. Sometimes I even miss the old code when switching to something new. This is the thing that makes _some_ outsourcing veterans (i.e. EPAM alumni) very efficient. -
Peter Zsoldos on 2013/01/23 20:38:18: what is the thing that makes outsourcing veterans efficient? The ability to enter any codebase and identify the place(s) that need changing for the new feature/project?
To add to the anecdotes (hoping @jasongorman doesn't read comments :)) - you don't need outsourcing for that, enough if you work on maintenance teams that are responsible for more than one application. Though it might be more a question of attitude and/or confidence than experience with switches. E.g.: I never hesitate to follow a stacktrace into 3rd party code (or find out why I *don't* have a stacktrace) or simply load the source to compensate the unhelpful documentation. Kind of like the difference between junior and senior developers is that the latter are not afraid to voice their opinions/questions... -
tamasrev on 2013/01/29 19:37:44: Didn't the blog just swallowed my comment? Here it is again:
What makes outsourcing veterans very efficient that they have to work with and maintain several projects written by other people. They will learn both continuously improve the code as well as do fuckin quick fixes. They also learn how to adapt to different coding styles they see in their project pool. They can relatively quickly identify the problematic parts of a codebase and they can come up with change suggestions. However, a typical outsourcing consumer isn't interested in their opinion.
It's worth to mention that outsourcing veterans only have a *chance* to learn all this stuff. They can also burn out due to the mind-numbing tasks they have to do.
