Tag Archives: Agile

The future of (knowledge) work

Note: This is the first part of a longer series on how social media is affecting management. I started writing the following to explore a vague idea and see where it might take me, and first stopped writing when it was roughly three thousand words. At that length it was quite a bit weightier than the average blog post – and far too long to read in a lunch break – so I’ve decided to break it into a number of smaller. The first is below, and you can find the other issues – Knowledge workers in the British Raj, The north-south divide, Working in Hollywood, World of Warcraft in the workplace and Problems and the people who solve them – elsewhere on this blog.

What impact will social media have on how you run your business? It’s being touted as everything from a better form of groupware or the next step in the evolution of work management — a new layer on the technology stack that’s starting to be called human interaction management{{1}} (HIM), sitting on top of, and bringing together, BPM, workflow and case management — through to a wholesale transformation of the way your business operates and is organized. Reality (as usual) rests somewhere between the two extremes.

[[1]]Human Interaction Management[[1]]

Are the inmates taking over the asylum?

Social media (Web 2.0, Enterprise 2.0, Social Business Design, and so on) seem to be triggering a change in the command and control structures that we have traditionally used to manage our companies. There is an ongoing discussion within the human resources community concerning what form our future organizations will take{{2}}. The key drivers are streamlined communication from social media, both within and without the organization, and the empowerment of the frontline and delegation of authority due to the increasing need to solve problems promptly within a local context.

[[2]]“Social” is now HR’s baby (sorry Marketing Department) @ Fistful of Talent[[2]]

Old power structures seem – in some cases – to be in the process of being inverted as the people at the front line find that they are now better informed and equipped than their management to solve the majority of the problems confronting the business. If people are your most important asset, then we might just be standing at the start of a revolution as the workers realize that they really do control the means of production.

Wholesale revolution is unlikely though. While employees might be an important asset, and one that has a significant impact on the overall performance of your organization, they are not the asset a business is built to support{{3}}. For many organizations the best result is usually to remove the people, such as with lights-out factories, or some of the new SaaS plays which are replacing people-driven BPO with automated self-service solutions. The dirty secret of Enterprise 2.0 is that it’s being used the same way as every other technology to date: it’s being used to remove people from the equation.

[[3]]Why Enterprise 2.0 and Social Business Design might be of marginal utility for most of us @ PEG[[3]]

On the other hand, it has become obvious that social media is having an effect on our organizations. A key assumption behind most organizational structures is that information is rare and expensive to obtain, pushing us to create organizations that gather information from the front line and aggregate it up to the CEO. This also means that information is the currency of company politics. However, with social media and the Internet information is now – on the whole – cheap and easily obtainable. Controlling the flow of information is no longer possible, leading us to think some amount of disruption of the current order is inevitable as the old power dynamics are destroyed and new ones formed.

One thing is clear though: we need to think about work – and the teams and organizations we construct to support it – differently. The formal, siloed structures we find in many organizations don’t map well to the more dynamic environment that social media is bringing to business. Many businesses now have more in common with the British Civil Service in India – flat structures where the people at the coal face work largely under their own direction, collaborating with others as required – than the vertically integrated titans of industry from recent time.

Computer: an electronic device for storing and processing data

Companies have changed dramatically since the days when the term computer referred to someone who manually computed mathematical functions. Technology has slashed the number of people required to support most, if not all, tasks in the enterprise, making today’s companies dramatically smaller and more agile than their forebears. What used to take rooms full of people now needs – at the most – a small team. This is true across the full depth and breadth of our organizations, from the mailroom and typing pool, finance calculating the payroll through to the production floor in the factory.

Williamina Fleming (standing) with her computers in the late 1800s
Williamina Fleming (May 15, 1857 – May 21, 1911, standing) with her computers in the astronomy department at Harvard in the late 1800s, hired to carry out the mathematical calculations required to classify stars.

