How to Think in an Agile Way

This chapter is from the book

Business Analysis Agility: Solve the Real Problem, Deliver Real Value

Learn More Buy

This chapter is from the book

This chapter is from the book 

Business Analysis Agility: Solve the Real Problem, Deliver Real Value

Learn More Buy

Wicked Problems and Gordian Knots

Sometimes the problem is more than a routine one with a routine solution. Sometimes the problem is complicated (consisting of many interrelated parts), and sometimes it is beyond complicated and we must think of it as a complex, chaotic, or wicked problem. Road traffic is a wicked problem. There are many variables and random variations—a truck breaks down, a building close to the road catches fire, and traffic accidents occur. You might also know these problems by other names. Here we are touching on systems theory, chaos theory, complexity science, and several other ideas and naming conventions about chaotic systems and messy problems.

Let us explain the heading by means of this allegorical story.

A legend from centuries ago has it that an oracle at Telmessos decreed that the next man who drove into the city in an oxcart would become the king of the Phrygians. (You’ll have to look this up.) As it happened, the next man through the gate driving an oxcart was Gordias, and he was duly declared to be the king. (This way of choosing a leader might seem a little bizarre, but given the state of today’s world, we might have better luck if we used this approach to choose our political leaders.) Before striding off to take up his kingly duties, Gordias tied his oxcart to a post using an elaborate knot, which brings us to the point of the story: the knot proved impossible for anyone to untangle, despite another decree that whoever could unravel the Gordian knot was destined to become the ruler of all Asia.

Skip forward a few centuries, and onto the scene comes Alexander the Great. Alex is magnificently ambitious; he wants to rule over the vastness of Asia, so he sets about untangling the Gordian knot. Realizing after a while that he was getting nowhere with the knot, Big Al unsheathed his sword and sliced the knot in half with a single stroke.

Did he solve the problem of the Gordian knot?

No and yes.

Click to view larger image

He didn’t solve the problem in the way he was supposed to; that is, he didn’t unravel the knot. But he came up with a solution.

The Gordian knot here is a metaphor for a unique, complex, wicked problem—a problem that is so difficult that it is impossible (or close to it) to say what the requirements are and to say whether any proposed solution is right or wrong. All we can say is that a solution might be better or worse, but given the complexity of the problem, it might be impossible to determine which of several proposed solutions is the best one.

We solve Gordian problems by experimentation. For example, Alexander might have experimented with other solutions, such as releasing insects into the knot to see if they would chew it apart. He might have set fire to it. He might have subjected it to intense infrared light causing the rope to rot. (This would have been quite a feat in the fourth century BC.) He might have lifted the linchpin out of the post to release the knot.

• There are no completely right solutions to Gordian problems, just better or worse ones.

There is nothing to say that any of these solutions is better than the other. All we can say is that Alexander found a solution.

Let’s leave Alexander to go off and conquer Asia and come back to Jack (and Jacqueline, our nimble analysts and their friends on the team). Let us consider what would happen if, instead of looking at each problem as routine with a routine solution having an “as is” and a “to be,” Jack sees all business problems as wicked, or Gordian, problems. Instead of grinding out a routine solution that delivers mediocre value, he places himself in a situation in which he is forced to find a progressive solution and to perhaps go beyond the original problem to find solutions that bring greater benefits to his clients.

Instead of saying, “This is as it is now, and this is what we want it to be” (the routine, assumed solution), Jack, Jacqueline and the team say, “How might we solve this problem? What other solutions can we find for this problem? What better value might we deliver to our customers?”

Instead of delivering the routine billing system, can you find a more convenient way for your customers to pay for their energy consumption (or anything else)? Instead of your customers ordering their office consumables online, can you find a predictive, preemptive, effortless way of supplying them?

Although this seems to be going beyond the original brief and might seem to be spending unnecessary time, you must keep in mind that the real objective of your project is not to deliver a mediocre system in the minimum amount of time but to deliver the maximum possible value. (Keep in mind that delivering value and delivering a product are not necessarily the same thing.)

• You must make your client aware of the potential value rather than the assumed value.

We are not for a moment suggesting that you have unlimited time on your hands. After many years of project work, we understand that projects should last not a minute longer than absolutely necessary. However, experience has shown us the immense amount of time wasted by projects delivering poor results. Instead of wasting time, let’s time-box the work of generating and experimenting with solutions. Let’s not close in on the first assumed solution but allow a little time for further discovery to find new value to deliver. You must make your client aware of the potential value rather than the assumed value.

