The dangers of reinventing the wheel

We all know that person, that program, or that company that just loves to do things their own way. Even in the face of incredible evidence otherwise, they just want to forge their own path and show how innovative they are. But at what cost?

I'm not beginning to suggest that we shouldn't analyse our ways of working, our processes and our generally accepted project management styles, but we should also ensure we understand best practice. And why it is best practice.

Another important piece of understanding is that whilst we may be using agile delivery, it doesn't mean we don't have a framework. It's not an excuse to just do whatever, whenever.

As an example, I had recently heard of a team which is redefining user acceptance testing (UAT). UAT is accepted to be performed at the end of a sprint, just before release, to ensure a user is satisfied that the requirements or purpose of the software are met. What I had heard, is that the team was going to perform a check to see if the software met expectations of what the user wants to do, which sounds fine. Until you realise that the user wasn't asked this question up front.

This places the UX/HCD define and discover phases after the software has been built. Not exactly ideal.

There are established reasons why we perform this function at the start. The glaringly obvious reason is to make sure we build something that users want, need and will use.

Don't get me wrong, feedback at any and every stage of the software lifecycle is great, but we shouldn't be trying to reinvent the design and build lifecycle.

Lots of this has to do with time and velocity. The team is working so fast that they don't have time to do things at certain times. Microsoft explored the danger of user research without the rigour.

Further, the team were using this UAT as a way of performing pseudo usability testing in place of any form of design QA. This creates confused and ill-defined goals as they are trying to understand different things, albeit with some overlap.

To sum up, we should ensure we follow best practice experience and development tasks to make sure we are getting everything right and performing the tasks at the right time. Else, our insights may be inaccurate, or we find out something we didn't want- that we've been building the wrong thing all along.