The Four Steps of Complex Tasks (Part II)

In the first part of this blog entry, we talked about how complex tasks need to be addressed with a proper problem-solving framework. One such mental framework can be found in traditional warfare. It involves all the anticipated artifacts like headquarters, mission statements and a general’s map, but will likely omit the gruesome parts of actual battle.

We started with the mission statement and then began to make a plan with four steps:

  • Reconnaissance
  • Maneuver
  • Offensive
  • Defensive

Step one: Reconnaissance

In the first step, we tried to unveil every part of the scenario and draw a complete map of the terrain. A botched reconnaissance is probably the root cause of most failed missions. You can read all the details about the reconnaissance step in the first part of this blog entry.

Step two: Maneuver

Emergency preparation equipment on the grass, on the nature backgroundFor a real army, maneuvering means to “change position”. In preparation of a battle, it means to secure the positions that will maximize the own effect and/or minimize the effect of the opponent. Most battles are already decided in this phase, with the following fighting being more or less the playback of the drama the generals anticipated. The ultimate victory in military warfare is the victory by maneuver, when the opponent revises his position before the battle and concedes that he lost already.

In our example case, we wage war on the call for proposals for a big software project. It would be our ultimate victory if we could convince the project owner that no call for proposals is even necessary because we are clearly the best-fitting proposer. But that would have required actions from our side in the past and that chance has passed. We need to prepare for the “fight” under the rules of the project owner, we need to submit a better proposal than everybody else.

Our maneuver step contains every preparative action we need to do so we can play out the last two steps in a smooth fashion. If we need to create an account to submit our proposal, then now is the time to create it. If we need to buy some office supplies to print the proposal in top-notch quality, we should buy them now. Just like a real army stocks their supplies near the anticipated battlefield, we need to stock our supplies, physical like the office supplies or virtual like the user account or a signing certificate.

The goal of maneuvering is to never stall when the last two steps are due. We take our knowledge from the reconnaissance step and interpolate it into the future. The maneuver actions support our scenario of the future. Once the third step is in progress, every negligence in maneuvering will mean delay, makeshift solutions and partial failure. If the negligence is too widespread, it will result in overall failure.

Step three: Offensive

Hiker crossing rocky terrain in the Bryce Canyon National Park, USAIn a real battle, once the maneuvering is done, things “get real”. This usually means that shots are fired. In our example, we also fire shots, but imaginative ones. During the offensive, we really work on the meat of the proposal. We dig into the details of the project and produce estimates and concepts. We use the mandated structure for the proposal to fill our proposition in. We concentrate on fabricating content.

In this phase, things get messy and confusing very fast. There are just way too many details needing attention all at once. This is where our plan from the reconnaissance step comes to our rescue. We need to make sure that we don’t stray from the plan too much. Remember, our “opponent” isn’t moving, it’s a static target. So our plan will stay mostly valid during the offensive. If not, this indicates flaws in previous steps and should be taken seriously. If you can afford it, time- or effortwise, rewind your mission back to step one if you find yourself attacking dummy problems or empty terrain that leads you nowhere. A well-planned offensive has immediate and visible effects.

Your work during the offensive phase might look chaotic and erratic from the outside, but it should be cold-blooded and calculated in your experience. This phase is known to intimidate you with overwhelming feelings of anxiety and despair. Stick to your plan and don’t panic! If you’ve planned it well, it will go well. If you didn’t trust your plans beforehands, why would you even proceed to this step? There is no damage done when your reconaissance unveils a task to heavy for your taste and you make an immediate retreat. There is little loss in surrendering your efforts to an opponent that played the maneuvering game better than you, like requiring several comparable projects as reference for the proposal, but you are a newcomer on the market. It will ache, but you cut your losses and move on. But starting an all-out offensive that you are not sure you’ll win? That’s just stupid or desperate.

Two remarks here: First, Being sure you’ll win means you are sure to fulfill your mission, in our example to submit a valid proposal. That doesn’t imply you need to be sure to win the pitch itself. Stick to your mission statement and win the battle before you try to win the whole war. Second, if you hold back on your offensive, you set yourself up for failure because of indecision and foot-dragging. Every offensive should be all-out or not started at all. You are in this game to win, not to play.

Step four: Defensive

