Distributed SCRUM team issues: The work environment

Question

One interesting issue appeared for me today. In a distributed SCRUM team when do you start enforcing an unitary work environment in terms of code format, IDE plugins (checkstyle & co), VCS, CI? The team is in an exploratory phase and thegoal is not production quality code but rather proof-of-concept. Isn't it an overhead to enforce some common coding rules "a priori" - before the team members decide which are really relevant for their future work? Using this kind of tools is for sure a huge benefit because they act as an heuristic to minimize the technical debt but enforcing rules as "no trailng spaces" that really break the Jenkins build seems for me an overkill for a phase that should be focused rather on ice-beaking than on creating production code.

Mention 1: the prototypes create will be thrown away

Mention 2: although I wish that everything should be done right from the beginning - I m totally aware that it is not 100% possible.

Answer 1

I think there are 3 parts to the issue:

1. You want to save technical debt/headaches down the road by enforcing good rules now.
2. You don't want to kill team velocity by bogging everyone down with unnecessary rules.
3. You don't know exactly the best rules to implement, because the project is in an exploratory phase.

I've tried both the extremes (from no rules, just use the same source control, to a 20 page coding style guideline + many other processes)

The only thing that's worked consistently is embracing the absolute minimum I know I need and can prove I need right now, and revising the process regularly. (Every sprint in the retrospective is a good time to do it) This also includes removing any vestigial rules.

Answer 2

I guess this really depends on teams and how much do you care about checkstyle. I agree that we should have some kind of rules to prevent some unnecessary bugs. But some rules are rather annoying than productive. I guess you have to agree within the team what rules are necessary and unnecessary.

Setting Jenkins jobs for checkstyle or firebug is good as well, but again you have to agree how strict you want it to be. I have been in a situation where somebody broke some checkstyle rule and we prevent anyone from committing. In the long run, it'll just annoy people. Again, if you said people don't have to pay attention much they'll start ignoring them. So, in my team we kind of agree that as long as the quality job isn't badly broken. It has to be blue before the end of the sprint.

So my suggestion would be, timebox the meeting so you don't spend much time on creating rules and discussing about rules.

Some thoughts, modern IDEs have checkstyle plugin to alert people when some rules have been broken the team can agree just to check during the code review before they commit. That helps for my team as well.

Answer 3

• Any IDE that doesn't make you develop faster isn't a tool, it's a boat anchor. Throw it overboard and never look back.
• If you already have a CI infrastructure, use it from day 1. You'll thank yourself later, even if you really succeed in throwing out your prototype code.
• Conversely, do not waste time setting up a CI system if you don't have one. The cost is too high, and you really do hope to start over from scratch.
• Start with a VCS on day 1. Period.

Answer 4

I would suggest start implementing the concept of a unitary work environment once the team's velocity starts to stabilize. This may cause some technical dept at the start of the project, but there is always technical dept at the start of any project. :)

I usually have success in allowing the self-organizational aspect of a team to come up with something which is appropriate for them and their requirements. Basically present the team with a description of a problem, like Jenkin Builds failing, and providing them with the opportunity to 'fix' it.

This usually results in a bare minimum implementation of a solution, just like Zachary Yates mentioned in his answer.

I would note it would count in your favor if you have someone of a senior technical skill level / position providing some subtle guidance, just to help the team to not get weird with what they decide to go with. :)