Saturday, December 17, 2011

The role of a tech writer on an agile team

There is a common myth surrounding the agile community that being agile means no documentation. This is a huge fallacy. The agile manifesto states clearly that we value working software over comprehensive documentation. It also states the following:

"That is, while there is value in the items on
the right, we value the items on the left more."

For me as long as the documentation is useful and will be read we should still do it. This might be user manuals or supporting sales material. Whatever the document it's often a good idea to have a technical writer on the team. Some clients do require  comprehensive documentation even if it's just a checklist item. If they can't be dissuaded and they are willing to pay for it then I say do it. So yes we do want a writer on the team.

One mistake I've seen teams make is to start the documentation for a story after it's been completely developed. The theory is that this prevents rework, but the side effect is that there's often documentation left undone at the end of the sprint. The tech writer gets frustrated due to the lack of time left and can feel that it's their fault that the sprint commitments weren't met. This can lead to the documentation to be written one sprint behind the development. What's the big deal with that? Well if there are any questions for the developers they're already focusing on something new. These questions can disrupt the developer through causing them to dredge up the memory or go back to the code to remember what they did.

So how do we fix this? One way is to have the tech writer attend all of the important design meetings with the developers and testers. They should get enough information to start work. Sure there maybe some rework and screenshots that need to be taken can't always be done until the end, but you've now lessened your risk for not getting everything done. If the writer has any questions they can ask the developers while everything is fresh in their mind. Another strategy is to pair the writer with a tester on the team. Testers are great at seeing all of the intricacies of the story and can communicate that to the writer.

I'm interested to hear about how other teams deal with technical writers on their team. 

Friday, December 16, 2011

Android Contact Storage issues when syncing Twitter and/or Google contacts?


For the last 6 months I've slowly been running out of phone storage space on my HTC Desire. This means that I've been hovering between 3 and 16 MB free for a while. Unfortunately the HTC Desire only has 128 MB of internal storage and as soon as I go below the 15 MB mark my phone stops syncing its apps.

Until recently I didn't realise where the space was going so I tried a few things, short of rooting my phone, to fix it.

Firstly I made sure that all apps that could be moved to the SD card were moved. This helped slightly but I soon realised that it didn't help as much as I had hoped, this is due to the dalvikCache. Even though an app is on the SD card, Android creates a dalvikCache instance of it on the main phone storage which is usually smaller than the original but not always by much.

Secondly I deleted all applications that I didn't need. Then I started to delete applications that I do use in descending priority order. Three days ago I was down to only having the apps that came loaded onto the phone, the Google+ app and DiskUsage. Blogger, Facebook, Evernote, Feedly and Twitter had all been uninstalled.

This was the last straw and I made a last ditch effort to find a solution, or I'd go ahead and root my phone.

Though I'd searched for solutions many times before, this time I came across an article that gave me some hope.

Clear Storage Space on Your Phone Without Rooting

This article mentions a Contact Storage bug which causes it to bloat but doesn't give a great amount of detail. Mine was around 50MB so I figured that this post might be onto something. Long story short, I tried the solution listed in the post but wasn't able to restore my contacts other than the ones that were saved to my phone as opposed to my Google account. What this did allow me to discover was that I had over 1200 contacts synced to my phone from Google+ each just containing a URL to their profile. I believe that this could well be the reason why my contact storage was so huge rather than a bug.

What I ended up doing to fix the issue was as follows:

1) I uninstalled Google+
2) Turned off all app syncing within Accounts & Sync
3) Deleted my Facebook for HTC Sense account entry from Accounts & Sync
4) Cleared my Contact Storage
5) Restored my backed up phone contacts to my phone storage (not the 1200+ that were attached to my Google account)
6) Verified that the small amount of contacts had been imported correctly
7) Added a new Facebook for HTC Sense account and made sure that Sync contacts was on.
8) When the Facebook sync was complete, I verified that there were entries in my people app and re-linked accounts appropriately
9) Reinstalled all the apps that I wanted.
10) Turned on all the app syncing again, except for Sync contacts for my Google account and my Twitter account.

Note: I did lose some contacts so I don't recommend you do this yourself