Let’s assume our offensive was successful. In a real battle, we have conquered the enemy’s stronghold or additional terrain. The enemy is defeated. A movie would now show the end credits, a computer game the game results. But this is real life, there is no “end point”. Your troops are all over the place, probably in a sorry shape and without a clear goal to look forward to. If your enemy has any troops left, now is the best moment to run you over. Your victory would be pyrrhic, your winning would finally cause your defeat.

The clever strategist has already planned the defense after the offensive (and victory). Often, this means a partial retreat after the battle in order to “straighten the lines”. We can’t do that in our example, it would mean we take back promises after our proposal wins the pitch. But we can plan our defense after victory.

Let’s assume our proposal wins. What does that mean for our company? Who will work on the project? Can we keep our promises even if external circumstances like other projects, other proposals or our staff changes? What will we gain from the project? What concessions can we make to the customer if he wants to re-negociate? Do we need to re-negociate as soon as the agreement is made? The last question answered with yes is a typical sign of over-commitment in the offensive phase and tells about poor leadership.

In our example, let’s say we’ve promised the customer a 24/7 support hotline for the software. We need to make sure how to fulfill this promise before we send out our proposal. There is no value in making hollow promises that we cannot keep. This would be like losing captured terrain again just because you cannot provide enough troops to secure it. It’s not worth the effort and an all-around damper on morale. Just to be clear here: You don’t need to act on the fullfilling of the promises before you’ve won, but you cannot wait with the planning. So we need to have a clear plan on how to implement a 24/7 support hotline, but we only need to act on it as soon as we are sure it is really necessary. We need to take steps one and two for the support hotline mission, but hold back the later steps until our proposal has won and the contracts are signed.

Don’t omit this step in your planning. A successful offensive without the backing of a good defensive is the prelude to a disaster.

Conclusion

We’ve learnt the four steps to master each complex task, lent from the art of warfare, namely reconaissance, maneuver, offensive and defensive, that form a pattern you can repeat each time with the same structure, but always different content. Every task will require a different solution, but the solution’s framework is always the same. This framework can be applied to tasks that seem to have nothing in common with warfare, but still play by the same rules. This is a powerful tool because it opens centuries of knowledge in military warfare to your creative transfer approach. And it is an effective tool because you don’t need to study history to apply it to your cause. Just reiterate the four steps and conquer your task.

If you’ve already applied these four steps, perhaps without consciously realizing it, I would love to hear your story and the outcome. Please leave your comment below!

Advertisements

The Four Steps of Complex Tasks (Part I)

In software development, we often face complex tasks that need to be addressed with nearly certain success rates. “Failure is not an option” is an easy sentence to say, but hard to implement. As experienced software developers, we’ve learnt our share from failures or near-misses and have probably derived an implicit problem-solving framework for our typical tasks. But what if the tasks are not so typical? What if we need to do complex work where we lack experience – and know it?

Adopting a problem-solving framework

In order to keep this blog entry as practical as possible, lets tell the theory with the help of an example that will be foreign to most software developers: You need to participate in a call for proposals for a big software project. You are responsible for the complete process from downloading and reading all documents for the call for proposals, making sense of the requirements, making a plan and an estimate, writing everything up and delivering your proposal in time and form at the right address. You cannot rely on the help of more experienced colleagues. You will probably feel overwhelmed and a bit helpless.

Now is the time to look for proven problem-solving frameworks that will at least help you coordinate your work and remind you about necessary steps that might go by the board otherwise. There are probably numerous frameworks out there, but I’ve found one to be easily applicable and reliable in the outcome. It’s the four steps of warfare. “Warfare” is a heavy word that isn’t in the dictionary of most people. It really means “to wage war” on somebody or something. But it doesn’t imply death, injury or even a “loser”. If you can wrap your head around the following sentence, we can easily forget its ancestry and follow the steps without any bloodshed: We are about to wage war on the call for proposals.

Being on a mission

We are now on a mission! Every mission starts with the most important piece of information: The mission statement. In this statement, the primary goals of the mission need to be declared as clear and unambiguous as possible. In our example, the mission statement might read like “I want to deliver a complete, believable and feasible proposal for the software project while adhering to all formalities”. It is worthwhile to write the mission statement down and keep it visible. This is your goal, this is why you wage war. Anything you do during the mission that doesn’t help you further your case in regard to the mission statement can be called a distraction (or in agile speak: “waste”).

