We recently decided to review all code produced by our team. By our team I mean the team which I’m currently coaching. I’m really happy that it wasn’t actually me who suggested this but it was one of the latest additions to the team. This senior developer had in his previous job used a tool called Review Board with good results. Good thing was that one of the other teams in our company had actually taken this tool in use already earlier so only things we needed to do was for all team members to signup for an account and ask Review Board admins to create a group for us.
I was really amazed, it took less than two hours to get all developers (and two TA engineers) to start using the Review Board. First reviews were made already during the same day.
We use Review Board with SVN, so the process goes like this:
- Developer does the changes to the codebase locally
- Developer runs svn diff >changes.diff in his local working directory
- Developer opens Review Board front page and clicks a button to create a new review request
- Developer writes a short explanation and uploads the diff of changes to Review Board
- All other developers get e-mail that there’s a pending review
- Developers go and read through the review request and give comments
- When enough “Ship It!” comments received, original developer commits the changes in and closes the review request
The process is still fairly light so it gets followed. In the beginning we had some problems, one developer didn’t put all his changes in RB, but committed some “obvious” changes directly. Also in the beginning the review requests were rather large so it was really laborious to review the changes. Soon people learned to not only put smaller review requests but also develop in smaller pieces.
After a while, the developer who originally came up with the idea of taking Review Board in use, started disapproving all review requests where there was code without unit tests, unless there was a very good reason for those missing. As a result, we now get decent size changes covered with unit tests. And this is good.
As I’m now working as a Scrum Master for duration of one sprint, I decided I could try some different ways of working. I recently started reading Lasse Koskela’s Test Driven, which I found really inspiring book. So, I decided that this time we’re going to write all tasks as tests. No tasks like “Implement method XYZ of the Foo API…” were allowed, instead we had tasks like “When this input is given by the user on this dialog, client should call method XYZ of the Foo API…”
Nobody objected with this style of planning, although I saw few really puzzled faces around me… Unfortunately we started the sprint with three days of Stop-the-Line due to too high (>30) amount of open defects (or mistakes as some might say) so we only got to start the actual sprint work today. Let’s see how it goes, I’ve got high hopes…
I’ve been working as a improvement coach in one of our teams for about nine months now. I’ve been mostly coaching the developers in the team, but as always the improvements usually affect the whole team. I’m fairly soon exiting the team in order to do improvements somewhere else in our company and my boss had a wonderful idea that the last two weeks I’m in the team I would work as the Scrum Master.
There are several reasons why this is a good idea:
- I haven’t been a Scrum Master in way too many years
- The previous Scrum Master of this team left on maternity leave few weeks ago
- New Scrum Master is still learning her role and could benefit in seeing how things can be done differently
- I’ve got a chance to push the team and be a hard-ass for the PdO 🙂
So far my journey as a Scrum Master didn’t start that well… Sprint planning yesterday went fairly well, we did a Test Driven Sprint Planning session, more about that later on. When I asked for “finger feedback” I got all fours except one three. Fair enough. Anyway, the reason for not that good start for the sprint is that we’ve got too many bugs open on the technology area we’re currently working. And because of that, there’s a Stop-the-Line in action until the amount of open bugs drops under bearable level. So we actually haven’t even started the sprint yet, we’re still paying quality debt introduced in the earlier sprints (by our team and several other teams as well).
One thing which I noticed right from the day one as a Scrum Master was that there’s A LOT of things to do. Most of the things are small but important so they easily take the whole day. Guess it’s goodbye for coding for the following two weeks for me.
Totally forgot this… I visited Tampere Goes Agile event last September and did a session about Git there.
I liked the event a lot and not only because it was free (as in free beer).
My session about Git was in two parts and we had a lunch in between them 🙂
During the first session I talked about what Git is, how does it compare to other version control systems and how Git helps you when you’re developing software with agile methods. During the second part we did some technical hands-on exercises with Git to see what are the benefits of using Git. I hope the attendees got what they need to convince their bosses and colleagues to start using Git.
The slides are available in Speaker Deck.