4 June 2015

Chained to the Desk – The Sequel



Not Now Jon
In a previous post entitled “Chained to the Desk - TheParadigm Shift” I discussed the importance of questioning everything and the danger of accepting the current paradigm I gave examples of how the status quo can perpetuate for years and even decades before someone introduces an innovation that once suggested seems so obvious it is amazing that it was never thought of before.

I referred to a modern day situation that I believe is just such a paradigm and one to which we have all become blind; the desktop user interface. The current model has perpetuated since 1973 and so it definitely falls into the “decades” family of paradigms.

I’ve had some responses to this suggestion and understandably the majority refer to the value of the desktop environment over that of the tablet. They quote the limitations of tablets, and the strengths of the desktop and I certainly don’t disagree with them…

…or at least I don’t disagree when it comes to the physical aspects of the desktop environment. Greater screen sizes and multiple screens creating a larger working space. A full size physical keyboard providing a far better typing experience, but that is a comparison of the physical provision and not the operating system or user interface.

When it comes to the user experience there is so much that has always frustrated me, and even more now that we have the pleasure and ease of the tablet experience.

Poison Arrows
To illustrate, let’s look at some basic questions about the typical desktop UI.

  • Why do I have to use a little arrow to grab that tiny area in the bottom corner or at the very edges to resize the window?
  • Why is it that the only way to move the window is to use that same arrow to grab the title bar (even if the title bar is off the top of the screen)?
  • Why do I have to hit a tiny icon the in the top right (or top left) corner to minimise or maximise the window, not to mention the dangerously co-located “close” icon? Who am I, Robin Hood?
  • Why are all the options in pull down menus that require dextrous handling to get to and then hit the right option?
And now to the desktop itself. Even with the larger screens and multiple display options there are some annoying limitations.

  • Why am is that space around the screen not reachable?
  • Why do I have to drag a window into the screen in order to look at it?
  • Why am I forced to choose between large and readable (but limited space) and small and illegible (but loads of space) via tucked away display options that when selected are treated like major engineering decisions? “Do you want to keep these highly dangerous settings? You may never get your display to work again.”
  • And why, now that I’ve paid all that extra money for a touch screen do I find myself resorting to using the mouse all the time?

The answer of course is simple… because that’s the way it’s always been; that’s the way desktops and laptops work! Get with the program Jon!

Moving Pictures
What I want from my user experience, regardless of the equipment I’m using, is a natural human interface. Something that fits the natural, instinctive way in which we interact with the physical world. In the real world, when I want to move something around, get rid of something, or open something, I use my hands in a natural way. The success of the iPad, in my opinion was driven primarily by Apple’s ability to tap into these natural gestures and to add a sense of the physical to the virtual, the “list bounce” being just one of these.

So Apple, Microsoft, Google, or whoever; please can you give me a desktop on which I can, using touch alone to:

  • Zoom the whole display area (not just the window contents) using pinch to zoom
  • Resize individual windows using pinch to zoom gestures
  • Move the virtual desktop around allow to bring those areas off the edges of my screen into view simply by dragging the viewing area with my fingers.
  • Drag windows around by touching any part of the window, not just the title bar
  • Close or minimise windows using simple swipe gestures
But as I’ve said before, if people can’t see it and live it they’re not going to get it, so a blog post won’t break the desktop “I need my windows paraphernalia” paradigm that has existed since 1973.

I guess I’m going to have to go and build a demo…

Regards
The Enterprising Architect

3 June 2015

Easy Does IT – The Complexity Conundrum



It’s Bigger on the Inside!
In large organisations there seems to be a painful reality that IT is horribly complicated. There is much discussion as to whether this is an inherent and unavoidable reality or if it is one inflicted on the organisation by a failing IT department.

Well, in my opinion it is neither. There is nothing inevitable about labyrinthine IT solutions, nor do they arise from incompetent technologists. Instead, they exist to solve a complex problem and complex problems require complex solutions. The one true failing of IT is in selling the idea that technology can perform the impossible magic of delivering complexity in a simple way.

