This week featured the latest gathering of Scrum prapractitioners in Bangalore. This free event drew a solid 50 participants for the second straight time, and featured some really smart technology workers. The group was about 50% developers, 25% testers, and 25% managers. I did get to do my standard presentation on Agile Contracts, but the broader theme for the day was “Scaling Scrum”. This was of great interest to me, since RippleRock is helping a large dotcom implement Scrum across two strategic pilot programs using 4 teams on 2 continents. Needless to say, I took copious notes below

Scaling Scrum

First off was Vibhu Srinivasa from Solutions IQ. People laughed out loud as he facilitated a team dynamics game. But what people came to hear were his points about using Agile techniques on really large projects:

• Understand Why You’re Scaling – The point is not merely to have an official standard for managing work. The point is to create alignment across larger projects, to make sure people are on the same page about delivering on a business objective.
• Understand What Scale Means – To help bring alignment to our own large group Vibhu offered this definition of large-scale agile projects: “A group of teams working together on a common product or project or portfolio”.
• Well groomed backlog is required to scale Scrum. For a single team of 7 people, a poorly formed backlog will only impact that team. On a larger project of a dozen teams working on the same poor backlog of project work, then you’ve just scaled the associated pain and errors.
• There are several ways to nest Scrum teams. In general you can have nested backlogs of increasing degrees of detail, but there needs to be a clear, singular owner of each product backlog.
• Charter a Product Owner team, responsible to keep the backlog groomed and prioritized. In larger organizations, the Product Owner role can quickly get to be too much work for one person. Have relevant stakeholders meet as required, above and beyond any other meetings with the Scrum team.
• Align the sprint schedules. Namely, it helps if everyone is working to the same deadline.
• Use the Scrum-of-Scrums only to coordinate dependencies. The overhead associated with the Scrum-of-Scrums is best utilized less as a status meeting, and more of an impediment removal meeting.
• Relentless Automation – Just scaling scrum management is not enough. You need continuous integration, low-cost regression testing, and  ”touch free” deployment.
• Rotate ScrumMasters – Spreads skill and awareness of Scrum and alleviates anxieties about career path.
• Ambassador Pattern – Fly people to their distributed counterparts for key meetings or even for an entire sprint . This help preserve team dynamic,  when individuals return to their home base.

Globally Distributed Agile Teams

Then, Rini van Solingen. the CTO of iSense Prowareness, joined the group over skype. He started off with describing the “30 meters principle”: When teams are distributed more than 30 meters apart, the communication frequency drops to near zero. So, it doesn’t matter if your 3 time zones away or 3 miles away, the real limit is 30 meters.

This is a bit of an obsession for Rini, who is working a research project at TUDelft called “Creating the virtual 30 meters”. In this research, he has found some best practices:

1. If a single roof is possible, do it! Don’t distribute if it’s not absolutely necessary.
2. First, deploy Scrum locally and effectively before working distributed.
3. Assign Scrum roles explicitly. The Product Owner and proxy roles becomes even more critical.
4. One team in one rhythm. Staff your regional teams with people from all other locations. This is the “ambassador pattern” described above.
5. Meet. Teams are not built by themselves. You need to actively establish relationships by traveling to each other’s sites.
6. Impediment removal and retrospectives are even more crucial. In fact, meet collectively for retrospectives (see previous item).
7. Work at the customer location at least between 10-20% of the time.
8. Personal mindset is crucial: “what did *I* do wrong? what can *I* do different? how can *I* help?”.
9. Don’t focus on tools: discussion and interaction are more important.
10. However, communication and awareness don’t happen automatically. Here, tools can help, but only if implemented with the right purpose in mind.
11. Fail fast: improve empirically. Both success and failures are sources for learning.

Open Conversations

The day wrapped up with an open space session. A number of topics were suggested, but the top two were two key topics:

