Wednesday, October 19, 2011

Process smell: Hardening sprint

Many people have discussed a hardening sprint in the past, some for and some against. I'm definitely in the latter category.

I've been in teams that have haven't had them and ones that have introduced them.

Hardening sprints tend to get introduced for the best of intentions. The team has spotted that they are having problems with quality and want to do something about it. Great, but the first thing that generally comes to mind is to do lots of testing before every release. This fixes the symptoms but not the underlying issues. Also what happens if you have to release unexpectedly? These underlying issues really need to be uncovered and dealt with, but that isn't the focus for this post.

Hardening sprints point to a process smell. The team should be dealing with their quality issue as the code is being written, not well after. There should be a whole team and company commitment to quality. Having these sprints can cause us to defer quality until just before release. It also breaks the completed stories should be potentially releasable rule.

There are numerous things a team can try without resorting to a hardening sprint.  I've listed a few below:

Take a look at implementing TDD.
Have testers and developers collaborate more as the code is being written.
Pair test.
Have acceptance criteria before planning which form the basis of acceptance tests.
... and more.

Do you have a hardening sprint before release? What are the benefits from having one?

Saturday, October 15, 2011

Personal ideal working hours vs team working hours

Ideal working hours are the hours during which you are the most productive. This can be at any time of the day. For some people this time is in the evening, for some the morning.

The challenge comes when balancing your own ideal working hours with those of the members of your team. If you are in a truly collaborative team, the most productive time is when everyone is in the office.

Some companies completely disregard ideal working hours and mandate that everyone be in the office between certain times. Others allow everyone to set their own working hours. The former sacrifices the individual for the team and the latter sacrifices the team for the sake of the individual.

Like everything else in life I believe there should be some balance between these two opposites.

An interesting discussion to have with your team is around each persons ideal and then setting core working hours based on that discussion. This should allow some flexibility for the individual and established team time too.

Again like everything else in life, you're not going to always be able to please everyone.

As a final point, sometimes an individual may have to sacrifice their own ideal working hours due to their personal situation. This us true in my case, when I work best in the evening but for my personal situation it's best that I start work early in the morning.

What are your ideal working hours?

Wednesday, October 5, 2011

ScrumMasters: if you're stuck, ask the team

Sometimes being a ScrumMaster can feel a little lonely especially in a small company, but you are not alone. You're there to help the team, but the team can also help you. Sometimes is feels like you have to have an answer to everything, but no-one is expected to know everything.

There will be times when you get stuck. If you do, ask the team for help.

Today our team had our bi-weekly retrospective. Going into it I felt unprepared as I couldn't think of a particular focus area. I asked the team beforehand if there was anything they wanted to focus on, but no-one could come up with any ideas.

I'm not a big fan of doing a general retrospective as they can be pretty scattershot and don't really do a deep dive into anything. Instead we started out with a brainstorming session on ideas for a retrospective focus. After some time and silence team members suggested a few topics. I decided to add one which was basically about generating focus ideas. The team voted and agreed on my focus idea. From there we generated some great action items around collecting more data that we can focus on. Amongst other things we're going to capture information about events within the sprint as they happen. We're also going to start collecting each team member's mood rating on a daily basis.

The team recognised the fact that a clear focus area isn't always obvious, especially if the sprint has gone well. I feel that the ideas that were generated will go a long way to improving our retrospectives in the future.
The team was able to help me on something I was stuck on.