When this was all done I had most of my contacts back and Contact Storage was down to about 2MB in size. For now I'm not going to sync my Google or Twitter contacts to my phone as I have between then 1900+ people. This will hopefully give me enough room until I upgrade my phone in 8 months.

I'm curious of any other heavy users of Google+ or Twitter have experienced similar problems.

Wednesday, December 14, 2011

Has the ScrumMaster role evolved due to a vacuum in line management?


If you look at the ScrumMaster role you'll see that they are there to serve the team. They are there to guide the team to improve themselves and the way they work. They are there to protect the team from unhelpful distraction. They are there to help the team overcome any obstacle that is preventing work from flowing smoothly. They are there to help the team self organise rather than telling them what to do. They are there to help the team deal with conflict and finally they have the authority from management to do all of the above. I could go on, but these are the most important parts of the ScrumMaster role.

The thing is all of these responsibilities are all things that a great manager does, so why does the ScrumMaster role even exist?

To me this implies that there are managers out there that don't realise that the items listed above are part of their role. This is especially prevalent in IT where managers have been pulled from the ranks of the company's senior engineers and given some management training. This isn't a bad strategy as managers should have the experience in the field that they are managing, but I'm of the view that management is something you need to have a passion for rather than just the next step in your career ladder. If you don't have the passion you won't necesarily drive yourself to improve continually. Good ScrumMasters have the passion and drive themselves to improve as well as their teams.

Some other posibilities as to why the role exists is due to the inherent lack of trust of management and company's with a culture of fear. The team tends to trust the ScrumMaster more as they have no authority over the team other than that agreed to by the team. In addition, as I mentioned before, they are responsible for protecting the team from undue distractions.

My final thought as to why the role came about is due to consistency. Management styles differ greatly between people within an organization or even the same department. Add in the fact that in larger organizations, managers change every few years which can cause the way the team works to change drastically. With a ScrumMaster you know what you are getting as the responsibilities are pretty clear. Yes each one may do things slightly differently but the core should be the same.

Of course the ScrumMaster is there in another capacity and that is of a pseudo project manager, but this is needed less as the team self organizes.

I'm not trying to bash line managers here, but I do believe though that both roles should be very similar. I also believe that both roles can work together to achieve great results.

I'd love to hear your comments about my post. Do you agree or disagree? Have I missed something?

Thursday, December 1, 2011

The merits of best practices

For many years now I've had a dislike for best practices. This isn't the fault of the best practices themselves, but because people adopt them without thinking just because they've been told that they're best practices. I'm far from blameless in this regard too.

My view is that the merits of adopting should be questioned before proceeding. Unfortunately the problem with best practices being blindly adopted isn't going away no matter how many times myself and others talk about it. With that in mind I propose a new meta best practice:

Evaluate the merits of a best practice before implementing it.

Feel free to evaluate the merits of the above :)

How do you feel about best practices

Wednesday, November 16, 2011

Why I blog

I started writing this blog post on the above topic earlier in the year and had almost finished it, but I was never happy with the result. Now my original reasons don't apply anymore so I thought I'd post about what's changed in a few short months.

The original reasons I started my blog were as follows:

1) putting down my thoughts in writing helps me solidify them.
2) to get feedback from others in the community.
3) to let me review my previous thoughts and see how I have changed over time.
4) to improve my writing skills.

Overall it's been a positive experience and I don't really have to self promote it anymore, but one thing has been bothering me and that's the amount of feedback I've received from the community.

If you go back through my archive you'll see a number of comments but compared with the site traffic it's a small drop in the ocean. Don't get me wrong, I thoroughly appreciate everyone who has taken time to comment but I'm craving more discussion so that I can learn.

Moving on to the present. Though my original intents for blogging are still valid, these no longer apply to the blog itself. Since July, Google+ (G+) has been my substitute for my blog. When I post there, I am closing the feedback loop considerably and am getting more feedback than I have here. I'd love to be proven wrong about this but I feel my time is best spent posting on G+.

Now onto my current reason to blog. Basically I'm still using it as a place for my thoughts, but the content I'm creating is replicated from G+. I'm not doing it for every post, only the ones I want to highlight to others. This highlighting is one thing that G+ doesn't do well.

I'm interested in what others are doing with their blogs. Do you still blog? What are your reasons for doing so?

