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?

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?

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.

First impressions of CoffeeScript

I first heard the word CoffeeScript banded about by a few people in the agile circles I run in a while ago. I heard that it was a language that compiled down to JavaScript but was more succinct and had better syntax. This instantly peeked my interest.

I've been coding Javascript for about 14 years and frankly I've always hated it. The advent of JQuery has made it more bearable, but it hasn't changed my feelings about JavaScript and don't get me started on JavaScript inheritance :)

I figured that anything that could improve on the syntax would be a good thing, so I decided to give it a shot.

Scott Hanselman recently posted about a plugin for VS.NET, called Mindscape Web Workbench, which allows realtime compilation of CoffeeScript to Javascript so I installed it and was off to the races.

Whenever I learn a new language I like to reimplement code I have written previous. This allows me to get the syntax down without worrying about logic. In this case I decided to rewrite a JQuery plugin, in our product at work, that I had worked on in the past.

I have to say that after some initial high hopes and early wins I'm rather disappointed.

I'm disappointed because the CoffeeScript syntax isn't too far removed from the way our Javascript is structured already and only slightly more succinct. We make heavy use of Knockout which is an MVVM framework. I'm not going to go into depth about Knockout, but if you want more information you can visit the Knockout website.

Here's an example of how our Javascript models are structured:

var exampleModel = {
    selection: ko.observable(""),
    text: ko.observable(""),
    isEverythingEntered : function () {
        return this.text().length > 0 && this.selection() > 0;
    }
};

Now here is that same code in CoffeeScript:

exampleModel:
    selection: ko.observable("")
    text: ko.observable("")
    isEverythingEntered ->
        this.text().length > 0 and this.selection() > 0

As you can see, they are very similar. This is a contrived example, but the more complex ones aren't any different.

The pros as I see them so far are as follows:

• No more missing semicolons at the end of a line. Though Firefox and Chrome are robust when it comes to malformed JavaScript, IE isn't and will throw script errors if there's a missing semicolon's. Same goes for additional commas at the end of a block.
• -> looks far nicer than having to write function() { }

The cons are as follows:

• It relies on tabbed indenting. The rest of our codebase is space indented. At this time I'm not sure if this is a problem with CoffeeScript or with Mindscape Web Workbench.
• I'm not a fan of the if then else syntax instead of a ternary operator.
• Large Javascript files cause VS.NET to lag a bit. This isn't to do with CoffeeScript, but to do with the plugin.

Right now I'm not sure the pros are enough to adopt CoffeeScript.

I'm curious what your experiences are. Am I missing something?

Is it easier or harder these days for kids to get into software development?

I'm going to show my age for a second and post my first crotchety old man post. I first started learning how to program almost 30 years ago when I was six years old. I don't claim to have written anything interesting at that age, but it started me on a life long journey. Fortunately I had access to something that kids don't easily have access to these days, a built-in programming language for their computer.

When I was six my parents bought my brother and I a BBC B Microcomputer with a separate tape drive and a couple of games. I instantly fell in love with it and would play games for hours. This isn't to dissimilar to kids now but there was one thing that changed everything for me and that's boredom.

Even though I loved playing the games I had I got bored with loading them from tape. This was a long and error prone task, I'd often have to rewind and press play again and again to get a particular game to work. After a while I decided to see what else the machine could do, but the only thing I had was the built-in basic interpreter available on the command line. So I experimented and failed, but learnt a lot by trial and error.

These days most kids have the ease of loading games on demand and there's no lack of games available. You don't even need a computer anymore. Does this lead to a lack of inquisitiveness of what the underlying platform can do?

Yes there are plenty of kids who want to write computer games, but how many have the resources to do so? If you're coding on a Windows platform until a couple of years ago you'd have to fork out for a full version of Visual Studio. Fortunately there are free express editions of Visual Studio available and have been since 2005. How many kids know about this though? Should Microsoft bundle it with all version of their operating system?

There are other alternatives, free downloadable compilers or interpreters for various programming languages. Another option is to install Linux and use something like gcc or g++, but these options require fore-knowledge.

Anyway these are just some random observations I've made over the years and may not be valid anymore.

What do you think? Am I wrong?

Working until the eleventh hour of the sprint

Over the years I've seen many types of team. Some teams believe that they have to cram as much in to a sprint as possible and work up to the 11th hour to get it all done. I used to think that way too. This can lead to, amongst other issues, the team working too all hours on the last day of the sprint. This is especially true if there have been unforeseen issues.

If you're able to do that successfully each sprint then more power to you, but I prefer a slightly different approach.

Though the term sprint suggests that we should hurry though as many stories as possible (while meeting the definition of done), I view the sprint as agreeing to a set of stories and creating them the best way you can. i.e. making them awesome (I know that sounds a little cheesy but couldn't think of a better word).

The approach I prefer is to build a little slack into the sprint. This means that the final day can be used slightly differently.

A little slack gives the team some time for innovation and learning, plus allows preparations for the sprint review. It also gives a little break from the constant slog.

Some people may consider this waste as it's time that could be used to potentially work on more valuable stories, but I look at it as making the product and the team more awesome.

What do you think?

Software development career tip: Find yourself a mentor

A few weeks ago someone asked me the following question:

If I was to offer one piece of advice to someone considering becoming a software developer, what would it be?

At the time I answered that they should expect to never stop learning. Things in the software development world are always changing and if you stop learning you can easily stagnate.

Though I still consider that good advice if I'm asked that again I think I'll change my answer. My advice is simply:

Find yourself a mentor.

Usually a mentor will be a more senior developer, tester, agile coach etc within the company you work for. I know it's hard to ask for help, but don't be shy. Speak up and actively ask for mentoring.

I never had a software development or agile mentor. i.e. someone to take me under their wing, help point me in the right direction. I've mainly learnt everything by myself, via an occasional course and through talking to colleagues. That's not to say I don't value any of these methods, it's just I feel that being mentored accelerates learning.

After being a mentor to other developers, I've seen how quickly they've learnt techniques that I took many years to even discover and use properly. This plus their own self learning, eventually allows the student to surpass the master.

Though I've implicitly known this for years, I've only just recognised it and I recognise that I also could do with a mentor myself when it comes to coaching agile teams. I'm kind of using forums and social networking to fill this gap, but I don't feel like it's quite enough. If anyone wants to help me out let me know ;)

I sometimes wonder where I'd be if I had had a mentor throughout my career, but that sort of thinking is counter productive. Does it upset me? Not really, it's nice to see others build on the knowledge I've bestowed upon them. If I'm really honest I sometimes have a twinge of regret or jealousy, but it's fleeting and I'm only human.

What are your experiences in being a mentor or a mentee?