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

Leverage or Perish!

The scenario is an all-too familiar one: meet the Head of Application Development for a multi-billion-dollar revenue firm with global operations. For this account, we shall call him “Mr. Stockbridge” for his territoire includes all software old and new, building, maintaining, upgrading, and further integrating the application portfolio – sometimes referred to as “the app zoo” – as well as R&D, and which is delineated in jovial collegial “Upstairs, Downstairs” manner, literally by a flight of stairs and if by Higher mandate from the realm of his peer, the CTO and “the guys down below” who worry about such seemingly trivial ‘plumbing matters’ as infrastructure, hosting, datacenters, data privacy, overall systems performance and security, etc.

Mr. Stockbridge – a lot less standoffish and snobbish a man than his celluloid namesake, the Marquis acted out to perfection, of course, by the loveable Anthony Andrews opposite the venerable Gordon Jackson – has a problem, a big one, and a hard one as such, but he’s not alone with it (oh, what I meant: unfortunately, he is all alone with his own problem, but other Heads of Application Development at other firms have it, too).

You see, his boss, the company CFO nonetheless (incidentally, in many a corporate hierarchy nowadays a most logical configuration, for whose avuncular fingers are better equipped to clip the wings of Icarus, to curb IT’s flight too close to the sun of techiedom, and to keep in check that otherwise rampant overreaching, overspending, and overpromising that’s supposedly just what ‘we IT guys’ do), has returned from his prolonged budget meeting on Mount Olympus to make the following pronouncement which surprises no one but likewise scares everyone: the current headcount will stay flat until year-end, though an imperceptibly small budget increase for new “specialty” hires has been approved for those projects dear to the CFO’s heart. IT is expected to not only maintain but to increase productivity and project output by an estimated 30% (take that to your next Committee hearing on the “jobless recovery,” Mr. Bernanke). To make matters worse, the technology mix has shifted considerably over the last 12 months thus challenging the ‘skills readiness’ of a good portion of the staff to be able to outperform (if even just to perform) in their present jobs. Plus there are some further hard architectural choices to make (for that global webification push!) that demand more than just the proverbial blood, sweat, and tears – they require the brains of people not distracted by playing perpetual catch-up with that ever-growing backlog of ‘IT business requirements’ dispatched, unfortunately, by those who pay the bills, the business owners. And lest I forget, Mr. Stockbridge, the charismatic new head of Sales & Marketing with that operatic temper (charming only to the colleagues in Italy and Spain) is loudly asking about the new CRM rollout that was promised this quarter (there we go again). The United States Marine Corps has a saying to sum up such rank sentiment: “the beatings will continue until morale improves.”

In fact, I’ve just returned from a visit to Stockbridge’s office-cum-requisite-war-room, a cerebral but no less acute situation desk to make General Petraeus proud – with, surprisingly, no blood on the floor but rather a set of well-thought-out, high-level objectives on the white board:

  • Make do with what we have;
  • Make small changes (that’s all we can afford) that make a big difference;
  • Leverage the existing team (never forget: team motivation is key!);
  • Create an elastic and offshore-leveraged workforce (review local consultant spend vs. a “global flexforce”?);
  • Assess offshore readiness (who on the team can manage in a distributed project environment?);
  • Assess skills gaps in the organization (and how do we bridge them?);
  • Up-skilling / right-sizing / bringing in external help (caution: difficult conversations ahead!);
  • Shorten the path-to-beneficial-use for upgrading internal or importing external “new” skills (if third-parties, whom to trust?; and sorry, no, we cannot afford IBM or Accenture);
  • Centralize solutions portfolio / central hosting / local configuration / create global best practices for deployment (divide and conquer: local vs. global teams);
  • A focused, effective, and realistic approach to upgrading our project management skills to improve outcomes (but please no Greek letters!);
  • Go make it happen!

It won’t come as a mortal shock to my regular readers that the aforementioned white board scenario represents a near-perfect use case for why IT leaders should consider remote staff augmentation. Together with the right remote staffing partner, you will selectively and quickly deploy IT professionals located offshore and manage them as a virtual extension, so to speak, to your own team. Your staff will not panic or lose morale, as you’re not really offshoring entire projects or outsourcing entire functions (and remember the old adage that you should never outsource your problems). These remote IT professionals can either be tasked to maintain legacy code, while your local team can be charged to tackle the new and technically more cutting-edge projects, or vice versa (if perhaps you’re lacking those ‘hot skills,’ such as Ruby on Rails, internally). Furthermore, by having your line managers manage these resources as part of a distributed work team, you will quickly realize improvements – by “gentle necessity,” that is – in project management skills and outcomes, as your people will bring just a little more forethought, discipline, and governance to bear on these distributed projects. No McKinsey, no Six Simga needed.

Good luck, Mr. Stockbridge, who incidentally just called back after somebody had ‘misplaced’ a flipchart of additional “what remote staff augmentation can do for you” notes in his office:

  • Typical savings range from 30-50% compared to the cost of local consultants;
  • Stretch the budget to really do more with less (e.g., eliminate project backlog, improve IT’s responsiveness to business requests);
  • Acquire IT skills that don’t exist in-house or are scarce in the local market;
  • Rapidly deploy IT professionals (individuals or teams) as contractors without additional staff overhead;
  • Handle fluctuations in project demand through “talent on tap” (smoothing out the troughs and valleys in workload while maintaining fixed staff level);
  • Enjoy the direct benefits of going offshore without the hidden costs / risks (no set-up cost, no minimum project size); and
  • It’s a solution that works for companies of all sizes and is viable at any project scale.

The Death of Distance – The Sequel

Call me a techie, something of a science-minded Skeptic who looks upon the ever-growing shelf of self-help titles for the executive set (and aspiring cadre) with a mixture of some bewilderment, little amusement-cum-disdain, and lots of professional jealousy. How come “they” have it and “we in IT” don’t? Meaning the inspired and adapted learnings of history’s greats to better one’s management skills. Just imagine our very own reading list: “Metternich on Winning Over Business Owners,” “George Smith Patton III, the Gatling Gun, and the Importance of IT,” or “À la Bonaparte – Supreme Power to the Little Guy” …

Nothing, however, beats management by Sun Tzu, his 6th century BC The Art of War a timeless classic on military strategy and thought. This enduring treatise which is, of course, shockingly contemporary in parts, stresses the importance of deception, cunning, and spying on others; not doing what you say you’re going to do emerges as the leitmotif, while it offers helpful advice on how to turn spies, punish turncoats, poison wells, and generally deal away with modern-day peasants in feudal lands, speak voiceless underlings. Self-proclaimed Machiavellian corporate strivers and intriguers may be strangely drawn to Il Principe, short enough of a posthumous Renaissance political essay to be digested between cafeteria lunches, where readers will be instructed in the method of acquiring necessary ends by any means, even if they are cruel. Supply chain management (SCM) types will find well-founded solace in being the rightful heirs to no other than Gaius Julius Caesar, partly-Consul and mostly-Dictator of the Roman Republic, his only regret when crossing the Rubicon not having had the SAP BI Platform to help track the dwindling corn supplies which would cripple his Gallic campaign. And finally, if you’ve been too successful a manager, beaten the competition to a pulp, and even your grinning shareholders are worried about your Emotional Intelligence (EI) score, there’s always Hildegard of Bingen to help you get back in touch with your inner Medieval Benedictine abbess, herbalist, poet, and channeller (the lesson there: don’t be afraid of your own success!).

But no, we (in IT) shall have none of that! We prefer such solemn encouragement as “attitude is a little thing that makes a big difference” from noted statesman, gifted orator, and arguably one of the greatest 20th century task masters in a distributed environment, The Right Honourable Sir Winston Churchill. Churchill managed one of the largest physically distributed field operations of his days by a set of rules that are prescriptive for any remote IT engagement:

  • Plan (vigorously);
  • Communicate (constantly);
  • Collaborate (and get the best out of others);
  • Be proactive (and always visible);
  • Govern (keep and refine metrics of success);
  • And, of course, persist (never, never, never give up – remember this is the man who said: “If you’re going through hell, keep going.”).