Sunday, November 6, 2011

I don't build software I create it

This title might seem like pretensious nonsense to some or that I'm splitting hairs, but bear with me and you can tell me whether it is/I am in comments below.

I'm a great believer that the words we use form the way we think about things. With that in mind, I want to state that I don't build software, I create it, I write it, I design it.

I use these words to describe an activity that is extremely creative. We don't lay down bricks and mortar to a predefined pattern or build a car which has already been designed and tested, we take ideas from our clients and turn them into reality.

I don't see creating software as construction, it has more in common with product design, and research and development.

To me when looking at a well designed, highly maintenable application I see the beauty, creativity and art behind it.

Developers themselves are generally creative people. How many do you know that play music, write books, do photography, etc?

For a long time software has been stuck in a construction metaphor. I think it's time to move on.

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.

Wednesday, September 14, 2011

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?

Tuesday, September 6, 2011

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?

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.

Friday, June 17, 2011

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.

Thursday, June 2, 2011

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.

Wednesday, May 25, 2011

Managing activity transitions through use of rituals

Last night I went to a fantastic seminar for parents of children with  behavioural challenges. The speaker was very engaging and gave us a lot  of great information and techniques we can try out to help diffuse challenges as they arise.

Disclaimer: I'm not a behavioural psychologist. This is just my understanding based on the aforementioned seminar and my own observations.

I'm not going to write about all of the topics covered as there were many and I couldn't do them justice. I'm just going to focus on something which struck a chord with me and some behavioural observations I've made in the work place. That is how people manage their own transitions between day to day activities.

So what do I mean by that?

Children, especially those with special needs, can get very anxious when transitioning from one activity to the next. This can be as simple as coming home from school or coming inside from playing in the garden. These transitions happen many times a day and unmanaged can increase anxiety levels with each one. This can manifest itself behaviourally in numerous ways including, but not limited to, melting down, wanting have an argument or violence.

The speaker relayed an interesting example from his own life. He noticed that his son, who is neurotypical, would always pick an argument after he stopped playing on the Xbox. This would only happen for about 15 minutes then he'd be fine. After recognising this they worked out a transition strategy.

One of the suggested way of handling this is by having a ritual between transitions. This helps reduce the anxiety and helps prevent behavioural issues. This should be quiet, perhaps with some food, so to reduce any unneeded stimulation.

So how does this apply to us adults in the workplace?

As adults we have generally figured out ways to manage our transitions between activities without even knowing it.  How many of you have a ritual when you get in the office, but before you start working? When I get in to the office the first thing I do is get a coffee, then I read a few blog posts. After about 15 minutes I can get down to some real work.

I'm suggesting that adults may not manage these transitions as well as assumed under certain circumstances.

I've noticed that my own anxiety levels increase when I go rapidly from one different activity to the next. For example, going from a video conference straight into coding, or leaving the office immediately while in the middle of an intense task.

Going forward I'll be looking for ways to manage these transactions through the use of ritual as to lower my stress levels. I'm also studying my own working patterns to see how I currently handle them.

I'd love to hear others thoughts and experiences.

Monday, April 25, 2011

Don't use Scrum because it has no technical practices

Spend enough time in the agile community and you'll hear someone make the above statement at some point. This is normally referring to the fact that Scrum doesn't make an explicit recommendation to use practices such as Test Driven Development (TDD) or Continuous Integration (CI) etc.
To me this sounds like a way to rationalize a decision not to do Scrum. That's their decision, Scrum isn't for everyone and it's not the only successful way to be agile (XP, Kanban etc). I just don't think the above argument is a valid one and shouldn't be used to sway someone in favour of another agile methodology.
Scrum doesn't need to explicitly outline these practices because it's a framework that can be used outside of software development as well as within. When done well it implements all of the practices and values, whereas some of the technical practices might not be right for your development environment.
I'm not saying that Scrum practitioners shouldn't use the above technical practices I just don't think that they need to be mandated (I personally recommend TDD, CI etc for my teams where appropriate).
Also because Scrum is a framework it gives us the flexibility to use any current or emerging practices, technical or otherwise. In fact most scrum practitioners I've spoken to encourage people to actively seek out and experiment with other ideas provided that they don't conflict with the Agile Manifesto or Scrum values. This was also mentioned in a Scrum Alliance update by Mike Cohn where he states that Scrum is not enough.
Finally, practices such as TDD and CI have successfully migrated out of XP and have taken a life of their own. I see more technical and non-technical practices doing that in the near future. This will allow skilled practitioners to mix and match based on the environment.
If you agree or disagree please let me know. I'd love feedback.