Not only has the volume of manual work changed, but the nature of that work has also changed with it. We used to deploy our employees to run the business, focused on the carrying out the plethora of operational tasks required to keep the wheels of commerce turning. Automation through technology has largely taken care of this.

With payroll and the shop floor dealt with, our employees are now more concerned with improving and guiding the business. For many companies the center of gravity of their workforce has shifted away from operations, moving to roles more concerned with the performance of the business: supervisory, design, business improvement and customer engagement.

Supermarkets, for example, have been hollowed out by modern management practices. In the past, store managers were masters of their own domain, held accountable for profit-and-loss and not much else. Today, the only real freedom many store managers have is in hiring the team who staff the checkouts, and keeping them motivated. The vast majority of decisions required to run the store have either been pulled up to head office (such as store layout and pricing moving to a centralized category management team{{4}}) or delegated to suppliers or the staff at the front line{{5}} (determining when to restock, for example).

[[4]]What is Category Management @ Category Management Association[[4]]
[[5]]What we’re doing today is not what we did yesterday @ PEG[[5]]

This makes projects the focus of many modern workplaces: projects to improve systems and processes, projects to bring new products to market, projects to expand into new territories, projects to optimize our product portfolio, and so on. One of the main short-term drivers for adopting social media in the enterprise is supporting work in these projects by providing the workers within them with a better way collaborating and searching for answers to the problems they have.

However, while the demand for work on projects has grown, the size of the teams required to deliver our projects has shrunk. Initiatives which required one hundred people and a billion dollar investments in the fifties, sixties and seventies, can now be delivered by team sizes in the low double digits, if not less than ten people.

The number and variety of careers – the professional community – supported by these projects has shrunk in response. This started with the specialists, but soon moved on to more general disciplines. For example IT platforms and frameworks used in the enterprise today have eliminated much of the need for specific technical specialists (there’s not much requirement for a distributed transaction specialist on most projects now). Some of the new frameworks eliminate the need for even quite common skills, as with databases and Ruby on Rails.

Flat, but not quite flat as it could be

Social media – as with many of the technologies preceding it – streamlines previously manual tasks by capturing knowledge in a form where it is easily reusable, shareable and transferable. What is different this time is that social media is focused on the communication between individuals, rather than the tasks these individuals work on. By simplifying the process of staying in touch and collaborating with a large number of people it enables us to flatten our organizations even further, putting the C-suite directly in contact with the front line.

This is having the obvious effect on companies, eliminating the need for many of the bureaucrats in our organizations; people whose main role is to manage communication (or communication, command and control, C3, in military parlance{{6}}). The big winners from social media will not be, as we first thought, those white-collar knowledge workers who spend their days herding those at the coalface, crafting policies, and worrying about organizational dynamics. The winners will be the team at the frontline and C-suite, as they both bypass the (soon to be removed) mid-level functionaries and engage with each other directly{{7}}.

[[6]]C3 defined @ Wikipedia[[6]]
[[7]]Rise of the task-worker 2.0 @ PEG[[7]]

The net effect of all this is that our organizations and teams are being hollowed out as the middle layers are replaced with software{{8}}. To some extent the chickens have come home to roost; technologies that replaced the people at the operational coalface are now being used to replace the people in the project teams that brought these technologies to the enterprise in the first instance.

[[8]]The IT department we have today is not the IT department we’ll have tomorrow @ PEG[[8]]

Continued in Knowledge workers in the British Raj.

Planning should not require a Gantt chart

There’s a standard slide in my bag of tricks which finds it’s way into a surprising number of presentations. It’s a simple slide, one allowing me to explore the idea of planning as a spectrum of possible methodologies rather than treating planning as an either-or choice: either be bottom-up reactive, or requiring us to engage is a major top-down planning processes. By combining elements of both top-down and bottom-up approaches we can modulate how reactive, or how proactive and predetermined, our execution is. The idea is to set the slider where we want it, at the position that best suits what we are trying to achieve, instead of being forced to one end of the spectrum or the other in a purely reactive or purely deliberative mode.