• Estimation: In this conversation, there was a lot of discussion about the expectations around estimates. Managers expect your estimates to be internally consistent, when in reality they aren’t. They also expect your actuals to match those estimates exactly, but in reality they were really just estimates. One suggestion was to begin using the word “forecast” instead of “estimate”. Doing so may emphasize the fact that the numbers are rigorous, but not iron clad.
• Careers. Here, there was concern about the impact Agile roles and responsibilities have on your career. For example, if a developer takes the risk of helping lower-paid testers learn code-based automation, will that make him less needed? If a BA takes the risk of not writing all the details for all the requirements up front, how will her skill be judged? If we take the risk to move in the professional direction of Agile skills, is there a job market for those skills? The answers are not easy. If you work for bad managers, then they may punish you for doing the right thing. But then again, they’re probably already doing that. And really, the your career should not be based on a choice between Agile jobs or non-Agile jobs. Your career should be based on what makes you and your team most successful.

It was an eventful day. iSense does a really good job of organizing this. I look forward to the next one at the end of September.

This is a reprint of my column in this month’s PM Network magazine. Click here, and then search for “The Agile Project Manager”

I’m growing weary of project managers whining about bad requirements. The truth is, no one can possibly be surprised. From research studies to high-profile disasters, we hear over and over that incorrect requirements and poor scope management are key reasons projects fail. If we know this is a recurring problem in our profession, why do we mindlessly continue engaging in the rote repetition of what doesn’t work? I’d like to share some suggestions to keep us from stumbling over the same mistakes:

Surrender the pipe dream of complete requirements.
There’s always going to be one dependency missed, one stakeholder we didn’t interview, one nuance hidden, one more thing we wished we had known. Don’t fall into the trap that more is better or you’ll never get started.

Always assume the initial requirements are wrong.
Sometimes the scope is inappropriately slanted toward one stakeholder or hasn’t been properly vetted. Sometimes the bulk of the requirements are actually “nice-to-haves.” Today’s project manager is expected to have the organizational savvy and facilitation skills to get to the root of these problems. To ensure that you yield the right priorities at the right time, take the initial scope statement as a starting point, then work with the sponsor to refine it.

Accept that all requirements change.
Traditional project management culture portrays change as a necessary evil, like traffic laws: If drivers did everything right, we wouldn’t need them. To mitigate the “risk” of change, we install intimidating change-control boards and financial penalties. But what if the scope you’ve been implementing for the last two years is no longer relevant to the market? Does it make sense to have your sponsor continue paying for what is now
essentially a useless deliverable? Not in my estimation. If we accept that our requirements are incomplete and incorrect, then we need to edit them to reflect reality. Indeed, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) warns: “Because of the potential for change, the project management plan is iterative and goes through progressive elaboration throughout the project’s life cycle.”

Simplify your change-management approach.
Agile project managers explicitly embrace the value of responding to change and institute project policies accordingly. Start by implementing a contract structure that supports authorized change rather than penalizes it. At the start of each iteration, mandate a high-level yet thorough revision of scope priorities. If your sponsor has difficulty determining priorities, coach him or her through the tradeoffs. Once changes are accepted, re-baseline earned value metrics at least every three to four iterations to match the latest scope. And while you’re at it, proactively communicate the latest scope to all stakeholders.

If you consistently find your requirements getting you into trouble, do something about it. It’s your responsibility as the project manager to be adaptable to your sponsor’s needs. Stop taking the requirements for granted and start equipping your sponsor to make the right scope choices.

As a project manager, a member of the PMI, and an Agile Project Management practitioner, I get yelled at a lot. PMP-certified project managers call me irresponsible for advocating the Agile approach to projects, and Agile practitioners call me a turncoat for collaborating with members of the PMI. It’s understandable that people who are used to one way of doing work are skeptical of another way of doing work. I get it. But does get tiresome. Last year, a fellow Scrum trainer called me a placator, akin to Neville Chamberlain, and it was not meant in a lighthearted manner. However, I am not the only recipient of that kind of vitriol. The Agile PM community is riddled with factions and in-fighting. In the pursuit of truth, many of our so-called thought leaders have taken rather inflexible positions of “No matter what you say, I’m right and you’re wrong.”