Friday, April 22, 2011

SSRS 2008 Quick tip: designing your databinding scheme for a custom charting control

So you've decided to create your own SSRS 2008 charting control. Good luck. The API is highly under-documented and there are very few examples out there. Now that I've got that disclaimer out of the way I'll proceed.

One of the decisions you'll have to make is how to structure your data for consumption by your control.

If your chart only needs a simple mapping scheme, where you consume data as it's returned by the dataset, then this tip won't matter much to you.

If you want to do something more complex then you'll be pleased to discover that any custom chart has similar column and row grouping capabilities that a standard tablix has.

Tip:

When getting your control databinding working create a tablix for debugging. This tablix should have the same grouping setup, including expressions, which also consumes the same dataset. This way you can debug any issues with the data you're receiving and also experiment with new grouping setups and expressions without wondering if there's a problem with your code.

I'm not going to go into great depth about the databinding code itselfu at this stage. I plan to do that in a future post.

Friday, April 15, 2011

Should the Subversion blame feature be renamed?

I had a brief conversation today about blaming people in which the following question came up:

'then why does svn have a blame feature?'

This is a very good question. My feeling is that it's named incorrectly.

I've had a problem with the name of the blame feature since I first came across it. To me it feels like it was inspired by a culture of fear rather than a culture that understands that mistakes are part of learning. Blaming someone isn't going to achieve anything. Sooner or later all developers will be on the receiving end as I've yet to find a person who doesn't make mistakes.

This also gets back to the words we use and how they shape our thoughts. If there's a bug and there's a blame feature, am I more likely to use it to blame a team member for causing the bug?

I have no problem with the feature itself.  I use it to give me a good view of all of the changes that make up a specific file and find out why they were changed.

I'd like to see the name changed, but have yet to think of a good name. What would you name it instead?

[Edit]

One possible alternative that was suggested was Root Cause. Any others?

Thursday, April 7, 2011

Do job titles shape our thinking?

It's well known that the words we use shapes our thoughts. With that in mind, does a job title shape our thoughts into what our role should/should not be based on industry norms?

For example, I've caught myself in the past using my job title to justify not doing a task that I didn't want to do. This is something I've worked hard at breaking myself out of.  I've also seen other developers do the same thing many times. At the time I thought it was perfectly fine, but have since realised that we all need to pull together.

Of course the job title is just one part of a larger thing, the job description.  When was the last time you saw your job description though, if ever?

In every company I've worked over the last 15 years I've never seen my my job description. I'm sure one was given to the various recruiters and I'm sure that if I asked I would have been given it, but I've never thought to ask.

So the job title, some management guidance and discussion with peers have been all I've had to go on.

With this in mind should we start using team based titles, or no titles at all? I'm gravitating towards Product Team Member.

What are your thoughts?

Tuesday, April 5, 2011

Vaguely empowered revisited

Recently I wrote a blog post on feeling vaguely empowered. Though this is still valid I've since realised that the feeling I had was simpler and more powerful.

Fear.

The upshot is that I don't need a meeting with my manager to figure out my boundaries. I just needed the courage to do what I feel is right.

This in turn doesn't put limits on me. Will I step over the boundaries sometimes? Most likely. Could I get into trouble sometimes? Probably.

I must remember to dig down deep for courage if I truly think that it will benefit the team and the company.

Note: the solution in the previous post might be helpful for people that are new to being empowered and are finding their feet.

Wednesday, March 30, 2011

Blog retrospective

Though I've had a blog since 2009 my post frequency has been a little sporadic. About two months ago I made a decision to post regularly. I'm now at the end of the first two months of active blogging.

As part of my serious commitment to my blog I thought it would be useful to do a quick retrospective. I won't be doing this on a regular basis though as not to flood my blog.

Anyway since I want to cast a wide net I thought a simple pluses and deltas format would suffice.