A slide for our times
A slide for our times

Planning has a bad name. How many projects get stuck in that endless spiral of planning (and re-planning) as they try to find their way to the middle of the project hedge maze? It doesn’t seem to matter if we’re planning the expansion of our business into a new geography or a major IT transformation, the process drives us all nuts; wasted days and nights spent constructing (and then deconstructing and reconstructing) elaborate Gantt charts which we’re all sure will never be used.

All of this runs counter to what could be called the first rule of management:

Make a timely decision, and then make it work.

Most organisations’ first thought is to focus on being reactive and deal with the problems of here and now. Unfortunately this too has its own challenges. The Agile software movement can be seen as one well documented reactive methodology which has seen mixed success. Where time, scope and cost are negotiable, taking a reactive approach is the same as choosing to put scope up for grabs. The result of the project will be whatever the project manages to deliver, unsurprisingly. This might be enough to realise the original business case, or it might not.

A top-down, deliberative, approach is planning as a chess game (the untimed1)Types of chess games defined at Chess.net rather than the timed variety). We assume that we have complete information and can take as long as we want to formulate our next few moves. The more we know about our opponent — the more tacit knowledge we have about what might go wrong (and right) on a project — the better and more accurate our plans will be and the further into the future we can plan. We can measure and evaluate our current situation, use tools like scenario planning2)Martin Börjesson has put together some nice resources on Scenario planning to anticipate the future, or even hire an innovation consultancy to identify our next, disruptive move. In a perfect world the only limitation to our planning ability is our own ability to comprehend the problem at hand (or the number of tasks we can cram into a Gantt chart, whichever comes first).

The problem is the unexpected — the unpredicted (and possibly unpredictable) event — which makes our plans unravel. It’s the event that we didn’t manage to anticipate, invalidating our assumptions and converting a carefully crafted plan into wasted effort. The faster the environment changes the more likely it is that something unexpected will happen between the plan’s conception and the delivery of its final outcome. Even worse, we might not even finish planning before something unexpected pops up which invalidates our work to date, causing us to restart the planning process.

Take your average major IT transformation: a multiyear project involving a massive investment in both time and money. To kick-start the project we need to predict what the business will need when the transformation is finally delivered (and as I’ve said elsewhere, this is a challenge in itself3)I’ve already told you 125% of what I know @ PEG). If we’re lucky, then assumptions we’ve made about the business’s requirements will still hold true all the way through to the end. However, what’s more likely to happen is that the change orders will start arriving well before we’ve finished, possibly even we’ve completed requirements gathering. The team then struggles to divide their time between scheduled work and change orders before re-planning (and often re-planning again and again) to try and regain control of the project. Try as we may though, the end result is often more like coughing up a fur ball than the slick solution we originally imagined.

A reactive approach, on the other hand, doesn’t worry having about complete information. The focus is on reacting to events as they are encountered, with little thought to long term goals or strategy. A shotgun approach, as it were. We craft our strategy by creating a set of rules covering what we should do in all the circumstances we care about. See a stop sign? Stop. And so on. The challenge is to craft a set of rules which cover most eventualities, and this is a major focus of the “agile” methodologies. They try and craft their manifestos and playbooks to document the tactics — the rules — which they think will drive their projects in the right direction.

playbook [ˈpleɪˌbʊk]
n

  1. (Team Sports / American Football) a book containing a range of possible set plays
  2. a notional range of possible tactics in any sphere of activity

The American Heritage Dictionary of the English Language, Fourth Edition.

The unexpected is not a problem for a reactive approach: you simply deal with problems as they arrive. If you’re not expecting anything in particular, then whatever turns up must have been what your were expecting. (There is logic in there.) However, this puts you at the mercy of what does turn up; as you’re focused on reacting to events, the events which arrive (and the order they arrive in) determine where you end up. While cost and time (i.e. effort) might be fixed, scope (and therefor the final result) is up for grabs, making it hard to drive a reactive approach to planning to deliver a well defined outcome.

