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 (, 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.


Agile for the Enterprise, Part II, or the Good, the Bad, the Dead Pig and the Living Chicken

The difference between a post-mortem and a project retrospective? The obvious answer: nobody has died in the retrospective, and since Agile software development encourages making (small) mistakes (in order to learn from them), the hope is to find the project manager at the finale sitting straight up, still breathing defiantly on the coroner’s table. Which, as far as software-related humor goes, is rather friendly and humanistic compared to Agile’s retelling of the old Sunday-brunch-after-church parable that teaches children the difference between an offering and a sacrifice, the lesson of which has become a tenet of the Agile “movement.”

And here it goes: A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed, but you’d only be involved.” We can all guess who is the chicken (not a kind calling in Anglo-American culture), namely the PM making an offering to the gods of Gantt charts, whereas the developer-cum-pig (and as a male techie I just don’t get it!) is putting more than just the proverbial skin in the game.

Such icebreakers set aside, there is in fact a substantial body of evidence that suggests that a number of Agile-flavored methodologies have yielded significant improvements in software development. The results are defined, measurable, and repeatable and typically involve faster turn-around, fewer defects, and less rework. The benefits are increased business value, better visibility, less risk, and improved team morale / productivity. Another key ancillary benefit, inherent in all Agile methodologies, is the ability to cope with changing requirements throughout the development cycle.

Companies that have adopted Agile and are reporting beneficial results are growing in number both nationally and internationally, are varied in size and industry, and range in diversity from John Deere to Google.

Some healthy skepticism within the CIO community has centered around the notion of exactly what problem domain is most suitable for Agile as a solution framework. For instance, it’s not all that surprising that a “heavyweight” methodology might not be the best fit for a relatively small and fast-paced web development project whose requirements, by the very nature of the project, are in flux and subject to user-driven refinement until completion.

Other critical voices have questioned Agile’s place in the enterprise-level IT organization, where a number of factors (mostly as functions of company scale) can conceivably impede its successful adoption. This is where the values which Agile espouses are prima facie at odds with enterprise realities:

  • Open-ended iterations against frequently changing requirements (versus the need for upfront budgeting and ongoing governance, tracking actual against projected hours and against allocated budgets);
  • Intense collaboration amongst co-located team members (versus the geographically / globally distributed nature of most multinationals’ staff);
  • Self-organizing teams that assign tasks bottom-up (versus the prevalence of command-and-control management structures).

Additional concerns are raised when Agile must co-exist with other, typically stage-gate project management models, as the Agile-developed software is often embedded in a larger development context: whether process integration is possible at all, whether the potential benefits are offset by the duplication in training effort, and/or whether the training of only select staff will lead to a cultural divide between Agile and “non-Agile” team members.

I will not attempt here to prescribe a certain, single methodology but rather suggest a framework of proven practices that has also been shown to adapt to some key enterprise requirements. In what is to follow, I will demonstrate how Scrum will:

  • Fit into the stage-gate project management approach;
  • Support a traditional budgeting process;
  • Sustain common IT governance principles;
  • Work for geographically distributed and blended (onshore / offshore) teams;
  • Integrate and beneficially co-exist with other software development methodologies (e.g., Waterfall Model).

Stay tuned.