Pluses
- I've been able to post on average once a week.
- I am pretty happy with the finished articles. I feel that I'm getting my point across.
- I have a large number of story ideas that I'm generating.
- I'm feeling more confident about my posts.

Deltas
- I need to decide what my update frequency should be. I'm thinking that weekly might not be sustainable and monthly too infrequent. I'm going to try bi-weekly.
- I should investigate other Android blogging apps as Google's Blogger app won't let me post hyperlinks.
- I need to get better at writing in general.

Feel free to add your own comments below as feedback is essential to improvement.

Monday, March 28, 2011

If it a'int broken...

I have a problem with the phrase "if it a'int broken, don't fix it" (other than it being cliche).  My problem with it is that it gets used often as the final word when someone wants to resist change.

Here's the definition of broken from FreeDictionary:

1.  Forcibly separated into two or more pieces; fractured: a broken arm; broken glass.
2.  Sundered by divorce, separation, or desertion of a parent or parents: children from broken homes; a broken marriage.
3.  Having been violated: a broken promise.
4. a.  Incomplete: a broken set of books.
b.  Being in a state of disarray; disordered: troops fleeing in broken ranks.
5. a.  Intermittently stopping and starting; discontinuous: a broken cable transmission.
b.  Varying abruptly, as in pitch: broken sobs.
c.  Spoken with gaps and errors: broken English.
6.  Topographically rough; uneven: broken terrain.
7. a.  Subdued totally; humbled: a broken spirit.
b.  Weakened and infirm: broken health.
8.  Crushed by grief: died of a broken heart.
9.  Financially ruined; bankrupt.
10.  Not functioning; out of order: a broken washing machine.

By this definition is an untuned or badly tuned guitar broken?  It functions but may not give the guitarist the result they want.

A team or a process may be functioning but may not be optimal. It might require tuning. Retrospectives are essential for agile teams to reflect and discover what needs to be changed. Remember though retrospectives will be next to useless if you don't take action items and follow through on them.

So in short, if it ain't broken it may still need fixing. 

Friday, March 18, 2011

Vaguely empowered