You should also take into account the continuing—dare we say eternal?—nature of solution development. Whatever you deliver will, sooner or later, need to be modified or redeveloped. The world continues to change, and our solutions must be kept alive by keeping them current. This means that the Möbius strip illustrated in Figure 7.1 is not only a metaphor for a solution development project, but also for the lifetime of the solution. The best way known to slow down the redevelopment of solutions is to deliver the best possible solution—one that is so closely matched to the essential needs that its customers do not want it to change.

Figure 7.1 Agile business analysis discovery and delivery is a continuous activity, shown here as a Möbius strip. The Möbius strip has no beginning or end, signifying that discovery and delivery are not joined by a straight line from “as is” to “to be.” The strip also reminds us of the ongoing maintenance and redevelopment of our solutions.

How might you do this? How might you discover and deliver better, more long-lasting solutions?

The Next Right Answer

Jack and Jacqueline are always thinking about, and looking for, the next right answer. Consider this scenario: you are presented with an assumed solution—the product—and asked to build it. You faithfully build it, and once built it turns out that no, that’s not quite what is needed. “We’ll have to do it again, but we’ll get it right this time.”

Instead of the above scenario, consider not building what is asked for. Instead, ask if there is a better solution—one that better matches the problem, one that delivers better value in a better way. And there will always be a better solution; it’s the next one you think of. And the next one after that.

Very few of the notable consumer products come to market in the same form as they were first proposed; they go through rethinks and iterations and many, many prototypes before they make it to the production line. The best buildings are designed and redesigned before the construction crews move in. The best software is never the first thing proposed. Rather, it is rethought—sometimes many times—before being constructed.

• The next right answer is sure to be better than the one you have now.

There are reasons these changes of mind happen. Sometimes the team members realize that they have misunderstood the problem and need to rethink their solution. Sometimes, though less often, they realize they have implemented the wrong solution to the problem. Sometimes the ecosystem changes mid project, and this results in the team rethinking its solution. And sometimes, partway through the implementation, the team simply has a better idea. None of these scenarios should be considered failures. They all contribute to a better end product.

This is not to say that the project is delayed indefinitely while endless redesigns are presented. But it is to say that you should be open-minded and inquisitive. Agile analysts don’t meekly accept the first proposal. They challenge it and usually find a better one.

• Agile analysts don’t meekly accept the first proposal. They challenge it and usually find a better one.

Looking Outwards

You cannot be expected to always be a magical source of great ideas. Nobody can. However, when we don’t have our own great ideas, it’s a great idea to look at someone else’s ideas. Much of the time, great ideas can be found outside your own team, department, organization, or industry. Industrial designers are constantly borrowing ideas; architects, artists, and musicians are inspired by others. This does not mean plagiarizing other people’s inventions, but abstracting from ideas, adapting them, and being inspired by them to find better solutions for yourself.

Making abstractions about one piece of work often leads to solutions that apply to your piece of work. Henry Ford came up with the idea of his Model T assembly line after seeing how a meat processing plant worked. The tricuspid valve from the human heart was adapted to make one-way valves for water and shampoo bottles. Velcro was invented when Swiss engineer Georges de Mestra noticed how burrs from the burdock plant stuck to his trousers and his dog after a walk in the mountains.

There are an infinite number of wonderful ideas out there just waiting for you to make an abstraction, make an adaption, and make an innovative solution for your customer’s problem.

Continuous Improvement

We know that “continuous improvement” is a tired cliché. But before you skip this section, please give us seven seconds. We know you’re exposed to thousands of self-help books, videos, advice, inspirational messages, and other miscellaneous well-meaning but not helpful drivel. Most of that stuff won’t help you be a more nimble team member. Perhaps some of the rest of this section won’t either. But it might. Thanks for your seven seconds. You are now free to read or skip as you wish.

There are two things that you can make better: yourself and your clients’ business processes. They are interrelated—the better you are, the better they will be. The converse is also true.

There is an old saying:

• “If it ain’t broke, don’t fix it.”

You hear this all the time—usually from people trying to avoid their responsibilities and avoid doing any useful work. But look what happens when you reverse the sentiment of the quote:

• If it ain’t broke, fix it.

Was your Nokia phone broken when Apple announced the iPhone? Could you still make calls and do the things you bought the Nokia (or whatever phone you owned) for? Of course, you could. Yet you and two billion other people bought an iPhone, an Android, or a Google phone. Why? To get something that worked better for you—better than the working product you already had.

You read books; they work. You can turn the pages and absorb the words, receive entertainment or knowledge, enjoy the experience. Reading a book works. Yet millions of people now do some—sometimes all—of their reading on a Kindle reader or some tablet device. Reading books wasn’t a broken activity; we just found a way to make it more convenient. Or consider the current upsurge in millennials listening to audiobooks. Books weren’t broken, young people wanted a different, more expedient way to have their books.