Analyzing our example’s mission statement, we can conclude that we have two fields of work to cover: the content of the proposal and the formalities of the call. Both need to be covered successfully in order to achieve mission success. It is not enough to have a formidable proposal but send it in too late or without certain required characteristics. And it doesn’t do good to send something awful in that fulfills all technical requirements of the proposal but stands no chance because of its content. You’ve just discovered that your war will be fought on two fronts (content and formalities) and neglecting either one of them will not result in victory. That is an important discovery for the moment you employ your “troops” – time, attention, effort and material in our case.

The four steps

But slow down! We are far away from employing our troops! We first need to learn about the four steps of warfare. With our mission statement at hand, we have to make a plan for these steps:

  • Reconnaissance
  • Maneuver
  • Offensive
  • Defensive

Nearly every military mission can be broken down into these four steps in that order. We cover the first step in this blog post and the following three in the second part next week:

Step one: Reconnaissance

hunter looking through binocularsEvery warfare mission has important things at stake. There would be no mission otherwise, because each mission is expensive. With something big at stake, you want to reduce risk as much as possible. The military way to reduce risk is to gather knowledge about the enemy, to “increase intelligence”. Our “enemy” is the call for proposals with its deadline and rules and requirements. It is an easy enemy in a way, because all information is already made available in clear form and will not change over time. Or is it? Our first move should be to gather and revise all documents that tell us something about the call for proposals. Are we in possession of all available information? Nothing will break our neck more effectively than forgetting to read all documents. The sentence “I didn’t know that!” might sound like a good explanation why the mission failed, but it only indicates that you already failed in the reconnaissance step. Everything you do after a botched reconnaissance has a high risk of being ineffective, useless or downright counter-productive. You need to be sure to survey the complete terrain (read all the documents). A general that says “we don’t need to look behind this mountain, there will be nothing behind it” is in danger of failure as sure as you are if you say “that’s probably all information there is, what else should one want from me?”. Don’t underestimate your enemy! Just because you can download and read everything in regard to your call of proposals doesn’t mean it can be found at one place or will be conveniently available. Double-check that you’ve followed each hint about additional rules (like in general terms and conditions). Read all documents carefully!

When you’ve gathered a complete map of the terrain (have all rules and requirements in readable form), it’s time to mark the problematic features. Make a list of all formalities you need to adhere to. This list is already part of your battle plan. You will later need to employ resources to check off each point of this list. Mark all requirements that you find problematic or surprising. Those are like the strongholds on a battlefield. They need extra attention from you later on. Take your list of simple tasks and tack it on your mission board. If you didn’t have one yet, you’ll have it now. The mission board will look exactly like in the movies when you complete your first step. On top goes the mission statement, with your task list in whatever fashion suits you beneath it (some prefer the ordered list, some might draw a graph, whatever works for you). The mission board is for you and you only, nobody else needs to understand it. You’ve just created your headquarter! Now you have all ingredients to assemble your troops on the battlefield: you know the terrain, where the enemy resides, where you are and what your mission is.

Now is the time to get moving – in part two of this blog entry series next week. Stay tuned!

Recap of the Schneide Dev Brunch 2014-06-22

brunch64-borderedYesterday, we held another Schneide Dev Brunch at last. The Dev Brunch is a regular brunch on a sunday, only that all attendees want to talk about software development and various other topics. If you bring a software-related topic along with your food, everyone has something to share. The brunch was smaller this time, but we held the last brunch only three weeks ago. We had bright sunny weather and used our roof garden, but hurdled in the shadows. There were lots of topics and chatter. As always, this recapitulation tries to highlight the main topics of the brunch, but cannot reiterate everything that was spoken. If you were there, you probably find this list inconclusive:

Student again – from full employee to university

One of our attendees worked as a full-time software developer in the recent years and decided to study again. He told us about the practical challenges of an employee turned student:

  • The bureaucracy at universities is highly developed and not on your side. It takes days to accomplish the tiniest step towards matriculation.
  • To listen again. In the developer world, two hours of highly concentrated programming is satisfying, but two hours of concentrated listening to somebody who tells the important stuff only once is very hard. You are allowed to doze off (just like in big meetings), but it won’t do you no good.
  • Higher-level mathematics. Suddenly, all that stuff about fourier transformation and matrices is very important again.
  • Running on a lower gear. It seems like heaven to replace a 40h work week with a 20h study week, but the irregular pace (one day no lectures, one day lectures around the clock, etc.) will take its toll.
  • Self-organization. Good developers are of course self-organized and know what to do: work on the most important issues in your issue tracker/todo list. But university will not write issues for you and you are the one to fill the todo list. We joked that a “master’s student JIRA” would actually be a good idea.

