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

Aim Small, Miss Small

There is an educational and buoyant if perhaps less jovial scene in one of the most stirring feel-good movies of all times, the 2000 film The Patriot, starring Mel Gibson and the late Heath Ledger (incidentally, an ideal choice for a Valentine’s Day home screening, in my case, however, only by unilateral demand and decree). The movie’s protagonist, Benjamin Martin (Gibson) is swept into the American Revolutionary War when his family is threatened and generally abused by the ruthless Green Dragoons cavalry. It deals with such important themes as single parenting, nation building, and uniting a ragtag South Carolina militia against mighty Lord Cornwallis in the face of indiscriminate carnage and cold blooded atrocities committed by the British. As such it marks Mr. Gibson’s second and most satisfying (and, no doubt here, historically correct) epic “blood libel against the English” war film. Not to be missed but back to the all-important ambush scene.

When teaching his eight-year-old how to shoot a muzzle-loading rifle in order to ambush a British column in the woods, Martin/Gibson admonishes “aim small, miss small,” meaning that if you aim at a man and miss, you miss the man, while if you aim at his button and miss, you still hit the man. As a piece of fatherly-cum-partisan advice not only useful, we shall see, when slaying foreign oppressors and Crown-loyalists in the swamps of 18th Century South Carolina.

“Aim small, miss small,” is in fact also the maxim, if not the credo of the CIO of a Fortune 500 company whom I’ve recently interviewed and whose firm has now implemented 20+ projects using Agile – and that under the governance of the PMO. Some of the key drivers in Agile software development, in the experience of this CIO, work best – or only work at all – when tackled in very small “shots”; these are:

  • Task planning;
  • Effort estimation;
  • Task adherence; and
  • Performance (self) assessment.

For him “aiming at the button” means rather than “big shots” (read the IT leadership team) deciding on the risk management approach, with Agile the development team is asked in real time how to mitigate the risk. Since risk management is embedded in the Agile framework, Agile teams are typically more efficient at identifying and managing risks.

And here the “Agile PMO” fills an important role – as an Agile educator and arbiter that can balance the business needs with the level of compliance in order to eliminate any waste. The PMO collects retrospective information from Agile teams in order to perform root-cause analysis or even run Six Sigma DMAIC. The PMO is also in charge of standardizing the Agile metrics at the organizational level. Then the PMO can statistically determine the organizational burn-down rate or velocity.

Agile for the Enterprise

What is the difference between a 4-year-old’s birthday party and a seminar on Agile software development? The good news: there is only but one similarity, I’m pleased to assure you, and I’m speaking with the hands-on authority of somebody who just celebrated his daughter’s b-day (in the company of her closest, 20-odd fellow pink-is-my-color-princesses) and also just last week hosted a gathering of an impressive PMO Roundtable in the Midwest. This is the story of having one’s cake and eating it too (in our case, a shockingly elaborate and yes, dominantly pink-colored “Disney Princess” cake) and the PMO’s mandate of managing IT projects at the portfolio level and with annual, upfront budgets while whole-heartedly, and so it would appear, embracing Agile as a way to improve the outcome of aforementioned projects. A contradictio in terminis or simply a meltdown (as experienced when the first guest princess bit into my very own princess’s gateau) of conventions?

In what is to follow, I will be blogging about “Agile for the Enterprise” – a topic that couldn’t be any more topical, as CIO Magazine and Forrester reported only last week as well that “Agile Software Development is Now Mainstream” – and that, my dear reader, is a pronouncement that is making me incredibly nervous … And I will tell you why “Agile for everyone” is making me just a bit uneasy – there are two reasons: first, my company Talent Trust is in the business of helping clients meet their IT staffing needs by provisioning highly skilled IT professionals located offshore. If there’s one thing we’ve all heard about Agile – as even the Rugby term “Scrum” would imply – it’s that teams need to collaborate very closely in so-called “Scrum meetings” – and now I’m selfishly wondering if the world is going all-Agile, what’s going to happen to our remote services business?

My second issue is that many of my clients are PMO Professionals – and now I find myself having admittedly bizarre conversations that go along the following lines: “Sorry, Mr. Client, but you insisted on using Agile, so we’re not going to tell you how much this project is going to cost upfront, but please bring a blank check – not entirely blank, all blank that is but for your CFO’s signature, and yes, I promise you’ll be pleasantly surprised – at least I hope you will – and yes, I very well understand: hope is not a strategy – and, furthermore, if I may, please don’t disturb the artist at work – for software development is now apparently both art and science …” You get the picture.

Of course, I’m just setting the stage for my next blog where I will attempt to tie these themes together for us:

  • There are good reasons why Agile has become mainstream;
  • You can do Agile development with geographically and indeed globally distributed team – which is a fact of life for most enterprises (and hopefully means that I’ll stay in business as well!);
  • And that Agile and the PMO can work together – to potentially achieve better results in software development while conforming to such key concepts as governance, budgets, stage-gates, project management, and so forth – again all elements of how IT is managed within the enterprise.

I will be the discussing the following Agile best practices in the “how-to for the Enterprise” context:

  • How the effort estimation / budgeting process works with Scrum, and how Scrum follows project phases (stage gates);
  • How the Project Management Office (PMO) tracks actual-versus-estimates and measures performance, e.g., by Key Performance Indicator (KPIs) / Key Success Indicators (KSIs);
  • How the partnership with the business owners is established and how their collaborative involvement throughout the project is managed (potentially leading to a better alignment between IT and the business);
  • How IT managers build and deploy effective blended (onshore / offshore) teams, using some Scrum-centric best practices and monitoring tools for working with distributed resources;
  • How onshore and offshore (e.g., Argentina-based) resources collaborate as if they were in the same physical work area, delivering Agile benefits as well as cost savings;
  • How Scrum works with other Software Development Life Cycle (SDLC) approaches.