Well, today I’m in a collaboration session today with technology management thought leader Alistair Cockburn. In our chat today, he introduced me to his latest initiative, The Oath of Non-Allegiance. It is a web page that challenges Agile practitioners to formally sign and ratify the following:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

Finally! Someone has taken a stand to hold these Agile thought leaders accountable to the core value of “Collaboration” they all advocate. As a co-founder of the Agile Project Management movement, Alistair has been dragged into many of these philosophical feuds. I’ve always appreciated him for advocating the Scrum alongside his own Crystal methods. It’s a strong statement to say your thing is good, and this other thing is also as good, and you’re willing to teach them both.

QUESTION: What do you think of these Agile factions? Do you think this Oath will help the issue?

This past Sunday, May 31, 2010 saw the kickoff event for the Scrum Bangalore user group (photos available here). It was a 6-hour mini-conference that featured 2 speakers, and open-space, networking, and several prizes. Also in attendance were the Agile Bangalore user group, an online community led by Vinay Krishna.

Rahul Sah Kicks Off The Event

Scrum Bangalore is the product of Rahul Sah of the Dutch company iSense Prowareness. He started the event by setting a vision: there is a huge gap between the demand and the support for Scrum in Bangalore. He said that he was charged by Jeff Sutherland to start something, when it was observed that the most Google searches for “Scrum” originate in Bangalore, more than anywhere else in the world. Before this month, there were no formal user groups supporting the local Agile practitioner community in Bangalore; now there are two.

Pete Deemer Wows the Crowd.

The headliner was long-time South Asian Scrum trainer, Pete Deemer. He shared with us his 19 keys to successful agile adoption. It was a great talk with lots of energy and insights. At the end of the talk, he amazed the group with several giveaways, including a copy of Mike Cohn’s latest book for *everyone*. A very generous gesture indeed. 



The “Amriki Gaura” Gives it a Go

In the afternoon, I got up and introduced myself to the crowd, sharing my story of starting an Agile consultancy in India. I then facilitated a group discussion about how to overcome key challenges with Agile Adoption. We used the “12 Key Objections to Change” from the NY Times bestseller Switch (a great book I will discuss later). Both Pete and the group offered some excellent points:

• Change is like a rebirth
• Many agile teams are technically proficient, but behaviorally are still stuck
• Driving in Bangalore is the essence of a self-organized system
• Scrum is a paradox: we offer specific guidance on success, but must encourage the team to choose its own direction


Agile India Moves Forward.

Afterwards, I had some drinks with the new leadership team of the Agile Software Community of India (ASCI). We talked about the 2010 spike of activity in India around Agile projects, such as:

• Agile Coaches camp in Goa earlier this year
• Launching of 2 user groups in Bangalore
• Four (4) scrum trainers offering classes in India, instead of Pete Deemer being the only one
• The forthcoming announcement of the Scrum Day India event in August

It is an exciting time to be a part of this community. And I’m looking forward to an eventful remainder of 2010.

QUESTION: What other signs of increased interest & momentum around Agile engineering or Agile project management are you seeing in India ?

This past Sunday saw the kickoff of the Scrum Bangalore User Group in Bangalore, India (more on that later). At the meeting, Scrum expert Pete Deemer gave us these 19 nuggets of wisdom from his many years as an Agile coach for organizations across the world.

