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

27 May 2015

­­Getting to Done - The Start-Up Mentality (Part I)



Come Fly with Me
There is a dilemma in the IT industry, and it is all about getting off the ground. It would appear that projects are like aeroplanes; the larger they are the longer the runway they require, and once they get too big they don’t get off the ground at all. If you’ve been in IT for any time at all, I’m sure you will have come across at least one legendary project that seems to run and run without end, never quite delivering anything of real value.

Those technologists who work in large organisations bemoan the inevitability of failure at scale whilst staring longingly at the few young upstarts who deliver at blistering speed in trendy start-ups. They point out how easy it would be if they could work in a green-field environment with no constraints and none of the rigour required for large systems.

But that is simply a luxury you can’t hope to have in any “serious” company. Even start-ups get slow as they grow… don’t they?

Well yes, in many cases they do. Of the ones that actually survive (and of course this is one of the biggest risks of working in such a world), many start-ups turn into average companies and then into lumbering corporations. The same people work there, but they’ve lost the spark and become the very thing they used to mock. Many of them even buy a suit, and start using Powerpoint!

It Ain’t Necessarily So
However, in some rare cases the agility remains, and new stuff gets done quickly and often. This leads us to ask the question, how can this be possible, and is it something that can be introduced into a company that has long since lost that loving feeling?

The attempts that have been made to achieve this are many and varied and most result in failure. Innovation teams sprout up, only to wither on the vine, starved of funding and lacking any true stakeholder buy-in. Companies strip away governance in the hope that things will progress faster, and then discover the mess they get into when large projects go off down blind or dangerous alleys.

They even try agile, introducing it to a sceptical workforce but even when they manage to create new evangelists for iterative development they still end up with something that an old colleague of mine referred to as “water-scrum-fall”. Things go so well at first as they try it out on small projects, and then as they scale up it all goes wrong. Once more the size overwhelms them and the speed disappears.

But agile seems so promising. It reinvents something the older amongst us instinctively knew when we started out in software development; you always start with the user need (which is very different to the user want). Requirements capture, huge documents, and wall sized Gantt charts felt like something from another world; one populated not by engineers but by accountants and lawyers. Agile felt right because it felt creative and dynamic, and that’s what we were doing; creating new things that had never been seen before, using technologies we didn’t really understand yet.

The size problem is still the killer though. With a small number of people, the agile creative approach works beautifully. As the number of people grows, the stand-ups become unwieldy and communications break down. So, you break the project down into manageable units, each delivered by a single agile team, but then find yourself needing to do more up-front design work to ensure that each team knows the boundaries of what it is delivering.

This is the thinking that leads to “water-scrum-fall”, an uncomfortable union in which agile teams deliver component parts of a much larger solution that in turn has emerged from waterfall style thinking. For some this seems ideal as it keeps all of the “best practice” of the “tried and tested” methods whilst still allowing the development teams to get busy (and wear jeans). Unfortunately it misses the point completely as those “best practices” are the very problem.

Infinite Monkeys
Discovery is fundamentally different to requirements capture. You are not asking the user to describe what they want in abstract terms and dry words; you are observing them and working with them to prompt thinking and try out new approaches. You fail fast in order to succeed faster. Alpha and Beta are fundamentally different concepts as well. You don’t design then build then test; you design, build and test as a single activity but in an iterative manner, learning as you go. If you embed this approach inside waterfall then you are not doing agile at all; you are just pretending. How often have you heard people who have adopted agile refer to the introduction of a “fire break” between discovery and alpha, and between alpha and beta to allow them to “get the paperwork together and apply the governance processes?”

In agile these things are not abandoned, but they are also not done as a separate activity. They are instead done in-flight as an integral part of each iteration. Flipping the problem doesn’t work either. Trying to embed waterfall inside or alongside an agile approach simply leads to a contention between the desire to do things (waterfall) and the intent to do them iteratively.

This is the point where I mention the wake-up call regarding waterfall. It doesn’t work at scale! Sorry to be the bringer of bad news, but just because something seems to work for small situations doesn’t mean it will scale, and waterfall doesn’t scale. The concepts are good in theory, and when planning your revision timetable, or managing a small team of people performing a well-defined and repeatable activity the tools of the trade work very well, but therein lies the problem. It is a very rare event in IT when we do the same thing for a second time.

Each time we build a system we are building it for the first time, and we have no information on which to base a meaningful plan. All the analysis and research in the world will not give you the answers you need; you will only find out anything real once you start building. Waterfall does not allow this, and this is why agile wins every time. There is also the reality problem. The disciplines of waterfall are fine in theory, but as you scale up the time and resource required scales up linearly; there are no economies of scale. Unless you have an infinite number of monkeys you are not going to get the complete works of Shakespeare and even if you did, no-one has time to read it.

The Three Pees
So what is needed to break out of the big-company thinking patterns that lead to programme bloat and long running programmes that promise the world but never seem to come to fruition? At the start of this post I talked about the delivery mentality that allowed start-ups to work at a pace unmatched in larger organisations, and it is from this model that I draw my solution.

There is more to the start-up world than just the advantage of small size. There are also the external pressures that are brought to bear. Start-ups are dependent on funding for survival in a way that far exceeds any equivalent pressures in more established companies. They are acutely aware of their own vulnerability and that in turn increases the volume of the ticking of the clock to deafening levels. Every day counts and quite often, every hour counts.

This creates appetite and pace.