Do you think that Samsung waits for customer complaints before improving its phones? Nope, it just goes ahead and makes a better phone. Do you think Amazon waits for customer feedback before finding new ways to make its shopping experience better and slicker? What about your bank? Are its systems as good as they can be? Are the systems continuously upgrading and improving? If your bank is not impressing you with its best services and customer experience, it is time to change your bank (or your insurance provider, or your energy company, or your phone company, or your shops, or anything else that you deal with).

• Necessity is no longer the mother of invention. Improvement is.

The best fixes, the best improvements, usually come not from dysfunctional products and systems, but from healthy ones in which the custodians are interested in continuous improvement. Necessity is no longer the mother of invention. Improvement is. This is illustrated in Figure 7.2.

Figure 7.2 If it ain’t broke, fix it.

Why Are They Complaining?

You’re at home. There’s a pair of dirty socks on the floor, and it irritates you. You complain to the other (or others) that live with you. Let us for the sake of illustration say that your complaint is erudite, well-reasoned, crafted in elegant and meaningful language, includes some ingenious disparagements, and is worthy of the great orators. Your audience is naturally stunned into submissive silence. Now take a moment to stop your flow of words and ask yourself, “What am I really complaining about?”

Is it simply that someone left socks on the floor? Or is this a complaint about habitual untidiness? Or that the washing machine is broken, and you know laundry is piling up? Or there is nowhere suitable for depositing dirty laundry? Or the owner of the socks doesn’t have enough socks and a dirty pair gives him one less, and if he could just stir himself to do his laundry occasionally, he (and you) wouldn’t have this problem? Or could it be that your dwelling is too small and you need to share a room, which you don’t want to do, particularly with someone who leaves dirty socks lying around? We’ll stop these questions; you’ve got the point.

There are lots of reasons to complain, and all too often people complain about the wrong thing. Or to put that a better way, the subject of their complaint and the reason for their complaint are not the same thing. You were talking about socks; the underlying problem was sharing a room.

Let’s leave the socks where they are and go to work. Your client is complaining about something, and it is safe to say that the complaint is not about dirty socks. But what is it really? If you accept what is said at face value and metaphorically pick up the socks, you merely respond to the first complaint. But is that the actual cause of the complaint? Until you find the root cause, anything you do is no more than putting a Band-Aid over the apparent wound and failing to identify and eliminate the actual problem.

• Continuous improvement can only happen when you address the root cause of the problem.

Does your complainer understand the root cause? Or is he complaining about the symptoms of it? Is this person complaining about something because he lacks the authority or knowledge to complain about his real issue? Is he in denial about his contribution to the problem?

This is not easy, but you need to keep swimming upstream, questioning every effect and its cause until there can be nothing left to question. Only then will you arrive at what you need to fix. Continuous improvement only happens when you address the root cause of the problem.

Enlightened Anarchy

Every organization has a procedures manual. This manual sets out how the organization’s business processes should be carried out, gives the rules for the processes, and usually has a few pages of inspirational words to say about what a wonderful thing it is that the corporation has put together this procedure manual. People in the organization believe their processes and their systems run in close alignment with the procedures manual.

But it’s not all true. That woman in accounting, whom everybody seems to like, is busy and enjoying her work. If you can ever get her to tell you the secret, it would sound something like this:

• “We’re supposed to use guaranteed bank loans for our Asian suppliers, but some of the Hong Kong banks are very slow to come through with these. I get around that by using irrevocable letters of credit. I can get these very quickly, and my friend Bobby in the foreign department puts them through his system to make it look like guaranteed bank loans. The result of this is that we pay the suppliers more quickly, and Alex, our procurement manager, has an informal agreement with most of the suppliers, which results in us getting a 2% discount for prompt payment. They love it, we love it, and our bank has assured us that it is the best thing to do; just please don’t tell the operations director because she’s a real stickler for procedures. If we did it her way it would be slower and require a couple of extra people, and we would pay more for our supplies.”

This is a shadow system. Shadow systems exist in practically every organization, and they are put there by the shadow people. These are the people who see ways that they can improve their systems and have neither the interest nor the time for the tedious negotiations needed to change the procedures manual.

The nimble analyst often works in the shadows. If there is a better, simpler way to do something, and providing it does not transgress any meaningful business rule, then Jacqueline goes ahead, builds an effective shadow system, and does not mention it to anyone who is not immediately affected. She gradually brings the best of the shadow systems into the mainstream.

We are by no means advocating complete lawlessness here, but we have seen benefits from people operating in the shadows. You must approach this thoughtfully and leave behind enough documentation to allow others to follow. You must, of course, create a superior system. Providing your results are useful to others and do no harm, we see little wrong with a measured amount of enlightened anarchy.