1. Do it for the right reasons: Like Harry Potter, when evil wizards use good magic for evil purposes, they get destroyed.
2. Start with teams that want to try it: It’s counter-intiutive, but don’t force a pilot effort onto resistors. Have the teams pick themselves. Then, set their expectations: “Are you sure you want to try it? It’s really dangerous. You can try it, but only for 1 sprint”.
3. Set realistic expectations for Scrum: Don’t go in saying, ”Scrum will save our disaster project”. Force a project restart & give the team 3-5 sprints of breathing room. That’s how long it takes to get to all cylinders/cruise control.
4. Call it a pilot program for as long as possible: People assume a pilot is messy, and nor will a pilot threaten their long term career.
5. Change is scary to many people: Humans aspire, in an unfriendly world, to protect ourselves with some stability and predictability. Introduce your changes gently: “Scrum may not be right for us, but we won’t know until we’v tried it. So let’s do it all-in, correctly, for 1 sprint. Did we see any benefit? If so, let’s do it one more sprint. It’s one way of working. It’s not the final way of working, but it might help us get a little bit better”
6. Patience is a virtue: - Start with 1 team and grow gradually from there. You don’t want 20 teams all struggling with the same issue we’ve yet to figure out.  Instead, it’s better to have one trailblazer fix that issue so others don’t have to.
7. Find the Scrum middle path: In some ways, my job is a purist advocating the dramatic change, speaking hard truth, but then encouraging teams to tailor the practices to their situation. Be careful though; many organizations respond to the pain of change by diluting the change.
8. Scrum is hard: it surfaces your nasty, accumulated junk. If you’re not prepared to deal with the issues that Scrum reveals, then it will be very hard to continue.
9. Get experienced help: Consultants are not afraid of getting sacked, nor do they have a departmental agenda.

10. Get high quality training: Often, adoption failures are associated with the initial training provided by someone who was told to read a book over the weekend. Better to send 1 person to really good training, than to send 20 people to bad training.
11. Your enemy is your friend: Spend the most time with the people that like Scrum the least. Put your chief resistors on the Scrum steering committee. If they’re not engaged, they’ll miss how it works, and feel marginalized.  Also, those resistors will help you understand the key roadblocks to successful adoption.
12. Be prepared to use Guerilla tactics: Namely, if management won’t solve your problems, sometimes you solve them yourself. One example: get your own screwdriver and change the cubicles over the weekend.
13. Find your guardian angels: You need senior managers who “get it”. When you need to bend a corporate rule or special budget funding, your guardian angel. Indeed, many executives are eager to try an Agile approach, because they’ve worked on so many project train wrecks over the years.
14. Make good information more accessible than bad information: There is a ton of bad information on the internet about what an Agile approach is or isn’t. Establish a steady flow of good information with email updates, brown-gab lunches, staff meeting talks.
15. Measure the results early and often: Publicize the good and the bad results. Have both business and technical metrics. Use surveys to measure both the customer’s satisfaction and the team’s satisfaction.
16. The urge to tinker is great: To illustrate the difference between tailoring and compromise, Pete described a game of “CricketBut”. We play Cricket, but instead of a pitch, we’ll use my living room. Instead of a wicket, we’ll use my dog. Instead of a ball, we’ll use a brick. Instead of a bat, we’ll use my head. After a few overs, you will have bloodshed, just like at the office.
17. Choose your tools carefully: Don’t ask “which tool should we use”, but ask “What problem are we trying to solve that makes us think we need some software tool?”
18. Don’t stop with just the members of the Scrum team: Scrum is an organization framework. Often a team can be successful on a localized level, but the organization is stuck in bad habits and the success is not fully realized. You as a team might be able to deliver results, but if it doesn’t get out to the end customer, who cares?
19. Scrum will always be messy: The Agile movement is fundamentally about people and what they do. If people aren’t perfect, then our projects will never be perfect either. You will always have conflict, mistakes, and challenges. Simply ask yourself, “is it better than it was last month”.

It was a lively talk, that yielded some good points. Pete has a witty energy about him that made the talk even more enjoyable.

QUESTION: what have you seen to be the keys to successful Agile projects?

Given that I’m in the midst of a major career transition, I’ve been reflecting back on the highs and lows of my years as an IT professional. It’s been a rewarding exercise, and I’d like to share some of it with you here in the next couple of posts. And what better way to start than with one of the worst days of my life.

The Blowup

In my first job out of college, I was a computer programmer on a large government project. After about a year or so on the job, a senior team member (let’s call her Terry) was promoted to manager. With that promotion, our relationship changed from senior-junior colleagues to superior-subordinate. What I didn’t realize was that she brought into her new role some initial impressions and expectations of me as a professional.

