Saturday, January 19, 2013

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?
  • 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?
I don't know. But it certainly was a fun thought experiment! Feel free to add questions to the above list in the comments!