With it’s focus on incremental delivery and improvement, a reactive approach is not an obvious bedfellow for your major IT transformation. It’s modus operandi is to focus on shot term demands, understand what the business needs next, build that, and then iterate. The IT estate evolves (somewhat) organically as we add things here, patch things there, and generally muddle our way through. Yes, we are reacting to short term business needs, but at what cost? Its a bit like taking our hands off the tiller to leave ourselves to the mercy of the wind; our boat will probably stay afloat, as long as the weather isn’t too bad, but we have little control over where we end up. Without the ability to drive toward a clear, long term goal, we soon find that all the well meaning tactical decisions we’ve made have resulted in a giant fur ball, just like those occasions where we tried to drive the project forward with a giant Gantt chart.

Neither of these two approaches to planning are necessarily wrong; they’re just not suited to solve the sort of problems we’re dealing with in the new normal4)The new normal @ McKinsey Quarterly. They represent two extremes — proactive and reactive planning — but we need to balance proactive and reactive, and find a middle path.

First we need to admit that we’re resource constrained. This might be in terms of time, the funds we have available, or even simply the number of people we can usefully bring to bear on a problem. (As Frederick Brooks5)Frederick Brooks on the Mythical Man Month pointed, it might take one woman nine months to produce a baby, but we can’t expect nine woman to deliver a baby in one month.) And this is in an environment where meaningful business change is measured in months, if not weeks. The effort required to develop our plan needs to fit into the time available, and our approach needs to provide opportunities to regularly revisit our assumptions and allow us to react to changes within and without the project. We need need to be reactive, but not too reactive, as we need to work within an overarching framework so that we can have some confidence that we are working toward our long term goals.

People — that’s you and I — take a more pragmatic approach to planning. If we didn’t, then I couldn’t imagine that we would manage to make it through the day with everything we need to get done and the disruptions that we all deal with. Think about how you went to work this morning. (Or how you went to the local café for a coffee, if it’s the weekend.) You weren’t purely reactive. If you were then I expect you would still be lying in bed trying to sort out you manifesto and playbook, hoping for something to happen which will prod you in the right direction. Nor do you take an exclusively top-down, deliberative approach, popping open the laptop on your knee whilst in bed and firing up your favourite planning tool. You’d probably still be stuck in bed, working at the never-ending ending task of plotting exceptions and eventualities. (What should I do if the case of divine intervention?).

People take a middle road. We establish a clear goal, usually something quite prosaic, like:

Get to work (on time)

We have a clear understanding — a set of beliefs, things we expect to be true — of the context we need to do this in.

  • I’m lying in bed
  • it’s a weekday
  • the alarm has just gone off
  • the weather forecast was for a clear sky and sun
  • I’m feeling a bit pudgy today

We also have a library of plans — short patterns of behaviour — which we know that, either from experience or by design, will drive us toward our goal. For example, to get to work we might usually follow the pattern:

  1. get up
  2. shower
  3. get dressed
  4. eat
  5. commute to the office

where each of the steps in this pattern can also be goals themselves.

We might, for example, have a few different plans for commuting: one each for by car, by bike, via public transport, and so on. When it comes time to commute, we consider our beliefs (it’s sunny and I need the exercise) and choose what we think is the most suitable option (I’ll ride). If the option turns out to be a bad choice (one tyre on my bike is unexpectedly flat) or unsuitable due to some change in the environment (it starts raining when I’m less than a block from home), then you discard the plan and pick another (heading back to the garage to take the car). After all, we hadn’t invested much in developing or executing the plan so we’re not losing a lot by throwing it away.

The twisty path between us and our goal
The twisty path between us and our goal