After one particularly bad month, she called me into her office, and started unloading. I can’t remember the exact words, but they went something like this…

Jesse, you really messed up that last software module. Because you weren’t able to figure out the solution, your team lead had to come in and finish it for you. Consider the impact of that, Jesse. Because he spent so many hours helping you, his own assignment was late also. Remember the last time this happened?

…um, no I don’t. When?

It was the file manager. Remember how much trouble you had with that? Don’t you realize there is a pattern going on here, Jesse? Now, I’m left wondering if I can give you anything substantive to work on, or if we’ll just end up having to send someone else bail you out of the next problem. In fact Jesse, I simply can’t believe you spent so long on the module without getting anywhere. I think you knew your team lead would be there to bail you out and so you didn’t try as hard as you could have.

…are you saying I messed up on purpose?

That’s what it looks like. I don’t know what to do with you, Jesse. But whatever your issue is, you need to fix it, FAST!

Step 1: Get expectations out in the open.

Yeah, it was that bad. But when I look back, the root cause of her blowup was simple human disappointment and frustration. From her perspective, I was the key issue. But the real problem was that I had no idea.. She was viewing my previous difficulties as a liability, and had put me on a secret probation. Instead, the two of us should have known way ahead of time what was expected of me.

• For managers, you need to be 100% positive your team members know what you expect of them. When you move into a new leadership position, you should have both private and group discussions about what people understand their roles to be, what the team expects of you, and what you expect of them. Obviously, Terry didn’t do that, so I was left to continue my current work style, setting me up to fail.
• For team members, just because you’re not a manager, that does not mean you’re not off the hook. Expectations are a two way street. Namely, if Terry didn’t initiate the expectations chat, then I should have. I learned this from the One Minute Manager books by Ken Blanchard. If you as a team member don’t know where you stand with your boss, supervisor, or manager, then it’s up to you to fix that problem. Ask for a meeting with your boss to ask “how can I best help the team? What skills do you want me to focus on?” If your boss doesn’t give you the for that conversation, then at least send her an email spelling out your own understanding of where things are (heck, email is formal written documentation, so if anything you’ve generated some positive input for your next performance appraisal).

Step 2: Vent first, then confront

Because of Terry’s delivery I couldn’t hear her message. Instead, I internalized it by posting this little self-pity manifesto on my cubicle wall:

• For managers, no matter how frustrated you are, don’t confront your team members in the head of the moment. Let’s say you are boiling with frustration over a team member, someone who gets you so enraged that you know you can’t control yourself right now. If that’s the case, then right now is not the best time to confront him. Instead, go to a peer or to your own manager, ask for permission to vent, and then vent. If there isn’t anyone good to vent to, then go vent in the bathroom mirror. But whatever you do, don’t go to your people, with full engines revving and unload on them. 
• For team members, this is NOT how you deal with an unreasonable boss. First, it tells her that yelling at me is okay. Second, I allowed the intensity of the message to drown out the critical feedback that could have made me better. Looking back across the years, I really wish I had done some venting myself. If I had confided in a co-worker to get some additional perspective, I could have gotten past the episode. But I didn’t do that. Instead, I let the emotions get the better of me, and I held a grudge. In fact, some 8 years later a very similar situation came up, and I did confront my manager about a tirade. This time, because I took the risk of first venting, then confronting we were able to get underneath some stuff, and build a much better working relationship.

“I’ve been meaning to talk to you about that”

At this moment, Terry was taking a risk. She’s in a rational state now and wants to follow up after the poor confrontation. And my epic response was

“Don’t worry about it. It’s an inside joke.”

Yes, I know. That was really wimpy. After my response, she smiled and left, and that was the end the conversation, and our working relationship. I soon started looking for a new job and turned in my notice a few weeks later.