It was a very entertaining talk and we digressed lots of times. Let’s have a look at some artifacts we came across during our discussion:

  • There seems to be a growing influence from military concepts on management. On book was specifically mentioned: Turn the ship around” by David Marquet.
  • “Bad work, good work and great work”. It’s a marketing video, but contains a message nonetheless. One practical advice is to not include “bad work knowledge” in your curriculum vitae, even if you have expertise in it. This minimizes the risk that your next job will contain a lot of “bad work” again.

The current state of JavaFX

Last year, JavaFX was aggressively marketed by Oracle as the next big thing in desktop UI. The claims and promises seem to finally be fulfilled. The combination of Java 8 and the latest JavaFX is especially joy-bringing. The JavaFX core is included in Java 8 and brings a lot of little but essential improvements. You can layout and design your graphical interfaces with a WYSIWYG editor and store it in XML-based layout files. These layouts are loaded, combined with custom logic and bound to custom data sources. The styling is based on a slightly outdated CSS dialect, but very powerful and done right in comparison to styling in past toolkit like Swing or SWT.

The best thing about JavaFX is that much less GUI code is needed for more pleasant user experiences. The toolkit feels alive and the details tell that the developers care and eat their own dogfood. Integration in the Eclipse IDE is enhanced by the e(fx)clipse project.

Our attendee has hands-on experience with Swing, SWT/JFace and JavaFX. If pressed to choose the technology for a new project, he would choose JavaFX anytime now.

Efficiency killers

We also traded tales about the most efficient efficiency killers in software development that we actually observed or endured:

  • Taking away notebooks and desktop computers and replacing them with zero clients – for developers that really need their multi-cores and gigabytes.
  • Restricting every employee to one (and only one!) computer. If you happen to choose a notebook, you probably don’t need that extra monitor, do you?
  • Installing a “privilege management” software. Basically, this software works like a firewall against user inputs. You want to install a new printer driver? It will be cheaper and faster to carve your text in stone slabs.
  • Fragmenting the company networks. This is actually a very good idea. You can have a wild-west style network for developers and a “privilege managed” one for management. It gets complicated when you need to cross the canyons everytime to get work done. Just imagine that your repository is behind a firewall and you need a clearance every time you want to commit/push.

Introduction to warfare

The last main topic was an overview of a self-study on warfare. And because the typical software developer won’t move whole armies around, it concentrated more on the principles and strategies of “common” warfare, which includes everyday conflicts as well as campaigns for a certain goal (e.g. establishing a technology). Three books serve as stepping stones:

  • The art of war” by Sun Tzu. The ancient classic book about warfare. There are probably a dozen different translations of the original chinese text, but they will only serve as a starter. This book alone will probably don’t give you deep insights, but you will come back to it often when you venture deeper into the mindset of warriors and generals.
  • Die Kunst der List” by Harro von Senger. This german book describes the political and rhetorical battle moves that are often used in everyday life. These so-called strategems can be identified and parried if you know about them. Most of us can react to some strategems by learnt lessons, but it certainly helps to be keen about the rest of them, too.
  • The 33 Strategies of War” by Robert Greene. This book doesn’t mess around. It is part of the “immoral series” of books about topics that don’t get discussed in this clarity often. You’ll learn much about strategies, their actual application in history (not only on the battlefield, but on movie sets, offices and political stages) and how to counter them. The book has a lot of content and many ideas and concepts to think about. And it contains an exhaustive list of literature to continue reading.

Is TDD dead?

We continued our discussion about the debate around David Heinemeier Hansson’s frontal attack on the hype around Test Driven Development. There were some new insights and an improved understanding about the manyfold contents of the hangout discussions.

Epilogue

As usual, the Dev Brunch contained a lot more chatter and talk than listed here. The high number of attendees makes for an unique experience every time. We are looking forward to the next Dev Brunch at the Softwareschneiderei. And as always, we are open for guests and future regulars. Just drop us a notice and we’ll invite you over next time.