Skip to content
8 March 2011 / Chris Neal

How to do error messages right

First there was the Fail Whale, but now check out the the 404 error page at Github.

This is not the webpage you are looking for.

To see it properly click here and scroll over the image to get the full effect!

This is how to handle errors nicely. The user experience should cater for the bad things that might happen, and good error handling is a critical in giving users a good experience.

6 August 2010 / Chris Neal

What Ikea has taught me about application development

Last weekend was spent sorting out the kid’s bedrooms. New furniture in, some old furniture out via Ebay & Freecycle, some old furniture resurrected, and plenty of grunting and whinging at seemingly ill-fitting bits of MDF. I must admit, I have a bit of a love/hate relationship to Ikea (other flat pack furniture suppliers are available). But, they are successful at what they do and like all successful businesses they can give some good pointers in how to do things

tiny bit of Ikea construction, courtesy of tilaneseven

My two sons needed a bigger wardrobe, and I had two dismantled Ikea wardrobes in the loft (Aneboda if you’re at all interested). Easy, I thought, just pick the best bits from both and job done.  Unfortunately it wasn’t quite so straightforward.   Although the doors were the same height and width, the sides were different. One of them was deeper than the other, which I only found out after several minutes scratching my head at why the holes for the top were completely out of kilter with the dowels. Ikea must have made them narrower at some point, which makes a lot of sense as a few centimetres shaved of the depth will lose a fair bit of overall weight to the flat pack package.

Next job was to build some drawers (Malm, I believe). A couple of years ago I’d built the same set. This time though it was a much easier process. Although the drawers were the same size and looked the same, building them was much easier. The drawers themselves had been re-designed. Apologies, but I’m going to get technical now. The runner bits with the roller things on, was now fitted around each side so it held the sides and base. This made the side but narrower and lighter, but also held the drawer in better and made it slide in and out more smoothly. The way the backs of the drawers were fitted was also improved.  A number of the parts including (sorry more technical jargon), the twisty round bits that you turn around the bits that are half-screw and half-nail to hold the sides on, were now plastic and not metal. The instructions had been updated, as had the packaging, the bits you needed first were at the top.

Now I’d always thought that once the designers had designed the product that was it, on to the next one and next name. But it seems not, like all good companies Ikea refine and then refine some more. A metal component replaced by a plastic one, over several thousand products will save a lot of weight and reduced shipping costs. The new drawer design coupled with the improved instructions certainly saved me time and effort, and I was definitely more in the love side than hate side of the relationship by the time I’d finished.

They had made the changes to not only improve the product for the consumer, but also to reduce the overall size and weight of the flat packs to be shipped, which reduces their costs. You can learn a lot from others who are not necessarily in the same market as you. Apps can always be refined and improved, and also not just from the user perspective but from the producers/maintainers perspective. Look at the things that annoy you when you use the app/product, but also the stuff behind the scenes that costs you money when you operate or maintain the code. Collate all this stuff, prioritise and then refine, refine, refine!

24 June 2010 / Chris Neal

Test driving the iPad

We’re a doing a couple of iPhone/iPad applications for clients, which means we have a “test” iPad knocking about. The iPad really appeals to me as a home laptop alternative, so I took it home for the weekend to see what the family thought.

My wife’s initial thought was, “Oh dear, here we go again, Chris wants a new toy”! Am I really that transparent? Well, yes,  I am but…

Anyway, back to the review. As Charlie Brooker so succinctly put it:

“At first glance it resembles an iPhone in unhandy, non-pocket-sized form. But look a little longer, and . . Nope. You were right first time.”

It is a bit like that when you first use it. First impression is  “oh, is that it?”.If you have an iPhone it is all instantly familiar and even if you don’t it is very easy to use. My son had his email and instant messaging set up in 5 minutes and he is only 8! But impressions improve once you delve a bit deeper. The screen is lovely as is the fit and finish. It is a bit heavier than I was expecting – you really need to lean it on something when you use it. It is a perfect device for browsing the web from the sofa, answering the odd email and of course playing games. Mail, Maps and Safari give a really rich and satisfying user experience. Games are great, as are photos and movies. You can plug a keyboard in, you can get a usb adaptor, but like when buying a car all these are “optional extras”, and being an Apple device not exacly cheap!