• For managers, even if you or your manager exert the emotional discipline not to blow up, even if you take the risk of a rational confrontation, there is still the need for ongoing follow up. Terry did just that, but gave up when I made it hard for her. As a manager, you can’t take no for an answer. Yes, I wish I had responded better, but I also wish she said: “Well Jesse, regardless, I’d like to have coffee with you this afternoon to work through our last conversation. Meet me at Starbucks at 3pm”. This is what is expected of leaders; this is why you are chosen for the role of a manager. Because Terry didn’t go that extra mile, she lost me the opportunity to steer me into a productive team contributor.
• For team members, if your manager follows up with a peace offering, then it’s your obligation to accept it. Furthermore, if she never does follow up after yelling at you, then you need to initiate that. I held onto the grudge, and I lost the chance to grow through the experience.

So, when it comes to managers losing their cool. It’s a two-way street. Prevent it with open expectations. Control it by venting first. Resolve it with intentional and determined follow up.

QUESTION: Have you experienced similar conflicts? What worked or didn’t work for you?

Okay gang, some big news here: I’m teaming up with the gang at Ripple Rock to start an Agile consultancy in Bangalore, India.

The Dream
Many of you know that I married into a first-generation family from India. Well, shortly after we started having children, we started wondering out loud:

“What if we spent a couple years abroad, expose the kids to their grandparent’s heritage, maybe help them pick up the language? What if we then come back to the U.S. in time for the oldest to start high-school, and he’s already set up as a global citizen?”

After 10 years of marriage and 3 kids, we finally made it to India…and we fell in love. Since then, we started getting gradually more intentional about making it happen. We did some research and some praying, and came down to this: we need a stable pipeline of work in India before we can make the move.

The Deal
Earlier this year, I was networking with other Agile Project Management people at the 2010 Scrum Gathering in Orlando. While there, I met Colin Bird and Tom Reinsel from Ripple Rock. We discovered we both knew similar people, so I shared with them the dream. Colin looked at me with a stunned expression:

“Really? I have a client that needs boots on the ground in Bangalore ASAP. If you’re serious, then let’s talk.”

We started talking and came to the conviction that this made sense on so many levels: We had a client need, a corporate vision, and a collective family dream that all pointed to India. As a result, we decided that I would begin building a fully operational Ripple Rock office in Bangalore, offering two key services:

• Offshore Software Process Improvement: If you’re a large Global 100 that moved your IT operations offshore, and it’s not going as smoothly as you want, send me an email.
• Agile coaching, training, and certification for professionals across South Asia: If you are a South Asian professional in the technology field, and you’ve of Agile Engineering or Agile Project Management, but have not yet been able to get access to good resources, send me an email.

The official press release was posted minutes ago: “RippleRock recruits PMI Agile Community Founder to launch India Practice”

The Transition

On one hand, this is obviously very exciting. On the other hand, it means a bittersweet departure from Excella Consulting, and the team of a very talented group Agile practitioners there. I’ve been at Excella for 4 years, and have grown immeasurably as a direct result of their corporate culture. If there’s one company in Washington DC that exhibits the virtues of Dan Pink’s “autonomy, mastery, purpose”, it’s Excella. I love the people there, and I’m going to miss them tremendously.

Also, I’m going to miss DC. Seema and I have built incredibly strong friendships here in Washington DC over the last 15 years. We plan to live abroad for only a few years, but going so long without those friendships will be tough.

Still, some things will remain the same. I will be as active in the PMI Agile Community as ever, if not more so. I will also continue to promote Agile Project Management at conferences across the world. But I’ll be doing it from a completely different locale, which means new faces and new challenges.

It’s an exiting time, and I’ll be posting updates here early and often. I’m eager for you to join me in this new adventure…

Question: How many of you are based in Bangalore or familiar with commuting to India? What advice or tips to do you have.

This coming Tuesday night, April 27th, I’ll be presenting at the Illinois Regional Agile Users Group in Bloomington, Illinois. I will be continuing my series on “What is an Agile Project Manager Anyway?”, where we deep dive on the role of an Agile Project Manager on both traditional and agile projects.