I have referred to IT’s love of silver bullet solutions in previous blog posts and I’ve also pointed out that just like the werewolves they are supposed to kill, these silver bullets are mythical in nature. They are mythical, not because we are unable as technologists to keep things simple, but instead because we are trying to fulfill an impossible promise. Somehow, despite failure after failure, the industry seems unwilling to learn this lesson. Attempts are even made to push the complexity down a level and refer to the adaptations required in our silver bullet solutions as “configuration changes”. The lure is attractive as the product now appears to be simplicity personified.

In practice, however, all we have managed to do is to push the complexity back onto the customer who is now required to “programme” the solution to work to their specification. We sell this as “putting control back into the hands of the business” but all we are really doing is subconsciously punishing the user for daring to be complicated in the first place. This is a “not my problem” solution.

Simple is as Simple Does
The answer to keeping things simple is simplicity itself, but simple is not the same thing as easy. The best way to demonstrate this is through example, but for the words I’ll turn to Steve Jobs who summed it up well in his statement:

“Simple can be harder than complex. You have to work hard to get your thinking clean to make it simple, but it’s worth it in the end because once you get there, you can move mountains” – Steve Jobs

It is from this source that my first example of simplification arises. In 1998 legend has it that Steve Jobs, in a moment of frustration, drew a simple grid on a whiteboard (the one at the start of this blog). This act radically reduced the Apple product line to four key products, shelving all other offerings regardless of status or demand. The original number of products is not clear; it is possible that even in 1998 it was not clear, and it was this confusion that led Jobs to make the decision he did. (There were at least a dozen variants of the Macintosh computer alone).

There is a smaller example much closer to home. Whenever I attend Cabinet Office presentations by members of the GDS Team they all bear a striking resemblance to one another. (It’s almost as if they’re working to a style guide!). Each slide contains just one simple sentence, and where the message needs to get more complicated they embed a simple picture, or more often a well-crafted video. It has always struck me that this approach focusses attention on the presenter, simplifies the message and creates engagement in the audience. More recently, whilst looking at mobile alternatives to desktop tools, it also struck me that this simplified approach to presentations removed the dependence on proprietary presentation applications (such as Powerpoint).

I would hazard that Steve Job’s example, although presented as being wise and well thought out, is less about evidence and more about gut. He made it simple because he liked simple and just knew it was right. He made the IT simple by making the business simple. Similarly, I’m sure there is robust evidence based logic involved in the GDS style guide, or could it be that the decision maker just knew that a decision to be simple in approach had a ripple effect on the simplicity of the implementation.

In both cases, the decision makers did something that some seem to find radical; they made a decision, and the decision they made was to give the user what they needed, not what they were asking for (there is a difference). They gave them something that they hadn’t even realised they needed and as a result they made them happy.

Paint it Black
Henry Ford did this too. He is credited with many quotes relating to user (or customer) needs, but the one I am going to repeat here is this:

“A customer can have a car painted any colour he wants as long as it’s black.” - Henry Ford

Henry Ford is not being rude here, nor is he ignoring the customer. Far from it. What he is doing is simplifying his offering in order to simplify the solution. It was this type of gut decision making that allowed the first Ford motor cars to roll of a production line in volume and at affordable prices giving the customer very much what they needed at the time.

So, to simplify the solution you have to simplify the offering, and to do that you need to make gut decisions. You will of course do all that good stuff like user research, prototyping and you will even run trials, but at the end of the day simplification will come from the brave decision to create the product or offering you believe in. You will offer this product to the customer, and trust in the fact that they will love it because you knew what you were doing.

You do know what you’re doing… don’t you?

Regards
The Enterprising Architect

29 May 2015

Getting to Done - The Start-Up Mentality (Part II)



A Game of two Halves
Welcome back to the second part of this blog post about introducing the delivery focussed start-up mentality to large organisations. In the first part I compared the two worlds and identified what I believe are the key differentiators that produce very different results. In this second part I draw analogies between what happens in the start-up world and how this can be replicated in an established organisation.

