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.

- 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.

- 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.

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.