How to Survive a Viking Attack, Make a Citizen’s Arrest, and Other Useful Process Flows

Play with me here. In the year of Our Lord 793 you find yourself, regrettably so, on Lindisfarne off the north-east coast of England. The village and monastery on this tidal island are about to be ransacked by the original inventors of the hit-and-run maneuver, and the priory is in line for a much-needed makeover, courtesy of that justly feared Hammer of the North. The sound of those Viking horns makes you freeze like a scratched DVD, and the sight – and not to mention the smell! – of these seaborne savages in their famed longships … you’d much rather have Mickey Rourke in his birthday suit jumping out of your birthday cake any day of the week. Their firey dragons make for terrible portents over Northumbria, and along with the other affrightened inhabitants you get your first peek and whiff of the harrying of the heathen: fierce Norsemen looking like Nick Nolte on the lam – in all exceptional navigators with a patent disregard for personal hygiene – committing rapine and slaughter with such “frenzied efficacy” that The Times would later report: “And they came to the church of Lindisfarne, laid everything waste with grievous plundering, trampled the holy places with polluted feet, dug up the altars and seized all the treasures of the holy church. They killed some of the brothers; some they took away with them in fetters; many they drove out, naked and loaded with insults; and some they drowned in the sea.”

Despite such notable policy failures, as not even trying to win the hearts and minds of the few people left breathing after each raid (and in sharp contrast to say 21st century U.S. military strategy), there was most definitely some method to the madness. Viking attacks were as agile as any Ken Schwaber (“father of”) Scrum. Runic inscriptions on the Kjula runestone and the Inchmarnock “hostage stone” as well as excavated evidence near Roskilde Fjord show that the Vikings had a Dark Ages version of a project methodology. From stating long-term objectives (demographic, geopolitical, securing food supplies), spelling out short-term deliverables (repeatable and best-practice pillaging across the Baltic coastline), to specifying means and tools (a chain-mail hauberk or equivalent armor made of metal platelets, conical helmet featuring a protective nasal bar – sorry no horns on the sides, circular shield of stout limewood, swords, spears, and the dangerously “bearded axe”, and finally, one heck of a bad attitude).

The contemporary writings of Alcuin of York, also known as Alcuinus or Ealhwine, would portray the Norse raiders as self-organizing teams that were adapt at responding to change, as opposed to following a plan; amenable to collaboration but disdainful of contracts; they were leaning more towards being individualistic rather than being process-oriented; and had there been software in their days, they’d definitely prefer it to be a “working prototype” over comprehensive documentation. The Vikings as ideological brethren of today’s Agile software development teams? How preposterous! What would that say about the interplay of process and discipline (or the respective lack thereof) which is so crucial to Agile? And is there perhaps an element of “chaos” that might serve a certain purpose, after all?

In Agile software development, discipline without process is blind, while process without discipline is empty (to borrow from Kant’s famous dictum). Discipline and process are indeed intertwined in Scrum which is an iterative framework for Agile software development and project management. Work is structured in cycles of work called sprints, iterations of work that are typically two to four weeks in duration. During each sprint, teams pull from a prioritized list of customer requirements, called user stories, so that the features that are developed first are of the highest value to the customer. At the end of each sprint, a potentially shippable product is delivered.

When Jeff Sutherland created the Scrum process in 1993, he borrowed the term “scrum” from an analogy put forth in a 1986 study by Takeuchi and Nonaka, published in the Harvard Business Review. In that study, Takeuchi and Nonaka compare high-performing, cross-functional teams to the scrum formation used by Rugby teams. Ken Schwaber formalized the process for the worldwide software industry in the first published paper on Scrum at OOPSLA 1995. Since then, Scrum has become one of the leading Agile development methodologies, used by Fortune 500 companies around the world. In short, Scrum is made up of three roles, three ceremonies, and three artifacts. The three roles are: the Product Owner, who is responsible for the business value of the project; the ScrumMaster, who ensures that the team is functional and productive; and the self-organized team. The three ceremonies are: the sprint planning meeting, daily scrum meetings, and sprint review meetings. Lastly, the three artifacts for prioritizing and tracking tasks are: the product backlog, the sprint backlog, and the “burndown” chart.

