The rumors are true: I have returned back to the US after a two year stint as Managing Director of RippleRock India. Now that my assignment is completed  (“build an India subsidiary”), I have been relocating myself and the family back to the States over the last few months. What was it like, you ask?

Highs

What an incredible journey! Over the last two years, I have trained and coached software teams in India, Malaysia, and China. Not only did I get an excellent exposure to different work cultures, but I met a compelling array of people, too many to mention by name. By virtue of being an expatriate, I was exposed to a full contingent of internationals. Here’s one story: The church I attended featured a number of African students, studying in Bangalore. One Sunday, I met a Ugandan and asked about the difficult history of Uganda and India, to which he replied, “Yes, lots of history, but I like to think of the future”. A few days later, I learn the US government is warning citizens not to travel to Uganda because of anti-American sentiment there. So I was one of the few Americans in the world who had the gift of hearing this African millennial’s positive perspective on the 21st century.

Lows

I’m proud of what we created at RippleRock India, but it took work. I joke with people that I must be glutton for punishment, given that I took a job that offered both the challenges of working abroad (culture shock, home sickness, language barrier) and a startup (legal, accounting, business development). As you can imagine, I learned a LOT of things all at the same time: (1) doing Agile consulting and training (2) as a foreigner (3) in the developing world (3) starting up an (4) international (5) subsidiary. One friend of mine offered the insight that I gained amount to a real world MBA, only with the bouns of a little more white hair.

Now What?

With the firm fully instantiated, I have handed RippleRock India over to the capable hands of Hiren Doshi. The founder of his own firm, PracticeAgile, Hiren is one of the strongest agile practitioners in India, and his team has generated some amazing results for clients across South Asia. With regards to our offerings, my absence means we won’t be offering Certified ScrumMaster courses nearly as often; however, we have established RippleRock as the premier best-in-class provider of PMI-ACP training.

For myself, I’m a little winded from all the travel and will be focusing my work on my home town of Washington DC for the foreseeable future. To make that happen, I will now be working with my old alma mater, Excella Consulting. My first Washington DC Agile training with Excella will be May 31st – June 1st, and to celebrate I’m offering major discounts to anyone who contacts me personally: email {at} jessefewell {dot} com.

Many of people are familiar with the acronym WYSIWYG = What you see is what you get. It’s a great pneumonic device that describes the expectations people have, versus the product they get. As it turns out, there are a few other great acronyms that describe human behavior patterns in the world of software.

WILIWIK (pronounced “willy-wick”) = “What I like is what I know”. In a technology context, this could mean “I am going to use Java to build this widget. Java is the best. Granted, Java is all I know, but I am fully convinced it is the best, because I don’t like to try new things”. In a business context, this would refer to any general resistance to change: “We’ve always issued a cover sheet for the TPS reports. That’s the best way to do it. Implementing a new policy of optional cover sheets will never work in this company. I like the way I do my job, because it’s the way I’ve always done my job.”

IKIWISI  (pronounced “icky-wissy”) = “I’ll know it when I see it”. This refers to the human pattern of wanting something, but having a hard time pinning down the specifics. “I know I want a website that makes me look cool. I’m not quite sure what that means, but I’ll know it when I see it. So…when could you have that built for me?”

YAGNI  (pronounced “yag-nee”) = “You aren’t going to need it”. This is a response to the human tendency to want to support every possible scenario that might potentially happen. “We need to build that laptop out of rubber, in case it gets hit by lightning.” It sounds like a good idea during the due diligence phase of a project, but really, how often are you going to be typing feverishly outdoors, in the open rain, in a thunderstorm?

GEFN (prounounced, “gefen”) = “Good enough for now”. Similar to the previous phrase, this comment reminds us that we don’t need to build a Cadillac every time. “Yes, I know you want our toy website to have a video over happy children playing with the toy…for each and every product we sell. But the CEO thinks having only 1 video on the home page is good enough to start selling toys, not that Christmas is only a few weeks away.”

WIIFM  (pronounced “wif-im”) = “What’s in it for me.” This is a sort of snide articulation of the need to make the business case for any idea you suggest. Technologists fall in love with their ideas, but often fail to explain why it makes good business sense. “Yes, I know you *want* to rebuild the entire Facebook website using Java (because we’ve already established that it’s the best), but you need to help Zuckerberg understand “What’s in it for me”.

WGLL  (pronounced “wiggle”) = “What good looks like”. When a team starts a new project from scratch there are a lot of unknowns. What does a good team dynamic look like for us? What does a stable infrastructure look like for us? What does a good product look like for us? When you get a little daunted by all the unknowns, it can be comforting if the team reminds itself that we are still “wiggling” towards goodness.

WDLL (pronounced ”widdle”) = “What Done Looks Like”. This is from Liza’s comment below. If you ask a team of 7 people whether a feature is “done”, you’ll get at least 7 different answers. Does that include testing? Does that include the Spanish language version? Does that include the data backup? Does that include rolling it out to the integration environment? Sometimes, to clarify the difference of interpretation, you have to hold up a specific example and say “this feature is what-done-looks-lie”.

This week marked the latest annual Agile in Defense conference, in the outskirts of Washington DC. There were about 100 attendees, and strong support form the agile community. As with any conference, the real value was the conversations that happen between the talks, but the talks themselves are also worth mentioning…

Warnings From the Past
I showed up a little, but just in time for Dr. Robert Charette’s talk. He gave a hard warning about the pitfalls of NASA’s Faster, Better, Cheaper program in the 1990′s might be repeated once more in the Defense community. Specifically, the program met with some initial triumphs such as the Mars Pathfinder project. But the continued pressure for “cheaper” began to create a culture of compromise, which some say led to the Challenger disaster. The response was to swing the pendulum all the way back to the extreme opposite end: never ending budgets. He warned us that mentality could bankrupt the military.

Agile EVM for Defense
Scrum expert Brent Barton then gave a tutorial on how to calculate Earned Value Management (EVM) in an Agile environment. Easily the most practical talk of the day, it was based on his original white paper, which you can download here.

The Agile Virus Spreads
Ronald Pontius, the Director of C2 Policy for the DOD CIO, gave an update on specific agile initiatives in the DOD. First, the Section 804 of NDAA 2010 and Section of 933 of NDAA 2011 are formally closed. The Office of the Secretary of Defense (OSD) completed its report for developing a strategy for rapid acquisition. That report included a proposed a modification of the DOD 5000 acquisition standard to be more iterative. But that was just the beginning. Not only did he cite 9 active programs seeking to be more agile (e.g. streamlining for “integrated test” initiative at Department of Test and Evaluation, but he gave a few pointed assertions:

• “The latest acquisition guidelines are encouraging concept of “time certain” delivery” (aka “timebox” in Agile speak)
• You can’t execute in smaller chunks if the requirements guys aren’t on board”
• “The CIO of DOD, Ms. Takai, is absoletly embracing agile”
• “Agile is consistent with Under Secretary Ashton Carter’s “Better Buying Power” defense memo“
• “All the C4SI senior project officers “get it”. The problem is at the middle management level.”

It was an encouraging list of the seeds of positive cultural reform.

Agile By the Numbers
The most enthusiastic talk of the day came from Dr. David Rico’s talk featuring some shocking statistics.

• Large systems are risky. When systems approach 400 millions lines of code, bad things happen
• The average productivity for a DOD system is under 1 line of code per hour
• Of the world’s $1.7 trillion in IT expenditure, $858 billion is lost
• Today 60-70% of DOD projects are using #Agile methods, including the F-35 and F-22 (My guess is all those projects may have at least one agile teams, but very few full program-wide implementations of Agile/Lean methods)

Well it turns out the “controversy” about AgileExams turned out to be the biggest of misunderstandings.

The Testimonials Were Authentic: Several of AgileExams customers contacted me and revealed the root cause of this confusion is the fussiness of PMI.org’s online certification registry:

• The name on the testimonial may not be the same format as the name in the registry (e.g. Joel Bancroft-Conners explains you can find his name by searching ‘Bancroft’, but not ‘Conners’)
• There are occasional delays from passing when a candidate passes the exam, until they are listed in the system.
• Most of all, candidates may choose not to be listed in the registry (which beguiles me, since the whole point of a certification is to assert to people that you’ve accomplished a structured learning program)

However, there are some bitter hard feelings left over. Joel posts an excellent analysis of the situation: The issue is not the issue. Apparently Yes, the testimonials may be authentic, but that didn’t stop the controversy from happening. In any crisis management situation,  (e.g. Joel cites The Toyota Prius), the response to the crisis often matters more than the core problem.

Privacy is not an effective crisis management response for public issues: In response to the issue, the owner of AgileExams has asserted his privacy by removing his LinkedIn profile from the internet, and personally asking me to refrain from using his name, which I have done. Yes, he has the right to his privacy, but only if he choses to remain in the private. Once you go out into the public with a product, you offer some of your privacy in exchange. Some examples from last night’s Republican debate show the point. Newt Gingrich blasted the press for highlighting the personal nature of his marriage. He made the point that some things are personal, and not related to public life. But then Newt promptly forgot his got high-and-mighty position when he questioned Mitt Romney about not releasing his tax returns. It turns out if you run for public office, you lose some of that right to privacy. Likewise, if you release a product online, then you have to expect the public scrutiny of 2 billion internet users.

Personally, I’m glad the service was exonerated. It further validates the efforts of the 515 project managers who earned the certification. Also, I believe the service made a substantive contribution to the community. So, for what it’s worth, I’m sorry that AgileExams had the misfortune to endure this controversy, but alas sometimes it is the price one has to pay to be successful.

Today, the Agile journalistic blog AgileScout.com posted a discovery that testimonials for the PMI-ACP exam prep service, AgileExams.com, may be engaging in some false advertising.

Controversy 1: Several of the testimonials come from people NOT listed as PMI-ACP certificants. PMI offers a public registry on its website, which allows employers to verify whether someone has the PMI certification they claim to have. Curiously, several of the customers quoted on AgileExams.com are NOT listed as certification holders. For example, the site quotes Jonathan Daly saying “…your site made the real exam a breeze”, but Daly is not listed in the PMI-ACP registry. Granted, PMI offers certificants the option of NOT being listed in the registry, for privacy reasons. But granting permission to be quoted, and then not granting PMI to list you in the registry seems odd.

Controversy 2: The advertised customer success rate is a bit naive. The post also reveals that AgileExams.com asserts that of their customers who actually took the the PMI-ACP exam, a full 97% passed. Unfortunately, PMI provides no way to tabulate failing candidates. Instead, AgileExams.com offered an open call for its customer to self-report whether they passed or failed. Not surprisingly, only 3% of his survey respondents admitted to failing the exam. As a trainer myself, I have received 0% of my own customers saying they failed the exam. Yet, I’m not naive enough to assume that nobody failed. I can only know for sure that nobody is willing to admit to their trainer that they failed.

Controversy 3: The site offers little in the way of Agile reputation . The site owner, [name omitted], is a relative unknown in the agile space, and some skeptics want some information as to who is involved in the product’s creation, and how it was put together. However, other people have commented directly on the blog post that they care less about this, and more data about the product’s effectiveness.

Summary: In the end, what looks like a juicy controversy may just be some circumstantial misunderstandings. Here’s how AgileExams.com can clear all this up:

• Update the website with testimonials from candidates who are listed in the PMI-ACP registry.
• Update the website to focus on the LinkedIn testimonials: http://www.agileexams.com/linkedin-group-testimonials/
• The site owner can post an open letter on his website explaining who worked on the product (including the associated AgileBOK.org), whether they bring any agile expertise to bear, and the methodology they use for building the site.

In my opinion, some simple website edits can quell this controversy, and also build the product’s reputation at the same time.

What about you? What do you think of the website’s product, and the claims it makes about the product?

Shortly after my last post, my website got hacked. At first, it seemed like a minor glitch: Visitors clicking from google would be redirected to a harmless directory site. However, I was rather occupied with significant business travel, while also relocating my family. I simply didn’t have the time to investigate it. Well, it snowballed into a full-blown crisis, and I re-learned some old management lessons along the way:

Lesson 1: Root Cause Analysis. I consult and train and advice people on the “5 whys” technique, but this time it got personal. Here’s why:

The hackers likely got in through an outdated plugin, BECAUSE the plugins were not updated to the latest versions,

BECAUSE my technophile webhost (Dreamhost.com) does not auto-update the latest versions of WordPress blogging software I use,

BECAUSE my technophile webhost is designed for people who are sufficiently on their technical game to do those update themselves, which did not happen,

BECAUSE I did not do those updates,

BECAUSE I am lame.

When YOU are the root cause of operational or project failure, it can be very personal.

Lesson 2: Always have a backup plan. As I was cleaning out all the corrupted files, I inadvertently deleted all my blog photos. Fortunately, Dreamhost has a restore feature that allowed me to recover those files. THEN, when I moved my blog to WordPress, the change in DNS entries caused my emails to get lost. Fortunately, I had alternate emails that people could use to contact me…and…fortunately, those emails were setup for most of my online services. But in reality, my good fortune was made possible by a little backup planning. I chose my webhost based on its multi-restore features, and I chose my emails to be redundant in case I lost access to them.

Lesson 3: Adapt to the changing reality.  I’ve been a customer of Dreamhost.com forever, but it’s time for me to move on. If I am the root cause of this failure, then I need to resolve the risk of causing this same thing from happening again. Dreamhost is a web host designed for technical people who know how to “ssh into a bash shell and grep for which files contain strange commands”. That used to be me 10 years ago, but not anymore. As a father of three, business coach, and entrepreneur, I’m not longer the geek-o-phile I used to be. So, I’ve moved my blog over to wordpress.com, where it’s a little bit more automated and idiot-proof.

In the end, management theory only matters when it has impact on the real world. This time around, I have been taking my own medicine. QUESTION: how about you? When have you had to take your own management or leadership advice?

A full four weeks ago, I saw Malcolm Gladwell keynote the PMI Global Congress in Dallas. Here was his opening point:

The paradox of innovative organizations is that they are followers and borrowers, not leaders and innovators

Malcolm Gladwell offers provocative observations on innovation

He followed that point with an avalanche of examples:

• During Bekaa air battle in 1982 (http://bit.ly/nee2Aa), Israel was the first to use drones, awax radar, and SAM missiles at the same time. These were technologies pioneered by the highly funded, innovation-oriented Soviets; then developed by the Americans with budget oversight and “get the job done” culture; finally utilized by a crisis-motivated Israel with no R&D budget at all. He found this example in the military innovation book by Adamsky
• The mouse and the Graphical User Interface (GUI) were developed at the storied Xeroc Parc project in Palo Alto. Steve Jobs famously took that GUI and did what Xerox could not do: launch a commercial product with the technology (i.e. the Mac). It was a beautiful product and business success. But it was Microsoft who modified the technology into Windows, the most commercially successful operating system of all time.
• Friendster is the one that lays claim to the first pure-play social media pioneer. MySpace matured Friendster’s breakthrough idea, and sold out to News Corp for a half-billion dollars. Now we all talk about Facebook as the king of social media and its multi-billion dollar valuation.

Here is the myth-breaker: being first to market with a fresh new idea, does NOT correlate to success.

Zen-PM takes a snapshot of Malcolm Gladwell's innovation talk at PMI Global Congress

The pattern is that innovation is carried out by three successive parties:

• First, The Inventors, who typify the innovative culture with big investments, and pioneer a new product, technology, or service.
• Then, The Implementors, who have less to invest, and focus on how to operationalize, productize, and monetize that invention.
• Finally, The Tweakers, who have very little resources, and make minor adjustments that transform the invention into a revolution.

Google is a company founded by tweakers of Lycos & Alta Vista. Sony ebooks were first, but Amazon dominates because they had the chance to see the impact of e-readers and then make adjustments. Finally, the iPad came along and introduce a tweaked tablet PC as a new challenge in the ebook space.

“Steve Jobs was always follower and borrower” The resurgence of Apple over the last 10 years, is based on his ability to tweak the PC, tweak the portable music player, tweak the blackberry, tweak the tablet PC, and now tweak the cloud.

…and if that wasn’t enough, he pressed further:

“Innovation at its best is a mass phenomenon, not an elite phenomenon.”

Gladwell’s asserts that the industrial revolution happened, because the West had an historical boom of dabblers and tweakers. James Watt was an implementor, only doubling steam efficiency; the anonymous tweakers increased it by another 500 times. Alexander Graham Bell’s voice-over-wire was only one of many contemporary tweaks of the telegraph’s signal-over-wire. Think of wikipedia. Think of crowd sourcing. Think of the old fashioned “suggestion box”.

It was a fascinating talk, and of course, wildly entertaining. Gladwell is a great story teller; memorizing an outline of his talk, offering just enough detail along the way, and adding energy throughout. Even his crazy hair helps amplify his enthusiasm.

But the talk would serve as the first in a personal series of innovation a-has. I’ll post those other reinforcing moments shortly. Until then, I leave you with this final quote and question: “Nimble adaptive organizations are mutually exclusive of innovative organizations.” Put another way, which kind of company do you work for? I’d like to hear if you think you are an ivory tower organization, or one that ruthlessly applies what already works?

I’m excited to announce that I’m writing a book to help agile practitioners earn the new PMI-ACP agile certification. 4 years ago, I started by helping PMI launch the Agile Community of Practice. Then 2 years ago, I worked with some great experts on building the certification program. Now, this book is the next step in my journey to encourage project leaders to grow in their understanding of Agile project management.

Also, this book will benefit from a lot of talent. I’m writing the book with my good friend Hiren Doshi. We’ve engaged visual communication experts Take-Action.com to illustrate the book, and have brought on some good editors.

Our target is to complete the book by the start of 2012, but anyone who’s written a book knows there are challenges to that. For example, people are beginning to post their initial feedback on the exam, which may cause a lot of last minute changes to what information is most helpful.

Also, You can go to the official website and download a free sample chapter to see what we’re trying to achieve.

So here is my question: What would you like to see in a PMI-ACP exam book?

I started working in India full-time in August of 2010. As an American, I had a suitcase full of expectations and assumptions. After a year of working with Indian IT professionals side-by-side, it’s time for a few reflections and observations.

Scrum in India is HOT. Some 18 Months ago, there was only one reliable vendor offering Certified ScrumMaster (CSM) training in all of South Asia (Pete Deemer of GoodAgile.com), and he was based in Singapore. Now, there are three Certified Scrum Trainers based in Bangalore (Pete, myself, and Vibhu Srinavasan of Solutions IQ), and a Certified Scrum Coach in Hyderabad (Madhur Kathuria). Added to that mix is a spike in agile events, such as the quarterly Scrum Bangalore, the mulit-city Agile Tour, and the upcoming Agile India 2011.

India’s Talent is a Strength. There is an obsession in this country with education. Driving from my home to the airport, I see two to three DOZEN billboard adds for bachelors and masters programs. The kids that score highest on standardized scholastic exams are featured in front-page newspaper articles. It then extends into the professional world. An amazing 2010 book called The India Way highlights the dramatic difference between American and India with regards to talent. In America, companies find talent, but Indian companies develop talent. When I joined large companies like Bell Atlantic or Lockheed Martin as a young engineer, my orientation took 2-3 days. Here in India a new hire can spend up to 6 weeks in skills development training. But it doesn’t end there. Most large firms have a “learning & development” organization that hosts dozens of training programs at a time, which employees are required to take as part of their annual appraisal process. What that means is engineers in India are hungry. They are eager to learn and try new things if you let them. By far and away, Indian teams leave my agile training even more energized and motivated than their US counterparts.

Infosys boasts the world's largest employee training center

India’s Talent is an Impediment. All that positive energy around engineering talent comes to screeching halt after a few years of professional experience. Over the last 30 years or so, the West has fostered the concept of the technical career track. For example, at Marriott headquarters in Washington DC, I met a really smart yet simple man who retired in 2009 as a life-long Cobol programmer with a happy family. In India however, that would be considered a wasted life. If you are still programming after 5 years of experience then something is wrong with you. You should have been promoted to the higher-paying and higher-prestigious management role, where you could then provide a better life for your children. I had one test manager tell me to my face, “Taking the role of an agile team leader is a demotion, and my career won’t be able to survive that.” Yes, there is talk of a technical career track in India, but it usually means getting promoted as an architect or a professor who has long since stopped programming and now tells other engineers what to do. Also, all that free technical training is a set of golden handcuffs. As a provider of IT certification training, I hear many questions along the lines of “Why should I invest in my own career advancement, when every company I’m interviewing is promising me similar training at no personal cost?” This all adds up to a dramatic gap between mid-level engineers and strong senior engineers like Robert Martin describes as the crux of software craftsmanship. Those engineers do exist, but you should expect that your Indian agile teams consist of many motivated, but relatively junior engineers.

Global IT infrastructure is an impediment. Without a doubt the largest shock I have experienced is the atrocious support that multi-national software teams receive from IT infrastructure departments.

• Some of it is simply multi-national business. The parent company in the West has its network domain, and the subsidiary in India has its network domain. Because they are two different companies, the workstations and servers often are not directly accessible to each other without jumping through VPNs, firewalls, and removing servers.
• Some of it is cost pressure. One of my clients does not even issue proper workstations to its engineers, but instead has them remote into Virtual Development Instances. Shared virtual development workstations will save a few thousand dollars on hardware costs, but it yields competition for system resources, and more network latency on my coding and testing.
• Some of it is just mean. Another client of mine is doing iOS development, but the IT department only supports Windows PCs on the network. One would think simply to do a manual sync of the source code to their macs, using a USB pen drive. BUT, the USB ports on their company-issued PCs are disabled “for security reasons”. I won’t say the hack these guys used to get their work done, but let me tell you it would make any sysadmin shiver in his bones.

Regardless of the reasons, it all adds up to wasted productivity. I estimate that Network latency + system resource latency + manually doing what a computer should do = 30-40% loss of engineering productivity. I blame the Fortune 500 CIO for this. His executive mandate is to cut costs, without regard to the ten times great loss of productivity and employee satisfaction. This means if you are dealing with distributed teams, expect IT infrastructure to be your number one issue. Worse than the time zone. Worse than the culture differences.

Everyone is doing it. Another misperception in the west is that only a small syndicate of evil CIOs have shipped jobs overseas. Here in Bangalore, a casual drive down along outer-ring road road will reveal the following firms: IBM, Perot Systems, CapGemini, Tesco, SAP, GE Healthcare, Oracle, Cisco, Intel, Accenture, and Dell. And that’s just eastern Bangalore. Other cities in India feature firms ranging from John Deere (Pune) to Microsoft (Hyderabad). After trading stories with my colleagues, I have learned that a surprising plurality of Agile coaches have made at least one visit to India in their career.

Even India is doing it. One American colleague asked me over dinner, “Jesse how do you respond to the challenge that, as a business agility coach in India, you are an accomplice to India’s sucking technology jobs away from America?” I was stumped by the question at the time, but the more I see of global IT, the more complicated the picture has become. For example, all the top Indian outsourcers have a significant footprint in the US (Wipro has 14 offices across the US), and one of them is even headquartered in the New Jersey (Cognizant). The biggest shock came way back in 2004 when India’s largest Telecom, Bharti Airtel, “reverse outsourced” its IT to IBM for $700 million. But now, it’s getting even more complicated: Last year, Airtel hired the New York based IT giant again, this time to support the Telecom’s expansion into 16 African countries. During the 2012 election season, we will hear a lot of politicians calling for a ban on outsourcing. But doing so may actually have a domino effect on current jobs in their own districts.

I’ve got other observations lingering around in my brain, but these are the first I wanted to share. What about you? What differences have you seen between the Western and Eastern approach to IT work?

People often ask me whether Agile PM is a good fit for their project. In general, I tell them that delivering more value to your sponsors, sooner, with higher quality is always a good thing. However, pursuing those goals is not devoid of risk. I warn people about three key pitfalls when choosing to “go agile”.

Overhead
Agile PM is not for free. Many project managers assume that agile means no planning and no documentation. Imagine their shock when they find that a standard agile framework employs no less that 4 levels of planning (daily, iteration, release, project) and a full suite of artifacts called backlogs (product, iteration, impediment, risk). Complex projects need a certain amount of coordination to be successful, and an Agile approach is one that merely seeks the right balance of the right amount of process to manage those projects. However, if your project is instead a small, simple, low-risk affair, then the overhead may not be worth it. A certain investment of time and resources are required to implement the discipline and rigor that Agile frameworks require. Before you go Agile, be sure your project is sufficiently risky and complex to merit that investment.

Truth
Agile project management is not a silver bullet; it is a magic mirror. It does not fix your problems, but rather reveals your problems in such painful clarity that you are compelled to actually address them. When the complexities of a 1-year project are compressed down to a 1-month increment, there is no longer anywhere to hide. For example, if you have a talent problem, iteration deadlines will be missed consistently until you build more skills. If have a negative team culture, forcing people to work together across silos will cause more pain until you attack team dynamics directly. If you have a track record of generating defects, you will have more embarrassing customer demos until you implement tighter quality practices. Beware. When so many problems come to the surface, the PM will often get the blame for introducing this Agile craziness. Agile PM is designed to help project managers tell the truth with empirical data. As it turns out, people are often not able to handle the truth, and will instead shoot the messenger. Before you go Agile, be sure you are prepared to handle the truth when it is revealed.

Change
Those familiar with the WYSIWYG acronym (“what you see is what you get”) will enjoy another. WILIWIK: “What I like is what I know”. Many people around us simply don’t want change. The pain of the known seems safer than the risk of the unknown. Methodology expert Alistair Cockburn has identified this as a human failure mode in project management. Anxiety will grip project managers when they learn the chosen agile frameworks does not explicitly highlight the project manager role. Annoyance will come from isolated ivory tower engineers who must now attend meetings with those pesky sponsors who pay our salaries. Protests will arise from requirements analysts who must now prepare feature specifications every month, rather than only once per year. Change is hard. Before you go Agile, be sure you understand the dynamics of the changes you are about to introduce.

Agile is not for everyone. Its overhead is best saved for high-risk complex projects; its truth-telling requires courage; it’s differences demand a disciplined approach to change. Understanding these pitfalls can make the difference between Agile failure or Agile success.