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?

The daily standup and flexible working hours

As mentioned in my post about The implicit bias with flexible working hours, I'm a fan of having a certain amount of flexibility in working hours.

Though some companies can be uber flexible and allow people to set their own hours, there are several limitations. The one I'm going to focus on today is with the daily standup meeting.

I'm going to assume that you're familiar with the daily standup meeting so I won't go into it in detail. In case you're not here's a great article about it. The Daily Scrum Meeting

The daily standup meeting happens every day at the same time, but if a team member turns up late then it isn't as effective. That team member won't hear what everyone else has done or will do, and won't provide that information to the team.

If the standup meeting time always changes to happen after all team members are in the office, the team is prone to forget to do it.

Naively in the past I've performed two standups, one with the team members that are there and one with the individual who comes in later. This is not a good idea and didn't really benefit anyone.

If you do allow employees to set their own working hours, I suggest a slight change. Let everyone know that they are expected to attend standup everyday. Talk to the team and ask them to agree on a time for the standup meeting. Also explain the reasons why it's important for all team members to attend.

My personal preference is for companies to set core working hours where everyone is expected to be in. I've found that this gives some flexibility, but also gives the team a good amount of time working together. The hours that all team members are in the office are the most productive.

I'll be going into more depth about core hours versus employee set hours in an upcoming blog post.

Thoughts?