Microsoft HoloLens

I was lucky enough to get tickets to see Mike Taulty talk about Microsoft HoloLens at Leeds Sharp last week. I didn’t really know anything about augmentated reality or virtual reality but in the interests of Staying Technical I was definitely interested to find out a little more.

Wow!

It turns out that the HoloLens is a Windows 10 PC designed to be worn rather than sat at. It runs apps from the windows store without modification (although Mike did stress that typing furiously in midair is somewhat less precise than using a keyboard). Instead of sitting on a screen the windows floats in front of you, hovers on a wall, or rests on a table.

3D apps can be build using Unity 3D (in fact Mike showed us how). I was really impressed how easy it was to work out what the user was looking out and listen to what they were saying (although I imagine Microsoft Cognitive Services could be used very effectively here).

Can I imagine us all walking around with these things strapped our head? Probably not… at nearly £3000 for the developer version these are likely to be out of the consumer budget (although Microsoft are working with partners at the moment to develop other models). But in a commercial environment? For architects, engineers, surgeons or even as a stepping stone onto the next generation devices which may weigh little more than regular sunglasses? I could see that!

Am I rushing out to buy a HoloLens? Probably not,  it would I seriously consider an Acer or Asus model for a couple of hundred pounds… that’s a much harder question to answer! I can imagine little spaceships flying around my living room or a huge troll sat on my sofa playing chess with me – the sky really could be the limit with these devices!

Who Should you Share your Backlog With?

I mentioned last week that I’d been to an interesting meeting discussing (and challenging) a few of the Scrum ideas. One of the questions we asked was about Backlog Visibility.

We all agreed that by making the backlog visible to our customers would invite feedback and reduce the likelihood that we’d spend time developing features which gave little value to our clients (see last week’s post on exactly what “value” is). But we couldn’t shake a distinct unease at making our plans visible, it took quite some discussion to articulate why this was.

Many customers and businesses work to project plans (ours included), they have long term visions of where they want to be and what they want to achieve. We realised with some trepidation that by sharing a fluid and ever changing backlog list of ideas with these customers it would create an expectation, which upon the next meeting would lead to disappointment as we had to admit the features we discussed were never in fact developed.

In an Agile environment we want to encourage this change, we want to update our backlog to remove unnecessary items and reorder the list to put the maximum value items at the top. However when presenting this to a client it could undermine us, particularly if the customer liked several of the items we ultimately decided to prune.

We decided that this is where clear communication is key. We talked about making it extremely clear that these were items we were considering working on and not a definitive product plan. A Development Forecast we suggested, after all – no one blames the weatherman if the reality turns out to be slightly different to our expectations!

What are your thoughts, do you share your Product Backlog with your clients? How do you handle their expectations that some work they are hoping for may still be cut?

Defining Value

I was recently at a talk where one of the key topics was “Defining Value”. I actually felt rather prepared for it – after recently reading The Goal I was fairly confident that the goal of any business was to make money. So “Value” would be anything which either earns us revenue or aids in our ability to make money.

It sounds boring, but it’s true.

My point actually kicked off a lot of discussion, in a room of experienced developers the proposal that unless we’re earning money we’re not adding value was rather controversial “what about paying technical debt!?” was one of the initial reactions (and one we came back to very quickly).

Delivering maximum value is of course what Scrum is all about, the idea that the team is constantly working on the most valuable piece of work is key to the sprint framework. So to be challenged to define value was an interesting idea, especially when Pete (our facilitator) threw out the following quote things became interesting:

“As a general rule of thumb, when benefits are not quantified at all, assume there aren’t any” – Tom DeMarco and Timothy Lister

With paid for work the value is often clear, the work is worth whatever the customer is willing to pay for it. Again, work to generate sales the Product Owner can list the contracts which will be opened up by a particular feature if it was to be implemented.

Support work becomes much harder. We all know that it’s easier to retain an existing customer than to earn a new one and anyone in sales will tell you the value of upsell and good customer service. So how do we justify spending hard pressed development resource fixing bugs, answering questions and supporting our existing customers when it does not earn us any revenue?

We all agreed that the only way to quantify the value of technical debt was to look at how much time and effort was being spent in supporting it. If an area of your software is full of bugs and you spend four days of each month assisting customers using it then over the course of a year it’s worth at least forty eight days to improve it!

Support work is valuable because by not doing it you’re putting your customer’s loyalty to you at risk. Reducing technical debt is valuable because it makes support work easier.

The next time you’re working in an unloved area of code, don’t moan about it – measure it. Present the business case to your Product Owner and help them quantify the value of refactoring and improving the code. It will make it a lot easier to justify doing the work!

Redefining User Acceptance Testing

User Acceptance Testing or “UAT” is a critical part of any project. It’s where the customer takes your software into their environment, tests it and reports any issues which must be resolved before they take it into live. Development teams then resolve these issues, send the application for retest and (hopefully) get a signed off version.

I have a deep seated dislike of this concept.

I should clarify that I have no problem with customers doing their own testing – in fact I encourage it, we’re software professionals and don’t work in our application’s domain. High quality customer collaboration is essential if we are to produce a good product. No, what I have an issue with is the concept of a development, testing, and bug fix phase.

If Agile and Scrum techniques have taught us one thing it’s that we need to move away from “development phases” and towards continuous delivery with ever increasing value.