Recently I've had a few mixed feelings about proceeding with some goals I'm trying to move forward with (yes that's a very vague statement :) ). I feel empowered by my boss but I'm also feeling a level of discomfort doing so.

My boss has been fully supportive of everything I've done so far so I'm not being empowered and then having it taken away again.

After reflecting and doing an internal 5 whys, I realized what's been bothering me. It's not clear about what I'm empowered to do. I'm worried about stepping on toes when I come close or overlap other peoples boundaries. I feel vaguely empowered.

In my last company I built my own role after seeing a market opportunity. I was also vaguely empowered, but the difference was I knew my remit as the only person I had to worry about was my boss who was also the CEO. I knew what his strengths and weaknesses were so I knew my boundaries. In my new company I'm still working out what those boundaries are.

Now I know the issue, I can set about fixing it. I'll be talking to my boss about these feelings and work with him to understand where my limits are.

Saturday, March 12, 2011

Motivation and recycling

Nowadays most managers hopefully know that the best way to motivate people is intrinsically rather than extrinsically.  Of course intrinsic motivation is very hard as different people are motivated to do a task in different ways.

Here's an example from my own life, recycling.

The traditional reason to recycle is to save the environment/planet. This is seen by the mainstream media and environmentalists as all the motivation someone could possibly need.

This might sound shallow but that doesn't motivate me to recycle. I don't know why, maybe its such a grandiose goal that I can't relate to it or perhaps I'm rebelling against popular sentiment (which I'm prone to do). I don't know. Yet I still recycle and since moving back to the UK I'm now recycling more than ever.

In Houston we had curbside recycling for corrugated cardboard, paper, certain types of plastic and cans. It was easy to recycle those items, but only those items. It was a pain in the arse to recycle anything else (glass, non-corrugated card, types of plastic outside of the numbers allowed etc).  This compounded with the fact that the local recycling centre was only open twice a week of which only one time was while I was home from work and then only for 4 hours. After a hard weeks work the last thing I wanted to do was go to the recycling centre at a mandated time. This meant that I generally threw the items I couldn't recycle at the curb out.

As mentioned before, since I moved back to the UK I'm recycling more.

The reason is pretty basic the local council makes it very easy to recycle any type of card, plastic food containers, paper, cans, glass, green waste and food. It's just about as easy to recycle as to throw things out so I'm happy to do my bit (I now throw out less stuff than I recycle)

Remember to ask your team member how best they would be motivated. If anyone in Texas would have asked me what would motivate me to recycle more I would have said, make it easier.

Friday, March 4, 2011

Physical vs virtual sprint storyboards

Every now and then the idea of adopting a virtual story board (or a more comprehensive agile management system) comes up in a retrospective.  As new reasons to adopt one come up I explain my reasons not to do so. Of course it's up to the team as a whole to decide.

Until someone comes up with a whiteboard size touch screen that a team can interact with and work with just as effectively I'm not sure I'll change my position.  Feel free to try and change my mind though.
In this age we seem to have the need to put everything we do or interact with into some sort of application. Anything that isn't is deemed old fashioned or inefficient.  I feel that sometimes we throw the baby out with the bath water.  Remember the first value of the agile manifesto:

Individuals and interactions over processes and tools.

With traditional storyboards we have a common place to gather and re-plan everyday, in real time. At the end of planning or daily stand-up we have an updated board that everyone in the team can see at anytime. The visibility of the board helps us be accountable to each other.   Another benefit is that if a team member adjusts the board in some way, the team has an immediate visual clue.  This can get lost in an application where updates can be made transparently.

During planning any member of the team can participate in writing stories, creating tasks, assigning estimated hours and signing up for tasks, rather than having one person responsible.
There's also something to be said for physically signing up for tasks as opposed to doing it in an application.  It makes me feel like I've made more of a commitment.

Recently our managing director likened our efforts to WWII generals with their battle plans. I love this analogy as I feel it fits well with what we're trying to do and makes me feel like she gets it.
Another thing that is hard to overlook is that it's easy to get up and running. All we need is an empty wall, index cards, sharpies and blue tack.

Though I love technology in a meeting it can be a distraction. This is especially true for the stand-up as we need to be focused.  Communication is key and things like computers, mobile phones etc can disrupt our focus.

It's also very easy not to look at a digital board as you have to actively access the appropriate part of the application.

We can also adjust our process, if the team decides to, that might be in ways not supported by an application.  You don't have your processes dictated by a tool.

Admittedly there are some drawbacks.  The ones that I've encountered are as follows:

The board has to be torn down and recreates every sprint.
It's hard for people that are working out of the office to see and update.
Charts such as burndown charts, cumulative flow diagrams etc have to be generated manually.

I'm sure there are others, feel free to comment below with other examples.

The first and last items are really non-issues for me as they don't really take too long, but they are tedious to do.

The second item is a legitimate concern for permanently offsite team members. For those that are working from home for a day I normally suggest that they sign up for tasks before they leave the day before.  There isn't an easy answer to this that I can think of unfortunately. We're going to experiment with a wireless webcam.

Is that really enough of a business case for adoption of a tool? I'll leave it up to you to answer, you can probably guess mine.

[Update]
I've just started taking photos of the storyboard and uploading them to our wiki after the daily stand-up.  We'll see how that goes.

Tuesday, March 1, 2011

Bug wrangling

Many teams have a hard time dealing with how to handle bugs no-matter what methodology they are using.
Teams who are generating a lot of bugs get overwhelmed by them eventually.  This is very stressful and demoralizing.

I've found that initial thoughts are generally around how to manage bugs them rather than why are we getting so many in the first place.  This leads to adoption of things such as bug tracking software, bug cards to be prioritized into future sprints or even a bug squashing sprint amongst others.  Unfortunately when you are in firefighting mode its hard to take a step back and look at fixing the cause rather than the symptoms.

Firstly you need to discover the reason(s) why you are generating so many bugs.

There are few ways to get that information. One way is to, as a team, do a root cause analysis on each bug that comes in.  Use something simple. I like the 5 why's technique.  From here you should be able to find out areas to focus on for a more detailed analysis.

You should also increase your bug transparency. Display your current bugs on cards as an information radiator on a wall, whiteboard etc. Using a tool hides the number of open bugs to a few people, having it on the wall makes it visible to everyone, potentially even customers.

When it comes to bug prioritization my rule of thumb is, make all bugs a priority over anything else.  If it's not high priority enough to do as a top priority, forget about it.

Your product owner should be able to help prioritize.

Traditionally bugs that don't warrant immediate fixing get logged in a bug tracking system and get forgotten about anyway. They get forgotten because they never become high enough priority over stories that generate business value. So why increase your signal to noise ratio.
 
Remember to talk about bugs at stand-up since the team needs to know the ad-hoc work not just project work.

... but I don't have time for this!!

So when will you have time?

If the answer is never then you have a bigger dysfunction(s) in the team. Too many bugs is probably a symptom of a larger problem (and out of the scope of this article). What are your team retrospectives telling you?

If the answer is in a few weeks then consider implementing some of the techniques above slowly. Perhaps only do root cause analysis on major bugs, or get the bugs up onto the wall and talk about them at stand-up.

I'd love to find out other peoples thoughts and perspectives on this issue.

Saturday, February 19, 2011

Quick tip: Linking against appropriate assembly depending on your configuration in VS.NET

Occasionally, while developing a .NET app, I've needed to reference an assembly from another solution from within my current one. Most often I see projects referencing either the debug or release versions directly, but what happens if you want to reference an assembly for the same configuration that your current solution is in? (i.e. referencing an external debug mode assembly while you're in debug mode and a release mode assembly in release mode)

The answer is an easy one, but can't be done directly by the IDE.

Reference the debug version of the  assembly you want to as per normal.

Next right click the project, which you just added the assembly to, and select edit project file. This will bring up the project's msbuild file.

Find the reference to the assembly you just added and replace the text Debug in the HintPath with $(Configuration)

Save and close the project file then reload the project. That's it! Now when you compile in debug or release mode the correct version of the referenced assembly will be compiled too.

NB: this assumes the dependant assemblies are located in Debug and Release folders off of the same parent folder.

Wednesday, February 16, 2011

Microsoft Nokia deal observations from a consumer

I don't profess to be an expert on the mobile industry but I thought I'd post my thoughts on the recent Nokia/Microsoft partnership from a consumers perspective.

Though it seems that Nokia employees and shareholders are unhappy and their stock took a nose dive, I see the switch away from Symbian to be a positive one.

I used to insist on using only Nokia phones from when I got my first one in 97 until around 2003. I not only used their phones but also one of the early smartphones, the Nokia 9110 communicator.

My love of Nokia phones started dwindling when I first moved to the US from the UK in 2001. To say that it was all Nokia's or Symbian's fault would be unfair, some of the issues lay with the state of the US mobile industry. Having to switch from a GSM to a CDMA network didn't help things.

I was disappointed with the phones available for one. They all seemed antiquated compared with the new Nokia phones that had started to come out back home. I felt like I'd stepped back in time.

From a business perspective I can understand why they wouldn't want to invest money in a non-mainstream technology. Still as a consumer I didn't care about that.

In 2003 I switched over to a Samsung phone as they had better options available for the free or cheaper phones. I did have a Nokia again when my Samsung broke and the local Cingular store no longer had one as an option. Unfortunately I didn't find that my new phone was much removed from phones that I'd used years before.

As soon as I got my Blackberry, Nokia phones became completely irrelevant as there wasn't anything available to me that came anywhere near, I.E. offering a phone that could integrate with Exchange for email and calendar, give me a half decent web browser (admittedly I moved to opera mini from blackberry's native one).

After moving back to the UK at the end of last year I needed a new phone. I didn't even consider a Nokia as an option and frankly didn't look. It was between an iPhone or an Android based phone.  I ended up getting a HTC Desire which runs Android (which I greatly prefer to my work iPhone 3Gs).

Looking back at this, most of my disappointment has been with the evolution (or in my view regression) of Symbian as an operating system. Rather than the quality of the hardware which has always been good.

To sum up, the Nokia/Microsoft partnership is a good thing in my point of view. Nokia get a good mobile operating system to replace Symbian and can break with that legacy. It also means that we only have 4 platforms that we need to develop for.

I don't know if this will be enough to save Nokia, but its a step in the right direction.

Would I look at a Nokia smartphone in the future?  My answer is yes I'd be prepared to give them another shot.