The gap after each step provides us with time to pause and reflect, consider our goal, and respond to the environment by selecting how best to execute the next step. This ability to revisit our decisions frequently — at each step on the journey between the office and home — allows us to be reactive, but not too reactive, while the knowledge that each step is part of a large plan provides us with the confidence that we’re working toward our longer term goals. The more granular we make our plans the more opportunities we provide to react to changes in our environment, but at the cost of being less deliberative and proactive, and potentially less efficient. The more coarse grained we make our plans, the fewer opportunities we create for being reactive, by it allows us to be more deliberative and efficient in delivery.

By modulating the size of our plans — the size of the effort we commit to — we can set the slider where we want it on that planning scale, with reactive on one end, and top down deliberative. This lets us align our planning with the degree of uncertainty and change we’re seeing in the environment around us.

I’ve been using this approach to plan and manage business and IT strategies for some time, with a great deal of success. Most of the tooling required already exists in the business business world, tools such as strategy maps6)Strategy map defined @ Value Based Mangement by Kaplan & Norton, mission statements7)Mission statement defined @ The Centre for Business Planning, and project portfolio management tools. Using these tools we can clearly identify our goals, articulate the tactics we want to use to drive ourselves toward them, and then create a portfolio of work which realises the tactics.

For example, the mission of being a low cost service provider might result in a goal of having efficient operations (which we can measure via a benchmark), and the tactics we can use to deliver more efficient operations might include consolidation (reducing the number of offices, data centres, or event tools). We can realise this need for consolidation by identifying a set of small projects (such as shutting down a small data centre, and consolidating its servers into a major one), each of which delivers one step on the journey. These projects then become part of a larger portfolio of work, with the resources available and business priorities determining which projects are executed next.

Just like the example above of each one of us finding our way to work in the morning, this approach enables us to balance how reactive or proactive we are at any time. We can easily re-proritise in response to business change by updating the mix of projects to be executed, rather than through a major re-planning effort. At the same time, we can be sure that the portfolio of work is driving us toward our long term goals, as each project aligns with an organisational goal. Planning without a major Gantt chart.

References   [ + ]

1. Types of chess games defined at Chess.net
2. Martin Börjesson has put together some nice resources on Scenario planning
3. I’ve already told you 125% of what I know @ PEG
4. The new normal @ McKinsey Quarterly
5. Frederick Brooks on the Mythical Man Month
6. Strategy map defined @ Value Based Mangement by Kaplan & Norton
7. Mission statement defined @ The Centre for Business Planning

I’ve already told you more than 125% of what I know

Bob Sutton has an interesting post on the limits of expertise: I have already told you more than 125% of what I know. As he points out:

I think that those of us who are alleged to have expertise in certain topics can easily fall into this trap as we try to be helpful to others, and rather than stopping and realizing that we are beyond our expertise, we just keep saying more and more about things we know less and less about.

Bob is talking about journalism, but there’s a similar problem with the business-IT relationship.  IT often forgets that subject matter experts don’t always have the answers needed; at least, not yet. Sometimes the subject matter experts need time to convert tacit knowledge —knowledge they know but which they can’t write down, or which they even struggle to explain — into a form which we can consume. Or they might even need time among themselves to create the knowledge together.

I’ve seen more than a few projects come unstuck because they didn’t understand that capturing knowledge is a journey you need to take with the business. The team continually returned to the business for more detail — asking for bullet pointed requirements or stories in a format that IT can easily consume — an approach which often fails, even if you have an embedded SME (à la Agile). (How many agile products have burnt out this customer representative with an overwhelming volume of detailed questions which the representative struggles to answer? Or transformation programmes which try to get the business to predict what they’ll need in a couple of years time, only to find out that they couldn’t predict that far into the future.) Sometimes the business just doesn’t know the answer, or can’t communicate it via our IT artefacts. They’ve already told us 125% of what they know.

We need to provide the business with a little help. This might involve iteration — showing them an early version to see “is what you meant”. It might mean deploying initial functionality into production quickly, and then building on the deployed solution. Or it might involve talking about the the things the business cares about — tasks, decisions, and points of variation, in the case of capturing a workflow — so that they can focus on the outcome they are driving too, leaving IT to worrying about how it might be implemented.