My approach to this is to adopt a model in two parts; a split personality methodology. The first part behaves like a start-up and adopts iterative agile methods and a more flexible approach to governance and funding. The second looks more like a traditional waterfall approach but only the part that kicks in during rollout. This is not simply about process, nor is it about asking for cultural change; it is about creating an environment that naturally reproduces the behaviour you are looking for. Culture is like a spring and environment is like a force on that spring. Change the force and the spring changes shape, but try taking the force away and the spring falls back into its natural shape. It is only though environmental change that you can bring about sustainable cultural change.

So let’s take a look at the start-up world as it moves from initial idea to finished product and at each stage examine what it looks like, and what I propose you should do to reproduce this in an established organisation:

I Have a Dream (Idea Stage – Discovery)
What it looks like: Two people meet in a pub and while consuming some fine sparkling mineral water and discussing the world’s problems they have an idea. This is the eureka moment when all the really good stuff happens. Energised by the pure genius of their idea the two colleagues embark on a process of discovery, researching the market, talking to potential users and mocking up the idea on paper. They may even knock up a cardboard model or mock-up to show to focus groups and make it real. The job gets a little more involved now and they may rope in a couple of like-minded friends with additional skills to help in the venture; the team is born.

What you should do: In an established company this happens all the time. All you have to do to make this part of your project approach is to actively encourage it. Don’t expect it to happen without encouragement though. If someone comes to you with a sketch on a piece of paper, an elevator pitch, and a lot of hand waving, don’t tell them to go away and come back with a detailed proposal. As a leader you should be able to quickly decide whether you like the sound of the idea, and if you do, have the courage to find them some space in their workload to go off and explore a little.

Show the Thing (Experimental Stage – Alpha)
Almost as often as asking the question “what is the user need?” Mike Bracken of GDS regularly uses the phrase “Show the Thing”. The importance of this mantra is far greater and fundamental than many people realise. (I’ve blogged on this matter previously under the title “The Art ofPersuasion – Touch it, Live it, Believe it”). It goes to the heart of product development and is based on the idea that until someone actually has the real thing in their hands they simply won’t believe in it.

What it looks like: To really develop an idea you need to show it to people, and so the next thing the team need to do is build a working version; an Alpha. This is where all the real questions get answered. In fact this is where those questions get asked in the first place. Before building something, the team didn’t even know the right questions to ask. This is why an alpha is built quickly from whatever the team have to hand. It is built to try out solutions and to eliminate that which doesn’t work for the user.

What was originally conceived and what emerges from the alpha may be very different beasts, and it is possible that the most important thing that emerges is that the idea doesn’t even work. This is probably one of the most important outcomes as it avoids the embarrassment of creating expensive white elephants.

What you should do: It is a lot cheaper nowadays to develop IT solutions, but it still isn’t completely free. There needs to be a way that the team can tap into petty cash to get an alpha built. It may only be a few hundred pounds or at most a few thousand (if hardware is required) but you can’t expect people to wait for weeks or even days for small amounts of cash or the impetus will evaporate. You need to have this money available to give them and as a leader it is your job to make sure you have a budget available to use at your discretion.

Enter the Dragon (Development Stage – Beta)
Remember, we’re trying to create a start-up environment here so let’s consider what typically happens next. In a large company we now initiate a project and get bogged down in the approvals process. Waterfall rears its ugly head and everything grinds to a halt. In the outside world, there is no company within which to launch a project and so something different happens.

What it looks like: The team reaches the point where the idea can go no further without real funding and they decide to involve the help of keen investors. This is beta, the cycle of invest/prove/invest/improve, and this takes money that the team simply don’t have. Without the security blanket of a large organisation around them, the team members need to find a backer and they turn to the venture capitalists. For this they need a convincing pitch and that pitch has to come with something to show. Luckily they have this, and hopefully they will be successful, but this is where things differ from a large organisation. Dragons are renowned for being fickle and have short attention spans. They are also very protective of their hard earned cash and demand regular demonstrations of progress in order to continue providing investment.