There is also the sense of purpose that exists in a start-up. There is of course a sense of purpose in more established organisations but it is never as personal and certainly never as all consuming. In an organisation a bad year for the company is a disappointing year for the employee. In a start-up, a bad month for the company can be disastrous for the individual. A large organisation becomes like a machine whilst a start-up is a living entity with moods and emotions.

This creates engagement and personality.

Finally, there is something bigger to aim for. Everyone in a start-up is aware of the potential exit or growth strategies. The commitment in time and energy is worth it because firstly at some point it will come to an end and something new will begin, and secondly everyone will benefit from the outcome.

This creates motivation, commitment and persistence.

Duplicating these environmental factors might just make large companies deliver benefit at speed, and in the second part of this post I will describe how to foster this start-up mentality and give your organisation pace, personality and persistence.

To be continued…

Regards
The Enterprising Architect

18 May 2015

Diversity Matters - Attack of the Clones



Here’s looking at you, Kid
Performance management. You simply have to have performance management if you want high performance teams… don’t you?

Formal performance management is a fundamental part of the culture that pervades most large and medium sized organisations. It involves “regular” one-to-ones where we discuss successes and then focus on weaknesses, and if you are one of the lucky few you get a hearty pat on the back and a top rating. For an unfortunate few, there is of course the bottom rating and the dreaded “performance improvement plan”, a wonderful piece of 1984 new-speak if ever there was one. For the rest (the vast majority) there is simply the mediocrity of a “you weren’t great but you weren’t awful either”.

Now, let’s consider what effect that has had on the motivation of your employees? Has the top elusive rating spurred the shunned majority into greater things, and has that highly supportive “get better or you’re out” given the under-performers the help and support they need to become the best that they can? In my opinion, the answers to those questions are “no”, and “hell, no”.

Instead, the middle majority (many of whom may have performed well in all areas apart from self-publicity) have been demotivated by the lack of recognition for the things they achieved during the year. They may have had some great moments backed up by a solid performance, but at the end of it all they get nothing but a “what you could have done better”.

And as for the under-performers, they are now working under the looming threat of dismissal and although a rare few might scrape back into a middle rating the majority, who are already struggling, will simply buckle under the stress of continuous scrutiny. Don’t think so? Try standing over someone who is typing and see how well they do.

There can be Only One
There is of course another issue here; what exactly are you measuring these people against? For the system to be “fair” there has to be a benchmark; a standard to which all should aspire and against which all can be measured. If not, how can I justify the rating I give to people? I can’t just say “you did really well this year” without a definition of “really well”.

So what’s wrong with that? Surely it’s good to have a standard to aspire to? I disagree, and I disagree strongly. The implication of a standard is that there is one version of good. That would also imply that you need everyone in your organisation to do the same thing.

We all accept that artists are different to accountants are different to athletes. We would laugh at the idea of measuring these people against the same standard, and yet, when we place a group of people in an office and dress them in work attire, we suddenly forget about the differences and assume because they look alike they should all perform alike.

But they look alike because we make them look alike.

In reality, different jobs require different skills and different skills come in very different packages. What is more, the idea that you should look at a person’s weaknesses and strengthen them ignores one very important point. Weaknesses are simply the flip side of strengths. It is all just a matter of perspective.

This becomes all too clear when you consider athletes. We all understand immediately that the strengths that make a weightlifter great might be terrible weaknesses for a long distance runner, and expecting an archer to measure up to the same performance standards as an equestrian would be ridiculous. An Olympic team is strong, not because of uniformity but instead because of diversity. It needs a wide variety of athletes if it is to come home with a large haul of medals. Turning up with a team consisting only of great 100m sprinters would result in two medals (don’t forget the relay).

Life is Like a Box of Chocolates
In athletics, physical diversity is the key to creating a successful team. In the office where the work is cerebral in nature, the most important thing is cognitive diversity and this is far harder to select for. Why? The reason is simple. You are looking for people who think differently; who don’t think like you. You are looking for people who disagree with you, and we are not very good at getting along with people who disagree with us. In fact, we positively reject those who disagree.

How many times have you sat in an interview waiting for the right answer only to be frustrated by the candidate’s insistence on the opposite? How many times have you sat in a performance review only to be told that your approach to work is not the right one? That despite delivering results, the way you delivered those results did not match the required “behaviours” or “competencies”. Creative people are told they are not organised enough and should brush up on their planning skills while structured project managers are chastised for not demonstrating enough “innovative thinking”.

Performance management regimes and competency based interviews, the mainstays of professional life, stifle diversity. But diversity is the key, and whenever you come across a new interview candidate or team member, remember what Mrs Gump said:

"Life is a box of chocolates, Forrest. You never know what you're gonna get."

And that is exactly the point. You never know what value you will get from a person, but the best way of maximising the value you get from a team is by ensuring that the members of that team are diverse; that their skills are varied and their strengths complementary rather than duplicated.

Take the Red Pill
When you are interviewing, or when you are assessing a person’s performance, remember that he or she may have something to offer that you don’t even recognise yet. I often think that the best answer to an interview question is the one I disagree with. This person might have something to teach me. They definitely have something to bring to the team that I do not; a different perspective. As Morpheus said to Neo:

“You take the blue pill—the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill—you stay in Wonderland, and I show you how deep the rabbit hole goes. Remember: all I'm offering is the truth. Nothing more.”

If you take the red pill and embrace diversity you may find that the world of possibilities expands enormously. You may find that the team you build is stronger and more capable than the one consisting only of those that match the “standard”. You may even learn something yourself and benefit from your very own performance improvement plan.

Or…

What the hell… stick to the script. Take the blue pill and help to build the clone army.

Regards
The Enterprising Architect