I’m really excited about this crowd. From what I hear, IRAUG is the hottest new Agile networking group in the country. If you’re in the area this week, I’d love to have you come check it out and join the conversation.

• Topic: “What is an Agile Project Manager Anyway?”
• Date: This Tuesday night, April 27th @ 6:00PM
• Venue: Holiday Inn Express, 1031 Wylie Drive, Bloomington IL 61701
• Details: http://www.meetup.com/IRAUG-ORG

After such a great experience at the Infotec conference last week in Omaha, I’ve committed to go back next month to teach a special edition of “Certified ScrumMaster for Project Managers”.

Granted, this will be similar to my other 2-day certification classes in Agile Project Management, where we discuss making the leap from traditional plan-driven PM to using the Scrum method in real-world situations. However, this will be a special session, in that I am co-teaching with Sally Elatta of AgileTransformations.com . Sally has established herself as *the* Agile coach in the midwest by serving big name clients over last 6 years.

If you are a midwest Project Manager, and you’ve been waiting for the right opportunity to get exposed to Agile Project Management, this is that opportunity. You get strong foundational training, the certification, and networking with one of the most important experts in the region.

Here are the details:

• Class: Certified ScrumMaster for Project Managers
• Date: May 18-19, 2010
• Location: Omaha, NE (Venue information provided upon registration)
• Price: $1,190 for General Admission
                 $1,090 for members of the Heartland or IA PMI Chapters
• PDUs: 16

This month’s PM Network Magazine features the latest installment of my “Agile Project Manager” column. You can read the column here (PMI Login Required). But In case you don’t have a PMI membership login, I’m posting the column below:

One team flounders in the best of times while the other flourishes in the worst of times.

I recently coached two project teams implementing agile. Let’s call them Team Flounder and Team Flourish. Team Flounder started with full management support, complete with expensive training and consulting help. However, six months later, the initial boost wore off and the team stabilized at a productivity level best described as okay. Team Flourish was given the worst of circumstances. Looking to avoid any notice by stakeholders, the project sponsor ordered the team to slow its progress. Furthermore, prime and subcontractors were at war. One year later, though, the project had accomplished more than anyone had hoped. Both teams had implemented the same methodology. Why did one succeed where the other struggled?

People Power
I’m convinced the number-one reason why projects fail is that the wrong people are on the team. Agile doesn’t solve your people problems. Rather, techniques like daily stand-up meetings and retrospectives are intended to expose people issues more quickly and nudge you in the right direction. To help filter out those who don’t fit a given project team, leadership author Bill Hybels offers the following criteria:

1. Character: People have to possess the mettle to do the right thing—as a team. Team Flounder suffered under the rule of one senior knowit-all who disparaged his peers. It took six months before the project manager fired the guy for the ongoing harassment. It was a relief to have him gone, but team members were left wondering if management would take that long the next time. Meanwhile, Team Flourish was under attack from a vendor. In response, the team formed an alliance with a few trustworthy contractors while staying firm with adversaries. It survived the sabotage and continued delivering.
2. Competence: Technical knowledge isn’t always enough. Team Flounder had a chief engineer who was undoubtedly smart, but she wasn’t the strong leader who would help team members grow. Team Flourish found itself in a feud with several buzzword-certified braggarts steering the project in the wrong direction. The core team spent weeks building an evidence-based case for the right strategy, and it worked.
3. Chemistry: Project managers often treat team chemistry as fluff and then are stumped why productivity is so low. When Team Flounder filled the roles of product manager and process manager, it followed the methodology rules to the letter. The problem was the two people picked didn’t get along. Every time one of them said something, the other felt undermined. As a result, the rest of the team was stuck without any clear direction. Team Flourish, on the other hand, was ruthless about pruning people who didn’t quite fit. The result was the strongest team dynamic I’ve ever seen—one that equipped its members to overcome all that weirdness of competing stakeholders and volatile project scope.

In the end, agile isn’t a silver bullet. The fate of projects is determined by people, process and technology—in that order.