There is no (more) denying that Agile software development is more successful than traditional project management for software delivery (e.g., a sequential software development process like the waterfall model). Just like it’s a historical fact that Viking attack were messy but effective. In the past, the Agile community used to defend its own “messiness” (we’re not code-slinging cowboys, but a little creative chaos is a good thing) and try to prove its effectiveness. Nowadays, Agile has become so mainstream that its leading practitioners are at pains to explain how it is still different – especially when deployed at large project scales – from previous process improvement methodologies. After all, once the hullabaloo and proto-Norse shouting had subsided, was a Viking formation really that different from say a Roman legion? Having run a number of larger Agile projects myself for our clients at Talent Trust (http://www.talenttrust.com/), I can offer up three observations for why Agile is indeed different and better:

  1. Just by virtue of being an “improvement process” alone, it forces you to define the things that you wish to and need to observe, measure, and effect. Even if you didn’t follow through on the rest of the methodology, you’d already have gained an advantage by creating a “map of key observables” in the software development lifecycle.
  2. Agile really won’t work unless you’re very disciplined – no mystery there, as you’d have to be more disciplined to compensate for less process rigor. But furthermore, it is discipline that matters: a regimented approach to team training (otherwise nothing will work); closely controlled and strictly enforced adherence to scope; a rigorous way to do effort estimation; and an open and honest peer-based culture of information sharing. Yes, all of this takes tremendous discipline on a daily basis that will naturally accrue to the benefit of your project and IT organization.
  3. An explicit acknowledgement that software development is both an inherently creative and collaborative process. Just putting the words “software,” “creative,” “collaborative” and “process” in one sentence will give you a clue that there’s a creative spark at work here that’s a) difficult to manage and b) the cause of consternation for “traditional types,” as predictable schedules have indeed become a thing of the past.

As an aside, the odds of surviving a Viking attack, especially if you were a book of hours-illuminating or medicinal Rosemary-plucking monk ca. 793 – 1066 A.D., were about as low as a George Carlin joke. However, here’s what you can do to increase your chances of living to fight another day: a buddy system is always recommended, though an early-warning system (sentries stationed in equal spacings along the seashore) is deemed to be even more effective. Brush up, if you can, on your dönsk tunga (the “Danish Tongue”), norrœnt mál (Norse language), or Old Gutnish, a peculiar Gotland dialect, for these brutes didn’t speak English at the time, and translators were typically the last in line to meet Odin, Thor and gang. If you can muster the courage, it will be to your advantage to use long-range weaponry such as the English longbow or a crossbow, as your Viking opponent will prefer to slay you in hand-to-hand combat, which he believes to be infinitely more honorable than distance-killing (take that for a fact, Mr. Rumsfeld). And whatever you do, don’t feed their cute little birds of prey – they’re raptor gryphons trained to eat your eyes out.

And to follow through on the other title teaser: you must adhere to a very specific process when apprehending your felonious fellow man, if you’re not acting as a sworn law-enforcement official. Notify authorities if you can; evaluate the situation clearly; say “Stop;” inform the suspect that he’s under citizen’s arrest; try to convince him not to leave until a police officer comes; be firm and matter-of-fact; in the U.S., a Miranda Warning is only required if you are both detaining and questioning the suspect at the same time; for clarification, you do not need to read the suspect his rights if you first question and then detain him; call the local authorities and identify yourself to the police when they arrive; try to stay calm at all times. This is, of course, an example of a process flow that is bound to get you in trouble – and probably end up looking like Rihanna if you try to do this at home and home happens to be Queens – if you’re not agile and you don’t have the discipline (or in fact the guts) for follow-through.

Advertisements

About Christophe Kolb
Christophe Kolb is Executive Chairman and co-founder of Talent Trust. Headquartered in San Francisco, Talent Trust employs mobile experts at our own development centers in Córdoba, Argentina and Lima, Peru. Our talented people are seasoned technologists with solid backgrounds in software engineering and cutting-edge skills in mobile web / HTML5, Android, iPhone / iPad, and BlackBerry. We have the technical expertise, industry knowledge, and proven capability to deliver winning mobile solutions, and have done so for some of the world’s greatest companies. Our mission is to help our enterprise clients win in mobility, with: • Captive development centers in Córdoba, Argentina and Lima, Peru • Same time zone advantage for U.S. clients, enabling real time communication • Cost-effective offshore development solutions for mobile • Focus on mobile for enterprise clients • 10-year track record of successfully servicing a blue-chip client base in predominantly multi-year relations • Agile development methodology (Scrum and Kanban) • Close collaboration with clients / Product Owners (daily stand-up meetings) • Excellent English communication skills

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: