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.

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?”)

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

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.