The Unanswered Offshore Question

Student: "But how does agile work with offshore team members?"

Me: "Well, let's start by asking another question - 'Why are you offshoring?'"

Student: "It was a management initiative."

Me: "Why?"

Student: "To save money. The hourly rate is lower."

Me: "But agile depends on high team interaction and collaboration. This change in how work is done might have changed the economics of the decision. How do you measure how productive those offshore teams are? That is, how do you confirm that you are indeed saving money?"

Student: "Ummmm…I don't know."

I've asked this question dozens of times. Always the same answer.

When I am coaching clients, and ask management about this, and most of the replies are essentially "It was the VP's decision, and it's not to be questioned or challenged." Considering that the VP lobbied for it as a good decision, it may not be something most would like to look into and find that they were actually wrong about that $6,000,000 decision (multi-year deal given the resources I've seen). 

The only hard numbers we traditionally had to make a ROI decision on offshoring was the hourly rate, typically somewhere from $40 - $60 for developers, and I've seen as low as $20 for testers. Seems like we're saving money, given the typical $100 - $120 rates I've seen for US developers. But what if those developers don't get as much done due to the fact they can't talk to the subject matter experts and other team members in the U.S. (at least not much of the time, and not without delays, and rarely face to face)? If agile depends on that kind of collaboration, aren't we setting the offshore team member up for frustration and failure? 

Add to this the aging of the decision data. A senior manager in India recently told me, "Those CEO's in the U.S. made the decision to offshore based on very old data." Ten years ago, he told me, you could get a ridiculously brilliant 5 Star engineer in India for 1/10 the cost of the same in the U.S. Many companies rushed into India to take advantage of this - taking all the 5 Star/One Tenth engineers (Such a deal!!), then moving quickly to the 4 Star/Three Tenths engineers (Pretty good business decision). Then large outsourcing shops and system integrators rose up to take advantage of the great staffing and consulting business opportunity. By bundling long term, large team deals, they smoothed out the bumps that they were starting to run into with 3 Star engineers and a moderately lower rate. Now, my friend said, it is very hard to find good to great engineers, so the U.S. is being offered 2 Star (and sometimes even 1 Star!) engineers for a rate that might look like a deal on paper, but these engineers are often not as good as most U.S. company's own developers, AND we using agile. 

A year or two ago, I was coaching a team that was waiting to start their project after they go the resources from the offshore partner. But there weren't any. We waited several weeks before they got one potential to be interviewed. The interviewee didn't pass the technical interview. Not even close. Nor the second, third or fourth. Finally, nearly three months into the original project schedule, the team compromised for fear of either having the reschedule or cancel the project.

If don't get the benefit from the cost/benefit analysis, is this truly best for the company? If we extend the team to realize the value for a project, because it takes 50% - 100% longer due to communication exchanges, the value itself is diminished. And the hidden cost of the quality of resources is certainly higher than the information and stories based on 5 - 10 year old projects. 

And if a company is saying that going agile is a strategic decision, we have to look at the offshoring decision to see if that is best for the teams and therefore the success of agile.

My next post will be on how to objectively, quantitatively and qualitatively evaluate the productivity and cost effectiveness of the offshore teams.

3 Things To Do Today To Add Agile to Your Project

One morning at a client site, I came across a small group of people standing up around a table in a conference room.

"So you guys are using Scrum, too?" I asked." 

"No, we're not using Scrum at all. Our project has a deadline coming up to deliver, and we thought it would help if the team just met each morning for a few minutes to talk about what got done yesterday, what's on tap for today and if anyone was having any problems."

Whether using Scrum or not, you can apply these action items below to add some agility to your project. Keep in mind that when I say agility or being agile, I mean activities and attitudes that reflect the values listed on the Agile Manifesto.

1. Meet with your project team (those doing the work) each morning for 15 minutes. Ask someone on the team to facilitate each person answering these three questions:

• What did I accomplish yesterday?
• What do I plan to accomplish today?
• Is anything blocking me from getting my work done?

Interactive displays and interesting conversations at EWEA 2013 by European Wind Energy Association

Attribution-NonCommercial-NoDerivs License

If any problem solving or discussions beyond these three questions come up, the facilitator should ask that they be held until after the meeting when others who are interested can stay and continue the conversation. This is called a daily scrum or daily stand-up meeting. It's not a status meeting, but a collaboration touchpoint for folks doing the work.

See the thorough article It's Not Just Standing Up for a deep dive.

2. Use simple collaborative tools. Especially given that most individual contributors in IT are introverts, tools such as fist-to-five (or fist of five), dot-voting, using stickies to brainstorm or provide feedback provide an amazingly different amount and type of feedback. Anytime I just ask for ideas, or what people think, I'll get a third of what I would if I asked the group to write down their ideas, or give me a fist-to-five.

The Fist-to-Five: When you're in a group deciding on something, such as where to go to lunch, you can simply have everyone hold up fingers representing where they stand: 5 means they love the idea, 4 means they like the idea, 3 means they're not that happy but they won't get in the way, 2 means they have some questions or concerns that if answered they can get onboard, and 1 means no way ever never. Fist of five is a great way to hear everyones voice and quickly see who's not in agreement and why (and then work to get them in agreement).

3. Estimate together. Estimate without bias.

I used to go to each of my team members individually and ask them to estimate the effort for their or their people's tasks. What works much better is to bring all the team members together and have them do a blind vote on what they think the estimate is. I commonly hear of only the leads or architects being asked for estimates, but whenever I ask the team if they would like for someone else to estimate their work, they say know. I think it disenfranchises them, eliminates real commitment, and therefore hurts motivation and productivity.

In the big picture, it's best if the work to be done is defined in terms of small units of working software (user stories) and using relative estimation (points) to derive when the work will be done. But that's a big shift, and if your team or company isn't going to okay using Scrum or other agile approach anytime soon, you can still use some helpful aspects of this approach.

Describe the work to be done. Ask if there are any questions. After there are no more questions, have people write down the amount of effort they think it will entail. Pick the persons with the lowest and highest numbers and ask them to explain why they thought so.
Vote again.

Although I hope they'll agree on the same number, they probably will only get closer. It's best to let the team decide the final number. Regardless, I've found that the conversation and team member engagement was so much greater in regards to the requirements and the estimates than I ever had before, and this thoughtful, focused exercise will yield much better understanding and therefore estimates.

These are just some things you can do today to improve your project with collaborative practices that shift focus towards agile values such as individuals and interactions over processes and tools.

Great Forrester Comment - "PMO's are Becoming Incredibly..."

One of my favorite quotes on the PMO comes from this frank and humorous comment from Dave West, VP Research Director at Forrester Research. You can hear him and the other panelists on Agile Portfolio Management Q & A Panel at the link below. Dave's comment starts at 1:30.

"It's interesting, what we at Forrester have observed across the industry this particular kind of  maniacal kind of addition to the program management kind of practice. PMO's have grown in size and stature in organizations and become incredibly…big, in terms of their execution. One thing that it illustrates is that complexity does not solve complexity.  As organizations wrestle with increasingly diverse portfolio, time-to-market pressures, one thing that they want to do is add more complexity. "When in doubt, add more governance!","When in doubt, add more people to manage the people that are managing the people!" "When in doubt, get more Gannt charts!" And I think that we've found that that does not work. I think it's clear that breakthrough companies or companies that are definitely driving the industry around change and innovation are not solving those problems with complexity."

http://www.youtube.com/watch?v=kN99R6Plw3E

Agile Planning Poker Rules

I posted earlier on planning poker, and since it's a popular post, I thought I'd post again on it.

One item that came up in a recent sprint retrospectives (in the "Where do We Need to Improve?" list) was getting better requirements and estimates. So, after the following planning meeting, where the CEO selected his highest priority items, the team met to review those items.

The meeting seemed to be another poor meeting of nothing definite or different being done - lot's of "Well, I'll need to look at that one more," or "Well, management says it needs to be done by next week, so what does it matter how long I think it will take?". I was ready to call the meeting until Martin asked about the planning poker cards (shwag from Phil Scott at the Agile Panel Discussion at the LA Code Camp). He hadn't used them before so we walked through the instructions:

1. Each team member is given a set of cards.
2. One person read the item to be estimated.
3. The team & customer discuss the item.
4. Each team member privately selects a card representing his/her relative estimate.
5. After all have chosen a card, everyone shows the chosen card.
6. If all estimates match, that item's estimate is complete.
7. If estimates are not the same, the group discusses the differences (focusing on the outlying values).
8. Repeat until consensus is reached.

Few notes on modifications we made to the rules -

• We don't have any business members there, but call in the requester if needed.
• We re-estimate until within one card value of each other, or take the median value if there's a majority.

The team really enjoyed, and benefited from the experience. The secrecy of each persons' pick not only made it fun for them, but it got each person so plugged into the task at hand. There was kidding of those who's estimates were way outside the norm. For outrageously low estimates, we rewarded the low-bidder's confidence by giving them that task, but with an agreement that if they met the estimate, we'd buy them lunch. It was particularly enjoyable to see how much this engaged Jeoff, our only team member with the strength Competition. There was great discussion on all the tasks the team had ahead of them, and we left the meeting with a lot more shared knowledge, both where we're weak and where we're strong.

You can buy planning poker card sets from Mike Cohn's Mountain Goat Software site.Technorati Tags: agile, scrum, project managment, software, team building

Comparing Mingle and ScrumWorks Agile Scrum Project Management Software

Thanks to a recommendation, I'm now using Mingle. I've found it easier to use than ScrumWorks and Excel for managing the product backlog, sprints, user stories, and tasks. My favorite feature is the ability to group stories and tasks by sprint, each card color coded to reflect status, and you can drag the cards into other sprints.

One draw back is that it's hard to beat the visibility and energy of Post-It cards on the wall in status swimlanes, but you also can't export the Post-Its into an Excel sheet to send to management for a quick status report.

Each project management tool I've tried has it's drawbacks.

1. The Excel worksheet with stories, tasks and burndown was labor intensive to set-up or change very much, and often confused newcomers to the team.
2. ScrumWorks is not intuitive, and couldn't show burndown on partially complete stories and tasks.
3. The Post-Its can't be mass-updated, reported on, nor accessed remotely.
4. Mingle doesn't have a burn-down (that I found, although rel 1.1 is said to have one), and performance is pretty bad.

Right now, the customer likes to see the project overview, and Mingle provides that at-a-glance better than the others, so I'll be sticking with Mingle for now.

Agile Project Estimation w Scrum Planning Poker

I learned this week that planning poker is a big return for the small investment. I could not find planning poker cards in stock anywhere in the world, until Mike Cohn just made them available again (http://www.mountaingoatsoftware.com/products/cards).

Besides all the great benefits outlined in Mike's great book on Agile Planning and Estimation, I found that the team interaction was good. There were great alternative views and just an overall good feeling of everybody's opinion counting.

Project Areas and Team Member Proximity

I’ve seen significant increase in information sharing on project teams due simply to having daily scrums (agile status meetings). I’ve wondered how much more would communication (and therefore team performance) improve if I had the team members moved to cubes in the same area. The evidence from Tom Peters, below, is significant. Note how close teammates need to sit for optimal interaction.

“…if you and I are separated by 5 yards or less, the odds of us communicating at least once a week are nearly 100%. At 10 yards of separation, the odds plummet to about 9%; and said odds are almost constant at 3% if we're 30 to 100 yards apart.”

Quote referenced from Tom Peters’ weblog here.

Which Project Management Approach Is Best?

I've been studying the Guide to the Project Management Body of Knowledge (PMBOK) lately, in preparation for the Project Management Institute's Certified Associate in Project Management credential (CAPM®) . I had recently read Craig Larman's book Agile and Iterative Development: A Manager's Guide. Reading about so many benefits of being agile and incremental in project approach, I would have said my project management preference was agile.

Now that I'm reading the PMBOK, I'm finding that there is a lot of value in the process-heavy PMI PMBOK. I say process heavy because, for starters, there are over 20 process steps in the Planning Process - one of five core processes. Each of those process steps can have several input and output artifacts. The value I'm finding is that, per the PMI's decades of effort towards a comprehensive project management guide, if I know their framework I shouldn't miss any steps in the next project I work on. I say framework because the PMBOK itself says that the steps are optional, and should serve indeed only as a guide. So, take what works and leave the rest.

One fear I have is that perhaps some say 'go agile' partly because it is easier to digest and understand in your head. But if someone doesn't understand all the possible steps they should take, they will miss the times when some extra process step would have saved the project at a critical juncture. Like any software framework, the PMBOK is a structure, guide and set of optional tools, but the benefit is in knowing what it is and therefore what you can apply where. Agile, in part, means low ceremony and therefore just enough process and documentation to deliver a quality product that meets the customer's needs and expectations. In my opinion, Agile and the PMI are not mutually exclusive. Not only that, it seems apparent that smaller, less defined, lower risk projects would benefit from an agile approach, while a large, multi-disciplinary, high-risk project woould be best suited following the PMBOK's process tightly. And odd as it sounds, I'm studying the PMBOK while starting my second agile project management book (Agile Project Management : Creating Innovative Products).

Perhaps its human nature, but I'm finding some tendency to polarize. I've worked with developers who felt that client-server was old and bad, and that, web development was the obvious direction to go, but there's a right time and scenario for each. I think people like precut answers, and veer away from answers like "well, that depends.."

So, what project mgmt approach is the best? Well, that depends...

11 Commandments and 10 Reasons

Two good lists:

11 Commandments for an Enthusiastic Team

1. Help each other be right....not wrong.
2. Look for reasons to make new ideas work - not for reasons they won't.
3. If in doubt, check it out. Don't make negative assumptions about each other.
4. Help each other win and take pride in each others victories.
5. Speak positively about each other and your organization at every opportunity.
6. Maintain a positive mental attitude - no matter what the circumstances.
7. Act with initiative and courage as if it all depends on you.
8. Do everything with ENTHUSIASM...it's contagious.
9. Whatever you want ... give it away.
10. Don't lose faith and never give up.
11. HAVE FUN!!

and

The Top 10 Reasons Projects Fail

1. Inadequately trained and/or inexperienced project managers
2. Failure to set and manage expectations
3. Poor leadership at any and all levels
4. Failure to adequately identify, document and track requirements
5. Poor plans and planning processes
6. Poor effort estimation
7. Cultural and ethical misalignment
8. Misalignment between the project team and the business or other organization it serves
9. Inadequate or misused methods
10. Inadequate communication, including progress tracking and reporting

For more information, check out Ian Percy's site (11 Commandments) and Frank Winter's series (login required) on GanntHead.com.