In a start-up you are always painfully aware that progress is the same thing as survival and there is nothing quite like the reality of a fixed date on which the money runs out and another meeting with the investor is needed. Dragons very aware that it is their own money that is being burnt by the team, and they are not fooled by attractive progress reports. They want to see real results with real customers, and start-ups only survive if they provide this.

Finally, VCs want a return on their money. This can of course come from the profitability of the start-up, but more commonly VCs seek an exit strategy and this is the scenario I will consider. Once the start-up has a successful product, but before it has expanded into the broader market, the VC and founder members seek a buyer, and if successful some remain as part of the deal and others move on, profits in hand, to pursue the next entrepreneurial venture.

What you should do: In companies you don’t have backers, you have stakeholders, and stakeholders rarely have anything personally invested in progress. Instead they are put in the position of having to agree to things progressing, but progress might lead to failure and failure gets you sacked. What you need to do is turn those stakeholders into dragons. Give them budgets to invest in ideas and measure their performance based on return on investment. If they are not investing they are not generating returns and so they fail. If they are investing in things that don’t progress this is even worse as now they are generating negative returns.

Instead of being critical stakeholders demanding more and more detailed plans and estimates, prevaricating instead of enabling, they become driving individuals with a personal stake in the success of the project. If things get tricky they will even dive in and get their hands dirty.

But they hold the money, and this is the other important part of the role. That money needs to be spread across a variety of investments and they need to decide where best to place it to get a return (in terms of business benefit). In order to do that they will need to drip feed funding into the various “start-ups” they are involved in and only continue to fund those initiatives that are showing real progress. This creates natural iterative development cycles with real deliverables, and provides checkpoints where genuine go/no-go decisions are made and acted upon. No funding, no start-up. The ones that make no progress are stopped whilst the successful ones produce something of real value.

Then comes the sell – the exit strategy, but we’re inside a large organisation and so instead of looking for a larger organisation to buy them out, the VC and the team pitch the idea to the major stakeholders within the company to take forward to rollout. The product is working, and proven, and all the difficult design work has taken place. The offering is therefore very attractive as all that is left to do is to scale and rollout the solution and take credit for the benefits. It is here that the currency of the sale becomes apparent. We don’t exchange the product for money; instead we sell it for an agreed business case that demonstrates the costs and resulting benefits.

The case can be worked on between the seller and the buyer in a process analogous to a corporate acquisition and this then gives us our mechanism for reward. The proposed benefits are effectively assigned to the seller (the VC and the team) and it is against these benefits that the seller is recognised. The buyer inherits the ability to then realise those benefits and gain credit for delivering the results.

Tomorrow the World (Expansion Stage – Live)
And then we make it production ready and mass produce (includes the creation of the production team)…and this is the waterfall part. Well, it’s actually only a small piece of waterfall; the planning piece. All the difficult questions have been answered. We don’t need to gather requirements because we have a product. We don’t need to guess how long things take because we’ve already done it and we know. We don’t need to hope the sizing is right because we have real metrics from the live service telling us how big it needs to be.

With all this certainty we can very quickly produce a roll out plan to which people can work with confidence and against which we can allocate resource and money.

Most importantly, we can grow a team around this service that will live with it, run it, and continuously improve it, and our original founding members can leave to pursue the next great idea (without needing to leave your company).

Different Strokes
So, in summary, let’s put aside the agile versus waterfall discussion and the old versus new debate. There is no old and there is no new; there are simply appropriate techniques for appropriate situations. Detail, discipline and planning are ideal for repetition of well understood situations at scale but stifle creativity and fail dismally in the face of uncertainty. Iteration and experiment work well with chaotic situations and allow innovation to flourish. You cannot apply the rules of one of the worlds to the realities of the other.

Methodologies are not religions; you are allowed to believe in more than one.

Regards
The Enterprising Architect