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?

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?

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.

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

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.

Don't just review at the end

One essential part of Scrum, that few practitioners argue about, is the end of sprint review. This is a great place to showcase the work completed within the that sprint to any interested parties, but in some teams this is also the first time the product owner gets to see the completed stories.

What happens if a feature isn't quite right, or if we've misunderstood what was wanted? We run the risk of features not being accepted.
Even on a 1 week sprint, waiting until the end to review is too long.

Instead of waiting, collaborate with the product owner throughout development through a series of informal reviews. The earlier you start these the better. By doing this we get feedback earlier, so if something needs to change you haven't gone too far down the wrong path.

Even if you've created mockups its not until the feature starts to become real that we find out if everything is practical or possible.

Frequent informal reviews can this lead to optimizing the created value within the story by producing a better end result. It can also lead to a happier product owner.

Please let me know what you think.

Our move to pair testing

Three sprints ago the team decided that the way were handling testing wasn't working well. There were a number of issues that I'm not going to get into right now, but suffice it to say that we needed to do something differently. I also want to point out that this was nothing to do with the quality of the testing that was being done.

An action item that came out of that sprint's retrospective was as follows:

When a developer has finished coding they should try to pair test if our only tester was available to do so.
This action item was the top most voted for item with regards to how much energy each member had for making this change.

Over the following sprint there wasn't really a wholesale up take with the new idea until the last few days of the sprint. There were a couple sessions that happened before that, but something changed in the last few days that would altered how we viewed pair testing.

Before I move on I'll briefly describe what we consider pair testing.

To us pair testing is performed with the developer, who has written the code for the story to be tester, and our tester. During this session any bugs that are found and are related to the story being tested are fixed and tested again immediately. When the pair feels that the story is good enough to release then they stop. Any bugs that are found that are unrelated are noted down to be added to our bug wall later.

Anyway back to my story.

Unbeknownst to me our tester was in training for two days, three days before the end of the sprint. On finding out, which was the first day he was out, I asked the team how they wanted to handle this situation.

At this time we had a good number of stories that needed to be tested and there was no way we would have made our sprint commitment if we didn't do something.

The unanimous decision was that the developers would pair test themselves.

What happened then was a series of pair testing sessions with two developers. As one of my team mates put it, having two developers test kept them both honest. Also as bugs were being fixed as they were found, we shortened our feedback loop. With two developers testing we probably weren't as effective as pairing with our tester, but when each pair finished they were happy that the result was releaseable. Testing and bugfixing was no-longer taking days, but taking hours. There was little or no miscommunication and if there was it was cleared up immediately.

In addition, an observation I made about my own code was that I wanted few bugs to be found so I made sure it was really ready to test before exploratory testing.

All of this really seemed to bring home the value of testing as a pair to everyone, as well as removing a bottleneck that had been a problem for us. As it happens our tester was ill on the last day of the sprint so we couldn't have waited anyway.

At the next retrospective the team decided that we should pair test on every story and agreed to add it to our team working agreements.

During this last sprint our tester was back and everything is going well.  We still had at least one developer pair testing sessions to alleviate a bottleneck, but that's fine.

Overall I feel that this has been one of the largest improvements, if not the largest, the team has made. That is from a performance and a team cohesiveness level.

I'd fully encourage other teams to try this for themselves especially if there's a lot of to and fro between developers and testers or if testing is a bottleneck.