Is it a “game changer” in the way the iPhone was? It is early days and Apple must be really happy with the initial sales and I guess we’ll have a better idea when other similar devices start appearing with a Google or Windows operating system. One thing is clear and that is the larger screen really gives developers a huge amount of freedom. I’m sure we will see apps appear on the device that change the way people think about how you can interact with a computer, I think the potential is huge. Our developers are certainly excited about the possibilities. Whether that will be restricted to consumer applications, or we start to see enterprises taking up the device will be very interesting. It is the sort of device where you can imagine a remote sales force using for financial planning meetings with customers at the home. Flicking through snazzy pension forecast graphs etc. Mind you I’d hate to be the guy trying to persuade the FD to purchase 400 iPads for the Sales team!

Which brings me to the price, it is expensive, and as usual in the UK it is considerable more expensive than anywhere else. People need to carefully consider if they need a 3G connection (probably not not if they are only likely to use the wifi at home), or can plug in an external hard drive and do with less storage.

Personally, I really liked it, but I’d still keep a laptop. My wife also, grudgingly, liked it but is tied to a real keyboard so I’ve got a bit more persuading to do before we can get one!

The kids loved it at first, but then found it very frustrating when trying to play games on their favourite websites. Lack of Flash support is a major annoyance. If Flash can run on a Mac why can’t it run on an iPad or iPhone? I think we all know the answer but in the short term it is the users that suffer. I know things will improve as HTML5 gets wider adoption and we see more websites move away from Flash. In the meantime it is irritating although I’m sure Apple will make plenty of money from the games that will appear in the App store! All my 3 children liked it though, and it was amazing to see how quickly they picked up how to use it.

Last word, I will leave to Fake Steve in his open letter to the people of the world. Genius!

11 June 2010 / Chris Neal

Just doing a standup doesn’t make you agile

Have you ever been on a project that thinks it is agile but isn’t?

Agility

Agility

Me too. And it really hacks me off. Project agility is not something you can just switch on. You (as a team) have to want to do it and have to practice at it to get it right.

Here are some telltale signs for when things are not quite as they should be:

1. Ceremony without purpose.

Daily stand-ups are a hard thing to get right and some people just don’t get them. They are not there to have a chat about coffee, focus on about long complicated issues.They are not run for the benefit of the Project Manager (or ScrumMaster) – they are for the team.

They are there to:

  • Share commitment.  This is crucial. This is when you all commit to the goals you will achieve each day. It’s not a time for “I’m hoping to…”, it’s “I will…”! If that sense of team commitment is not there, or uneven across the team, things are likely to slip.
  • Give a real-time status update.  Where are you up to, did you achieve the goal you set yourself yesterday?
  • Identify potential blockages. Developing software is rarely plain sailing. Identify potential blockages early, and as a team work out the best way to overcome them.
  • Set direction and focus. What do we need to focus on next? If your lucky enough to have a small team, with your backlog on the wall nearby and your sponsor at hand – this should be easy. But it is surprising how often teams can lose focus, or get distracted away from the goals. If your Product Owner is not available this is where the PM or ScrumMaster should have a more prominent role, ensuring the team stay focussed on the immediate priorities.
  • Build a team – To me this is the second most important part of the meeting. It’s the team that needs to deliver the software, and it’s the team that needs to actively participate in the stand up. The best stand-ups I have been involved tend to have the following characteristics: everyone is involved, no one person dominates or leads, people come prepared, the team collaborate on issues/blockages, and they are over quickly!

All too often you can find the stand-ups becoming routine and mundane. When this happens look at how you are running the meeting and concentrate on why you are doing it and how you can keep the energy and commitment high.

For those who want a more information Jason Yip’s great blog post gives some really good information and advice.

