Monday, August 22, 2011

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?

Friday, August 5, 2011

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?

Wednesday, August 3, 2011

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?

Friday, July 29, 2011

The implicit bias with flexible working hours

I'm a big fan of flexible working hours. I'm one of the few that gets in early and leaves early due to family commitments. I do seem to be in the minority as most techies seem to prefer to come in late and leave late. I also don't have to stress about being late, because my employer knows that I'll make up those hours.

One problem I've discovered being an early starter is around crunch times. I've found that there's an there's an implicit pressure and bias by the team to have everyone working late until the same time. This isn't so much of a problem for late starters, but for early starters they may have already put in 2 to 3 hours of work before others arrive.

All I ask for is teams with flexible working schedules accept that around crunch times early starters might stay late, but not as late as their later starting colleagues.

Thoughts?

Wednesday, July 27, 2011

Is the daily standup good for the brain?

A few days ago I came across an article on Psychology Today called Is Your Brain Asleep on the Job? which talks about how doing the same thing day in day out uses the same neuronal pathways over and over, eventually forming ruts. It goes on to discuss ways of waking up your brain by challenging it, but right at the end of the article I came across the following quote:
Another way to wake up your brain is to create short-term goals for each day (or task). These tell your brain what you want it to focus on, bringing it to fuller attention. Your brain likes having a set of concrete actions to perform. That's why having and reviewing a list of short-term goals, and the tasks required to meet them, works so brilliantly. Your brain happily signs on as your taskmaster, but it's up to you to create the tasks that matter and to keep your brain alert and focused on achieving them. It works because goals wake up "sleeping neurons" and strengthen and increase the firing of neuronal synapses
This instantly made me think about the daily standup. Every day we create short-term goals and provided we stay focused we are helping our brains.

Monday, July 11, 2011

Social networking and self promotion

I'm a mixed bag of conflicting thoughts and emotions.

As far back as I remember I've had an intense desire to fit in. I'm very sensitive to established rules within a community or group whether they are written laws or unwritten social contracts. At times I try too hard to fit in which makes me seem needy or annoying (please let me know if I come across that way). Now mix that with the feeling of always being scrutinised in everything I do.

At the same time I feel the urge to rebel. So I rebel in small ways whether that's my choice in food or music, or sometimes my appearance. Also if I don't agree with something that's going on I generally remove myself from that group silently rather than going along with it.

This makes my choice of being a Scrum Master interesting, as I help teams establish their own social contracts but at the same time fight against established rules within the wider company that are detrimental. More about that another time I think.

Fortunately over the last few years I've decided to go my own way rather than conform.

So what's this to do with social networking and self promotion?

Within each of the different social networking communities there are social contracts on how to behave. The threat is that if you don't conform to these rules you run the risk of being ostracised. Some have attempted to codify these social contracts to help others not to break the rules.

One rule that is fairly consistent is not to promote yourself too much. There are even percentages of self promotion versus other activities. Even these can change within sub-communities and it also seems to depend on who you are as to how much you can get away with. One example that's given is not to promote your blog too much.

Due to my strong sensitivity to established rules I get intense feelings of guilt when I try to do any self promotion what so ever. I agonize over posting a link to one of my blog posts, or adding a hashtag, for ages before I do it. I see others who promote their own blogs and I wonder how they get away with it. So what is the magic balance? Frankly I don't know, but I do feel like some level of self promotion is key as we all need feedback to refine our ideas and thoughts.

I now see my blog as being an extension of myself and I have something to say. If you want to unfollow me because of that then go for it. Isn't having something to say one of the points of social networking?  Why should it matter if its in 140 characters or in an entire blog post.

In the future I'll be promoting links to my blog more often, but I'll try not to be too annoying (that latter part is the residue of me still trying to fit in :-) ).

I'd love your feedback. Do you agree or disagree? Let me know what you think.

Note: this entire article was written with a light heart and with no negative emotion involved

Monday, June 20, 2011

The Agile manifesto, Asperger's syndrome & high functioning autism

Since January my son has been going under an evaluation for autism. This has been a lot to come to terms with, but I'm on the road to acceptance. Right now we don't know where on the autism spectrum he is, but whatever happens he's going to struggle through school and the work place.

During a home visit our health coordinator made a comment that caused me to sit up and think. She said that there are a higher number than average of people with high functioning autistic (HFA) or Asperger's syndrome in IT jobs. These are generally highly technical jobs where they don't have to interact with others too much.
This got me wondering about how people with an ASD would view the Agile Manifesto. I can see how three of the principals could cause extreme anxiety.

If you aren't familiar with HFA or Asperger's syndrome, here's a high-level overview http://www.webmd.com/brain/autism/high-functioning-autism.  From here on I'll be referring to both of these as Autism Spectrum Disorders (ASD).

People with ASD’s are characterized by a triad of impairments in the following areas:
  • Impairments in social interaction, including difficulties relating, sharing and forming relationships with others.
  • Impairment in social communication, including difficulties interpreting and expressing verbal and non-verbal communication.
  • Impairments in imagination and social understanding, including difficulties with imaginative play, pretending, planning ahead and tendency toward detail focus at expense of global understanding
The above description is from http://www.grampianautisticsociety.co.uk/about.html

Now here are the main principals of the Agile Manifesto:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
As you can see there's a bit of a mismatch between the 1st and the 3rd principals of the manifesto and the triad of impairments.

It seems to me that a common sentiment within the agile community is that, people who can't collaborate within a team really shouldn't be part of a high-performing agile team. I had this view myself until recently. These people are generally talked about as crusty old programmers, with poor hygiene, who just want to sit in a basement developing software and don't want to interact with other team members.

People with ASD are generally average or above average intelligence. So my question is, as part of creating a better way of developing software have we inadvertently shunned people who aren't neuro-typical? ASD is only one disorder that could affect the functioning of a team another that comes to mind is ADHD.

I'd love to hear from your thoughts. Also if you've had a team mate or perhaps you have an ASD or ADHD yourself, I'd love to hear about your experiences.

Anyway I'm still learning about this confusing world, so feel free to correct me where I'm wrong.