Leaving bug detection and resolution until the end of project is bad!

What then is the role of UAT in modern development methodologies? How do we achieve a signed off version without digging ourselves into these waterfall defined project stages we were supposed to have abandoned years ago?

By making UAT a continuous process alongside the development.

In my view as soon as a project begins, while the stories are still being written and the mock ups created the latest and greatest version of your application should be installed into the customer’s UAT environment. Then, while you’re working away creating the new features the stakeholders in your client’s business are testing the suitably of what you’ve already developed against their needs.

As you continue, Sprint on Sprint, Story on Story you can incorporate your client’s feedback (both bugs and suggestions) to deliver the best possible product at the end of the project. It’s only by presenting your build to the customer early that you can get this feedback. Forcing your clients to wait until your project is feature complete and signed off internally will create these heavy bug fixing phases we’re all working so hard to avoid.

A Different Sort of 1:1

I met up with my line manager the other day, a nice change to our more common video chats. Spare meeting rooms at head office are seen less frequently than unicorns so instead of sitting in the open plan work area he suggested going for a walk.

The idea resonated with me and it’s something I’m determined to try with my team. Here are a few reasons why

  • Meeting rooms are very formal, 1:1s don’t have to be
  • Fresh air and a little light excercise is good for all us office bound geeks
  • Getting away from the office environment can lighten moods and change perspectives

Now, I don’t suggest you try a walking 1:1 on a wet, cold, or otherwise horrible day but the next time the sun is shiny why not take a walk?

Have you tried outdoor 1:1s? What was your experience?

Have you tried At Desk Testing?

Last week I wrote about the value of finding issues early. How it becomes increasingly expensive and time consuming to fix issues the further down the development lifecycle you get. With that in mind we can now appreciate that anything we can do to find bugs earlier makes our software not only better but cheaper to develop.

Something we’re trialling at the moment are at desk demos. The idea is simple, before signing off a piece of work and passing it onto the next link in the chain (Dev to QA, QA to Support Analyst, Support Analyst to Dev and so on) you demonstrate the issue or feature to them.

For example, before I finish a feature and pass it onto someone who specialises in testing I invite my buddy over to “give it a bash”.

Remember last week? I talked about the time it takes to move from on link in this chain to another. I discussed how it can take a few hours to build your software, another hour or so to deploy it, and a day to run the signoff scripts (obviously this varies if you’re fortunate enough to be working on a ‘modern’ solution or have invested in some proper CI). Time moving backwards is time wasted, if you can avoid rework then you should always take the opportunity to do so!
By offering up my work to the QA for a few minutes before formally handing over can save hours of wasted time. These guys know what they’re looking for and can often find edge cases and give feedback on a few scenarios you’ve not considered. By having these pointed out to you early you’re saving all this extra time!

The same theory can be applied to a Support Analyst demoing bugs to a Developer rather than just recording replication steps on a ticket or a Developer showing a bug fix to the same analyst before shipping it to a customer’s UAT environment for testing.

So far it’s working well for us. Do you demo before handing over? Do you feel it works for your team?

The Cost of Fixing Bugs Late

Have you ever been in a situation where you’ve written a piece of code and it’s almost there but there are a few niggling issues which “can wait for V2?”. Have you ever wished, maybe months later that you’d gone back and resolved them at the time? You’re not alone!

More and more developers and managers are beginning to realise the true cost of fixing bugs late, not only on their sanity but on the company’s time and money.

Let’s say for the sake of argument that you’ve finished a piece of code except for a few edge cases. You’re under a lot of time pressure so you decide it’s of a high enough quality and you push it through to QA. The cost to the business of fixing that issue actually increases dramatically the longer it’s left.

Let’s look at a few scenarios:

You fix the issue immediatly

  • Fix time – 30 minutes

You send to QA and it’s rejected there

  • Fix time – 30 minutes
  • Build time – 2 hours
  • QA deployment time – 1 hour
  • QA signoff testing – 24 hours
  • Fix time – 30 minutes

QA passes as an “edge case” but the customer disagrees

  • Fix time – 30 minutes
  • Build time – 2 hours
  • QA deployment time – 1 hour
  • QA signoff testing – 24 hours
  • Deploy to UAT – 3 hours
  • Customer UAT – 1 week

Missed in UAT but discovered as a significant issue in Live

  • Fix time – 30 minutes
  • Build time – 2 hours
  • QA deployment time – 1 hour
  • QA signoff testing – 24 hours
  • Deploy to UAT – 3 hours
  • Customer UAT – 1 week
  • Customer live deploy – 3 hours

 

As you can see, even with these rough estimates the time it takes to resolve the customer’s issue increases dramatically the longer it’s left. Not only that but the cost of time to the business of paying staff to run extra QA cycles or rounds of UAT spirals out of control. We haven’t even considered the final case where it goes to the bug queue to die and a completely different developer has to learn the feature and resolve the problem.

The graph is actually a very common shape*.

graph-2

I’m a big fan of practicality, no software is going to be perfect and it’s unrealistic to expect that you’re going to find and fix each and every issue before shipping to a customer.

However, hopefully this has made you stop and think and has provided a strong argument for making that extra 30 minutes to resolve the issue before it causes a real headache for the business!

*Thanks to fooplot.com for the graphing software.