2. Your Product Owner has gone missing.

This is probably one of the most common problems with Agile projects. Organisations start off with good intentions, but all too often the people who can contribute most to the project and drive the priorities, aren’t given the time to do it. They then turn to assigning Analysts or Project Managers to the project to fill in the gaps. This rarely gives a good outcome.

I’m not saying that you need someone on hand 24/7 but it is  essential that you have someone who deeply cares about the success of the project directly involved. This is crucial at the start, when defining the backlog, but throughout in setting and re-evaluating priorities, reviewing progress (demos or release walk-through) and in being the person the team negotiate with if and when things slip or priorities change.

There’s a lot of debate about what makes a good Product Owner. To me it’s simple. They are the person that cares, the person that is charged with making the initiative a success. If you don’t have good access to someone empowered to make priority calls, define what really matters, you are much less likely to succeed. From the outset you need to be realistic about how much time this may take, and this should be factored into the decision process to start the project.

3. I’m done is not good enough

When is a feature done? This might seem a stupid question but it still surprises me the frequency in which teams still try to set a feature as being “done” too early.

It’s not done when just the coding has been done.

It’s not done even if it is sat in the test environment and the tests have passed.

It is only done when the Product Owner or business sponsor or person that cares says it is done.

That means coded, unit tested, system tested, deployed, demoed and accepted.

OK we are all clear!

4. The magical self organising team

This is one of the hardest things to get right and sometimes this never happens. A true agile team works together to achieve the Sprint goal. They have a single purpose, they collaborate and resolve the issues they encounter as a team.

If it sounds like some sort of hippy utopia, then I’m sorry, but that’s what you should be striving for.

In my experience though, it rarely happens. The reason that it is usually so hard to achieve is simple. People are different. Teams are also different, and each team will have people of varying degrees of experience.

There is no magic solution here, but I think this is where some good people management skills come in. I’m not talking about command and control, I’m talking about trying to create a team environment where everyone feels valued and can contribute.

This takes time and effort to achieve, and on my projects, it is something I try to foster right from the start. It’s not easy, it’s never repeatable and it’s often time-consuming and demanding. But it is always worth the effort. If you have a team that works together to resolve issues and hit milestones, your project has a much greater chance of success.

5. I want it all (and I want it now)

Freddie

Freddie with thanks to Orange_Beard (http://www.flickr.com/photos/metrojp/)

Everyone wants to get the most of what they can. It’s understandable. Developing applications is expensive and you want to get the most bang for your buck.

Where this becomes a problem is when everything becomes a “must have”. If you have no room to manoeuvre then you are not really working in a truly agile fashion.

Good agile projects work with constant negotiation between the team and stakeholders. The team need to be realistic about what they can achieve, and allow themselves some headroom. If something comes in, something else may have to go out. Teams don’t have unlimited capacity and whilst we are an agile team and happy to accommodate change it may come at a price!

This is where the relationship between the PM (or ScrumMaster) and Product Owner is key. This is where the negotiation needs to happen. Be realistic about velocity and don’t overload the sprint with “must haves” (60-75% is my rule of thumb). Accept that change is inevitable and make dealing with it part of the process.

If your scope is fixed, or even worse expanding as you go, with no mandate to change it then you are not on an Agile project.

Make it count

Agile is not easy, as with all things in life it takes effort and commitment to perfect. Hopefully this blog highlights some of the issues many of you will have experienced (please add it if it isn’t). Next time you are on an agile project that isn’t really agile, don’t be afraid to say so. Figure out what you and your team need to  put in place to make the project run in a more agile way! If you can’t do that – you might have to face up to the fact that yours is not an agile project, and to continue pretending it is, isn’t really gong to help you deliver!

19 May 2010 / Chris Neal

Hello world!

Welcome to my blog. I’m Chris Neal and work as a Principal Consultant at Answer.

I’m a Project Manager by background, although have done Analysis, Design, Product Development, Team Leading, Testing and general management.

Hope you enjoy the blog.