To optimize outcomes, Churchill was fond of running alternative scenarios, a quick A vs. B “hypothesis testing” for every decision he made. I’ve applied the same method, including some probing questions, for helping us determine an optimal approach for setting up a remote resourcing environment:

  • Captive vs. Non-Captive:
    The benefits of a captive offshore operation are obvious (dedicated resources, significant cost savings after start-up costs are recouped / no middleman, full control / security, quality imprint, in-house culture / communication, in-market sales presence, etc.); but some of the drawbacks may be less obvious (static resourcing / difficulties with right-skilling and load-balancing, dependence on single geography / economy / labor market can mean wage inflation / talent shortage / staff attrition, bench- and lead-time challenges responding to user demand, etc.). What criteria would you use to weigh the benefits/drawbacks of a captive vs. a non-captive offshore operation?
  • “DIY” vs. Managing Vendor:
    Faced with the task of setting up and managing a portfolio of multiple, sequential vendor relations, what ‘value equation’ would persuade you to outsource vs. in-house the management of that portfolio? (E.g., managing-vendor expertise, economies of scale associated with managing the costs of (sequential) vendor discovery, setup, transition, and ongoing coordination, etc.)?
  • Single Partner- vs. Multi-Vendor:
    When considering a non-captive offshore operation, what decision criteria would you use to establish a partner-based vs. a vendor-based approach? (E.g., cost- / risk-sharing, price breaks based on volume, other commitments from a single partner vs. “best-of-breed” every time / breadth and depth, flexibility / no single point of dependence when sourcing from multiple vendors, etc.)
  • Tier-1 vs. Tier-2:
    What is your experience working with tier-1 vs. tier-2 vendors? (E.g., professionalism, process maturity / CMM:5 vs. entrepreneurship, “working with heroes,” etc.). Can you relate to the statement “quality is not a function of size”?
  • Offshore Success – Inhibitors vs. Enablers:
    In your experience, what are some of the key inhibitors (e.g., potential lack of capital, scale, reach, process maturity, ‘hidden costs of offshoring,’ etc.) and enablers (e.g., people, process, technology) to offshoring success? Do effective Service Level Agreements (SLAs) increase the chances of success?
  • India vs. ‘The Rest of the World’:
    Have you had experience resourcing from some of the “other” offshore regions: South America (e.g., Argentina, Brazil), Eastern Europe (e.g., Romania, Ukraine), North Africa/Egypt, Southeast Asia (e.g., Vietnam), China? How would you relate this to your ‘India experience,’ if any, in terms of critical success factors (e.g., quality, flexibility, cost – i.e., is India – with its ~30% staff turnover and ~20% wage inflation – trending after Ireland which priced itself out of the call-center business in the 90s?)?
  • Synchronous vs. Asynchronous:
    What are the key drivers for you to insist on time zone overlap to enable synchronous (e.g., U.S. / South America) vs. asynchronous collaboration (e.g., U.S. / India)? What experience have you had, if any, with more advanced “follow-the-sun” and multiple-shift 24×7 development / support models?
  • Standalone vs. Distributed:
    Have you noticed an increase in complexity managing remote resources as part of a distributed (onsite-offsite) team vs. managing them on a standalone basis?
  • The “Impossible Triangle” of Quality, Flexibility (Availability), and Cost – Tradeoff vs. Optimal:
    Trying to optimize all three dimensions (quality/flexibility/cost – or for project-based work: scope/schedule/cost), how would you prioritize them in order to further drive profitable growth? Furthermore, how important is the “4th” dimension (control)? Does the (relative) importance of control (project management / outcomes ownership) influence your structuring of offshoring engagements: staff augmentation vs. project outsourcing, Time & Materials (T&M) vs. Fixed-Price Contracts?
  • Today vs. Tomorrow:
    Is the impending shortfall in workers and skills (“Talent Shortage/War For Talent”) due to demographics / macroeconomics already impacting your firm? Or, impacting your future resource planning? And, given how technology and globalization are re-shaping both the workplace and the workforce, are you looking at alternate strategies for sourcing and deploying talent (globally, virtually)?

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.