Today, we’re focused on leveraging the synergies between business and technology, rather than simply automating existing business processes. New technologies enable new business models which were not possible before. The business can see the opportunities but doesn’t know what’s possible. IT knows what’s possible, but can’t see the opportunities. Companies that understand this blur the line between business and IT, getting the two groups to work together, on the same side of the table, to identify and exploit these synergies. These companies — such as ZapposP&G and Vanguard — identify and exploit new revenue streams which are unavailable to their peers.

What’s interesting about these companies is that they seem to have realised that building out their IT estate is a journey that IT and business need to take together, rather than a simple matter of IT asking business what they want.

You keep using that word. I do not think it means what you think it means.

Inigo Montoya
Inigo Montoya

[Vizzini has just cut the rope The Dread Pirate Roberts is climbing up.]
Vizzini: HE DIDN’T FALL? INCONCEIVABLE.
Inigo Montoya: You keep using that word. I do not think it means what you think it means.

The Princess Bride

We keep using these words, but they don’t seem to have any meaning anymore.

Agile. It started with agile software, and seems to have spread like a virus to (agile) testing, (agile) architecture etc. At some stage we confused two ideas: agile delivery and agile outcome. One does not imply the other; while your process might be agile, being able to redeploy the team quickly does not guarantee an agile result for the business. You can make your architecture/development/testing team as agile as you like, but if the solution they are working on is a giant furball, then business agility will elude you. And by getting this wrong in the eyes of the business, we’ve made the term next to meaningless.

Architect(ure). Back when I was a lad, every geek wanted to be a grow up to be a systems analyst. None of us really knew what a system analyst did, but the title sounded good, they seemed to be senior and the pay was ok. Some time in the last few years, architect (and architecture) have replaced system analyst in the minds of aspiring software engineers. The minute we reach something like team lead we start calling ourselves “architect”. This puts software engineering in the strange position of having a surplus of architects, but very little real architecture.

Chief Technology Officer. Full disclosure, I carry the CTO title. I prefer to use the acronym rather than spell it out–to avoid confusion. With technology playing an increasingly important role in business, using technology well (or not) can have a disproportionate impact on a company’s performance. The idea behind a CTO is a good one: someone to advise how to leverage technology at a senior level. Though most CTO roles seem to be something else: head of development (nee VP Engineering) product management (Dir. Product Management), or just “big solution architect”. Using one title in so many different ways means that the title has little meaning to the business. I prefer to use the acronym, focus on helping the business solve problems, and let them make up their own mind on what it means.

Innovation. We have big innovations, and small. Industry defining disruptive innovations, and incremental innovation. There’s whole ontologies of innovation. We’re told to innovate our way out of recessions, and to innovate to remain competitive in bull markets. There’s a surplus of innovation activities, yet very little seems to happen. All this thunder without rain makes me yearn for more obliquity. Innovation should imply doing something useful, making a difference, rather than being reduced to a label for an ever growing consulting industry and a lot of talk.

Mash-up. From that first push-pins on a map solution, fusing data from a range of sources (GIS, reviews, yellow pages …), the mash-up concept seems to be growing to include an UI concept that we want to generate buzz around. iGoogle and NetVibes as mash-ups? Aren’t these just a SaaS version of the portals of old?

Synergy. Many things in the business world are done to release “synergies”. Mergers and acquisitions are driven by the quest for synergies. PowerPoint business plans are often considered incomplete unless they line up A and B, proudly announcing that synergies will make it all worthwhile. Why then, do promised synergies so rarely eventuate? We seem to use the term as a vague aspirational statement, rather than a call to action.

More terms as I find time. Send in your own and I’ll add them to the list.

Update: The Economist points out where synergy went wrong.

Update: Added “mash-up” after commenting on Enterprise Mash-Ups in Transition.

Update: You can find my attempt at a clearer and more consistent definition of mash-up over at We need a better definition for “mash-up”.

Posted via email from PEG