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

Afraid of The Invisible Man (or the Remote IT Worker)?

Whenever I travel extensively and am naturally engaged in a remote working relationship with my colleagues from head office, I experience first-hand the chief tenet of our firm’s value proposition to clients: that with a little know-how just about anybody can tap into and benefit from a remote workforce. Whether you’re already part of a distributed IT organization with geographically dispersed teams, or you wish to engage remote workers in order to source or supplement skills that are locally scarce or unavailable, or whether you’re in the market to save money with offshoring, a number of key Do’s and Don’ts apply.

Although there are different engagement models when it comes to working remotely (e.g., managing a remote individual or stand-alone team vs. managing that individual or team as part of a larger and by definition even more distributed team), and hence different best-practice prescriptions exist for how to maximize the chances of a successful engagement, I will share a list of common success factors that make up what I call the “Parity Principle.”

For the sake of argument, our Parity Principle says that in order to make working with a remote person (located say in Buenos Aires, Argentina) as effective as working with someone in the proverbial cubicle next door, there is additional requisite behavioral activity that, when conducted properly, creates efficiency that, over time, offsets the “cost” of the behavioral change required in the first place. While there is in fact a scientific basis for measuring changes in management behavior and concomitant productivity levels, I will give you a commonsensical intuition for what this principle is all about.

Imagine you’re an IT manager and you’ve just called up your local recruiter to help fill an open, say highly specialized and three-month position with a local consultant. The contractor now reports for duty on Monday morning, and is presumably given a desk to work and shown a tour of the facilities, while you collect your thoughts on how best to familiarize, indoctrinate, and instruct your newest team member in order to make him or her as productive as possible on the task at hand. Communication with the consultant on the first day, for the first week, or for that matter for the entire three-month duration, can be spontaneous, on an as-needed basis in order to answer any questions or resolve any issues. And then there is always the iconic water cooler around which co-workers congregate for informal team discussions, and where even a slight gesture or expression of frustration can be more meaningful than a red-flagged item on the project’s Gantt chart. And lastly, you keep regular taps on your consultant using the most effectual management technique known since Peter Ferdinand Drucker left his native Vienna: managing by walking around (in other words, a quick stroll to the cubicle, a quick status check, a look at the screen, and you’re in the know again).

Now compare and contrast the situation with a remote IT worker. All the management activities are the same, but in general everything takes a little more preparation, a little more formality (watch out water cooler, here comes the water wiki!), and a little more follow-up. The Parity Principle now asserts that all that “little more” that is required to manage in a distributed work environment will accrue to the overall benefit of the project and the team (tangible results through a slight perhaps but measurable increase in standardization, formalization, and day-to-day discipline). A short-list of the most common success factors then looks like the following:

  • Planning (on behalf of the local manager);
  • Communication;
  • Collaboration tools;
  • Proactivity (on behalf of the remote IT worker);
  • Governance processes for a distributed IT environment.

In my next blog I will discuss these key factors in detail and within the offshore context. Of course, the world of work is rife with anecdotes of how, for example, communication with the “invisible worker” can be especially challenging when not only bridging geographic but in addition cultural distances. (An old favorite comes to mind that chronicles the travails of a German radio operator at high seas fielding the desperate plea for help of a sinking American vessel; listening in anguish to the repeated “Help, we are sinking” calls, he finally musters the courage to respond in English: “Yes, I hear you, but what are you sinking about?”)