Offshore Agile Isn’t the Problem. It’s the Solution.

By | Blog, Uncategorized | No Comments
offshore team working virtually

graphic courtesy pictofigo.com

The honeymoon is over. Looking to deliver more while spending less, just about every large company has engaged in distributed offshore projects over the last several years. But organizations are discovering that outsourcing carries more pain than was promised. More projects are suffering from quality issues, language gaps and woefully unmet expectations. So what can we do? Here are some ways that Offshore Agile projects are overcoming some of these side effects:

Forced Collaboration

Agile project management places a strong emphasis on collaborative communication. Using written English can sometimes mitigate language issues, but email takes too long, and large documents can be stale the moment they’re sent. Instead, we augment project communications with standard processes like a daily call, team chartering, and working agreements. To make that more feasible, teams are using modern online collaboration tools such as Google Docs, instant messaging, discussion boards, and Skype. Some teams have always-on webcams so each side can see what’s happening on the other. You can’t have successful projects without some kind of interaction. If time zones make that inconvenient, share the pain, with each worksite taking a turn after-hours. In short, agile methods expect you to work hard to communicate in real time. You’ll develop stronger collaboration, which will yield greater understanding and more innovative results.

Get bad news early

A mentor once told me, “Never surprise your boss.” Similarly, a good project manager wants bad news as early as possible. One of the greatest pain points for distributed projects is unmet expectations. Sponsors can spend significant time and money generating rigorous requirements, wait a year to see any output and then receive a single large deliverable that simply misses the mark. If iterative-incremental delivery is a good risk-management practice for local projects, then it’s absolutely vital for distributed projects. A monthly demo using a virtual meeting platform can reveal problems and opportunities earlier in the game. If it reveals a slew of defects, the sponsor can reprioritize debugging over adding new features. If an incremental deliverable is built to off-target specs, the sponsor still has the opportunity to swap some of the pending features for the needed refinements.

Formalize Problem Fixing

Conventional offshore projects rely heavily on up front planning, to minimize the pain associated with distance, silos, and time-zones. However, no amount of planning can account for surprises and mistakes. This is why Agile methods formalize policies around fixing problems and changing course. Demos give a chance refine the scope for optimum value. Retrospectives give voice to issues that need escalating. Transparent metrics reveal issues that need to be analyzed further. In short, agile processes require you to pay attention to the issues that crop up on virtual projects.

Now It’s Your Turn

As it turns out, I’ve written a whole minibük on this topic, which you can download for FREE here. It goes into more detail on both insights and tips. Check it out and then post a comment or send me a line: What has worked for you in making the most of offshore, distributed, virtual project situations.

[NOTE: This post was originally published as part of my recurring column, “The Agile Project Manager”, printed in PM Network magazine. Other installments and more info can be found here]

The magic secret to achieving your goals? Be willing to fail first.

By | Blog, Uncategorized | 6 Comments

This year I accomplished one of my dream goals to run a marathon. It was a climactic moment where I graduated into another class of achievers. Want to know my secret for how I did it?

I failed the first time. And that failure directly led to my success.

step 1 fail with goals. step 2 succeed with goals

I had actually set the goal of running a marathon back in 2012. Near the middle of the year, I created a December 6th deadline by paying money for the Rock ‘n’ Roll Marathon in Las Vegas. I downloaded a running plan, and bought some shoes. Then, with two months left I got shin splints. When I told the doctor that resting for several days didn’t do the trick, she said, “No Jesse. You need to stop running for several weeks. I’m sorry, but you’re not going to be heal in time to finish your training program.”

Here are the three things that I did to set the stage

1. Reframe “failures” as progress

Modern management methods like Agile or Lean Startup espouse the virtue of failing fast. That is, if you’re going on the wrong path, you want to find out sooner than later. Better to get slapped in the face early in the game, rather than spend bucket loads of time and money on the wrong thing. All of that sounds great, but I can assure you that when the doctor gave me that news, I was crushed. I had already paid for the race, as well as the hotel and airfare to get there. But after the dust settled, I recovered, flew to Vegas, and ran the HALF marathon at that event.

  • The only way you get on the injured reserve is when you’re already on the team.
  • The only way to get shut down is after you’ve already shown up.
  • The only time you lose the championship game, is when you’ve already beat everyone else.

Or put another way,

Failure is directly correlated to progress, no matter how small.

2. Refocus on learning

After the half-marathon, I had to look inward and ask WHY did this happen. I was a decent cross-country / track-and-field runner in High School and College. I SHOULD have done better. So, I started asking and reading. I bugged friends and colleagues who had run marathons before, and heard what hurdles they slammed into. I read books about the barefoot running and mid-foot strike, which led to me altering my stride. I read another book about over-training and going too hard too fast, which led to me slowing down my pace. What happened was this:

Failure motivated me to unlearn the wrong things I thought I knew

Given that I had been a casual runner my whole adult life, I assumed I knew something about running. But there is a difference between a 2 miles on the treadmill at the gym versus spending 2 hours on the road. I was in a different ball game, and needed that failure to wake me up. I wonder if this has ever happened to you.

3. Resolve to be patient

It was about in March when I started running again with some kind of regularity and conviction, and it was time to reset that goal again. Last time, going aggressively got me injured. So, this time I’d do it differently. I planned my next half-marathon in 4-5 months,  and a full marathon another 2 months later. It turned out to be critical. I spent most of the year traveling to business clients all across the country, which made regular exercise really tough.

Failure reminds me to take my goals seriously

Achieving goals comes only as a result of developing new habits, and new habits take time. Lots of time.

The marathon was one challenge I overcame this year, but there have been plenty of other  pains / burdens / failures. In each case, momentum came only after I worked to re-frame my failure, re-focus on learning, and resolve to be patient.

Now it’s your turn. Which of your life goals did you achieve only after bumps and hurdles?

Washington Techies Hold Retrospective on Healthcare.gov

By | Blog, Uncategorized | 2 Comments


Last night, I attended the Washington DC Scrum User Group’s monthly meeting, where a group of 25 technology professionals talked about the Healthcare.gov crisis. There’s been a lot of debate in traditional media as to why the website project incurred so many issues.

The group discovered four common themes…

No One in Charge: The congressional hearings revealed the classic accountability problem: Everyone was in charge of their part, but no one was in charge of the whole thing. If there were ever a conflict over which agency or contractor needed to own an issue, there was enough ambiguity to deflect any blame. Also, even if CMS took accountability for stitching together all the pieces, they would have needed the appropriate expertise in house, which by all accounts, was not the case.

Quality: By now, we’ve all heard the story that overall system testing began way too late in the game. Each agency or contractor reportedly delivered their components just fine, but cross-system testing happened too little, too late. The group discussed the value of continuous integration, applied not just to the individual components, but to the entire program.  

Big Bang Delivery: The opposite of continuous integration is last-minute, all at once integration, which we saw with Healthcare.gov. The group wondered out lout what problems would have been avoided if the program release support for only 1 state at a time. Releasing one small piece of the capability at a time allows for progressive learning and elaboration of the technical solution.

Volatile Requirements: Several fascinating points were made regarding the scope of the project getting delayed and changed in a way that would put any technology project in jeopardy:

  • Scope Unrealistic: One person made the point that the ACA law refers to “the website” 118 times. This means the website project was launched with over a hundred system requirements, which ostensibly, had not been reviewed by technical experts.
  • Scope Delayed: Much like any large scale project, the 2012 election created very real political forces on the project. Out of a sense of prudence and self-preservation, the administration held off on several policy decisions that were feared to have a potential impact on the election. As a result, key questions (like the difference between a gold and silver plan) were delayed until after the president and the democratic Senate were safely secured.
  • Scope Changed: When the Supreme Court ruled on NFIB v Sebelius in June of 2012, all of the Medicaid expansions were invalidated. Needless to say, that would require any previous work on that piece of the system would have to be reworked.
  • Scope Expanded: The website was originally envisioned to be a pass-through portal to the state-run exchanges. However, when Republican governors overwhelmingly decided not to create state exchanges, the federal website would now have to support those states as well. Expanding from 8 exchanges to 34 could not have been a trivial change.
Completing my last half-marathon before the BIG race

Agile Project Management for Marathon Training

By | Blog, Uncategorized | 8 Comments
Completing my last half-marathon before the BIG race

Completing my last half-marathon before the BIG race

This weekend I will run my first marathon ever. It’s been a journey that’s taken over a year to get this far, and even then only with the use of agile project management techniques from an adaptive and empirical mindset. I’m sure it will take me a handful of posts to talk about all the techniques I used, but the first one I want to share with you is this:

Deliver Early, Deliver Often.

Theory: Agile practitioners universally advocate the use of short cycles. When large scary projects are decomposed into a series of timeboxed phases, they suddenly become suddenly achievable and less intimidating. It turns out that marathon training already has a commonly accepted cycle for crafting a project schedule: the weekly running plan.

Application: My very first research efforts led me to www.marathonrookie.com, which offers a basic 16-week complete training plan, broken down into a series of weekly goals.(scroll down to towards the bottom to see it). This is HUGE! Now I don’t have to run 26 miles, I only need to run 3. Heck, even I can do that.

In fact, I’ve heard that for distance running, your weekly goal is all that really matters. One of my advisors, PM expert and 3-time marathoner Dennis Stevens, told me that you should shoot for running in a week 1.5 times the number of miles for your target race. Running a 10K? Target 15K-per-week by race day. Running a half-marathon? Target 20m-per-week by race day. By the time you hit your peak, most marathon training plans have you doing between 34-40 miles per week.

More posts to come: Right now, I can think of several other techniques I used that I will be sharing with you all, such as…

  • Go Small.
  • Don’t fight adversity, adapt to it.
  • Define project success beyond the constraints.
  • Get some project data.
  • Choose your team.
  • Build an infrastructure.
  • Review your Budget.

…and so on.

What about you? Have you found project management to help you achieve large personal goals like this?

Large Agile Estimation Scenario: Pure Story Points

By | Blog, Uncategorized | 4 Comments
Affinity Estimation for Large Groups

Affinity Estimation for Large Groups

Now that we’ve covered the problem of estimating large agile projects, as well as some underlying considerations, I want to explore some scenarios and approaches that have been used in the community. First, a word about “large”.  If we are talking about 3-5 teams, the problem of multi-team estimation tends to be quite manageable. The real pain comes in around 10 teams or so. However, for purposes of our discourse here, I am going to use a 4-team construct just to illustrate the considerations.

Context: We have four agile teams (Alpha, Beta, Gamma, Delta) all working on the same project. We’ve completed our latest major release, and now the Chief Product Owner (sometimes called a Product Manager or Program Manager) needs estimates on all the candidate initiatives (sometimes called projects or epics). We already have known, stable velocities for each of the teams, so we should be reasonable able to determine which initiatives will fit into the next quarterly release. Furthermore, the group has been a cross-functional committee called the Product Ownership Team, consisting of the Chief Product Owner , the four team-level Product Owners, and a couple architecture and operations tech leads.

BEFORE the Release Planning meeting:  During the previous release, the PO team has been continuously grooming the backlog of upcoming epics continuously in preparation for the release planning event. During the regular team-level grooming meetings, each PO and tech lead has been soliciting team-level size estimates of the upcoming epics. For example, the Scrum Guide allows for up to 10% of the dev team’s work time be used for grooming activities in support of the Product Owner.

STARTING the Release Planning meeting: All 50 people in the program convene together in a large room.  The Chief Product Owner give a quick overview of the upcoming strategic goals. Then, he reveals the aggregated estimates, based on rthe team-level input that has been solicited during the previous release:

  • Social Media Initiative = 47 Alpha story points + 22 Beta story points + 10 Gamma story points + 112 Delta Story Points = 191
  • Performance Improvement Initiative = 12 Alpha story points + 45 Beta story points + 0 Gamma story points + 33 Delta Story Points = 90
  • Realtime Data Dashboard  = 125 Alpha story points + 8 Beta story points + 40 Gamma story points + 51 Delta Story Points = 224

Total Work = 191 + 90 + 224 = 505 points

Then we look at Total Velocity = (41.4 for Alpha + 55.2 for Beta + 41.3 for Gamma + 38.2 for Delta)  X  three  iterations = 528.3

The Product Owner is proud of his math and declares, “Since our proposed work fits within our average velocity, we should be able to get all this done over the next 3 months….right?”

ADJUSTING the Release Planning meetingImmediately, a number of people raise a concern that our understanding of the story point scale has deteriorated over the last few months. The meeting facilitator proposes they hold a cross-team estimation workshop to reaffirm their program-wide story point scale. They quickly pick a few of the backlog items for which they have a common understanding of risk and complexity. Then, they use spend a some time performing a planning poker tournament or Affinity Estimation for large groups. Then, they update their “estimation wall of fame” with the backlog items they all agree represent the best definition of 5 points or 13 points or such.

CLOSING the Release Planning meeting: With the common inputs all resolved, the teams then have breakout sessions where they review the proposed work, and go deeper into their team-specific backlog items, explore acceptance criteria, risks, integration points. They work together to understand whether they can reasonably commit to achieving the Chief Product Owner’s goals for the release. If new information changes the risk or complexity of backlog items, they re-estimate them on the spot. If we discover the work is too big for the upcoming release, we remove some of the work to achieve a minimum marketable feature that fits within the strategic constraints set by the Product Owner. This is called flipping the iron triangle. In the end, the meeting should close with a program wide confidence that we will be able to meet the release-level goals, because we have used our estimates to measure the work, and adapted the backlog to fit within our constraints.

Simplifying Observations. Many of you are reading this and thinking, “well of course that’s how it works”.  But I believe there are some critical assumptions that make this story work:

  • Everyone agrees the teams should operate on synchronized iteration schedules of 4-week duration
  • Everyone agrees we all use story points, for all the benefits they provide
  • Everyone agrees we need to have a common story point scale, so that we can easily aggregate and arithmetize the numbers
  • The POs and Tech Leads have been soliciting input from their teams on the risk and complexity of each initiative from that team’s perspective.
  • The POs and Tech Leads have been working together, outside of the agile development teams, to integrate and reconcile the estimates into a candidate plan
  • The entire program comes together to verify & revise the estimates, and then use the estimates to adjust the backlog to fit the strategic constraints.

This is the first scenario. The next one I want to cover is the usage of ideal days across a similar program.

What about you? How have you been able to use story points across large programs?

I’m speaking on the “The Agile Business Analyst” TOMORROW night

By | Blog, Uncategorized | No Comments

iiba-baltimoreJust a quick note to say I’m speaking tomorrow evening at the Baltimore Chapter of the IIBA.

I often get asked “What is the role of a BA in an agile environment.” Much like a project manager, a business analyst carries a set of expectations and is legitimately interested in how that changes when we change our approach to work. If you’re a BA, product manager, or someone that works with them, come join the conversation.

Agile Paralysis: How Agile impacts your role and the BABOK

When: Tuesday Jan 8th @ 7pm

UMBC Technology Center
1450 South Rolling Road
Baltimore, MD 21227

It’s official: Agile is all the rage. In businesses and projects all across the world, we’re being told to use Agile methods to be more successful. But how is that possible, if it means we don’t do documentation any more? What is the role of a BA on an Agile team? And with the upcoming release of the Agile Extension To The BABOK, what does the IIBA think of all of this?

Link: http://baltimore.iiba.org/index.php/chapter-events/event-listing/details/74-Jan13-chapter-meeting

Agile experts say the stupidest things

By | Blog, Uncategorized | 5 Comments

It drives me crazy. I heard an agile consultant this week say, “We’re trying to force the client to track progress they way we want her to”. Really? Good luck with that.

People tell me over and over the things self-appointed agile experts have said, and when you think about it, not only do they violate the spirit of the agile movement, they just sound silly. Tell me if you’ve heard one of these before.

“Our project will succeed only with a full and immediate implementation of an agile methodology, and its associated project tracking software”.

 The official definition of the agile movement can be found at agilemanifesto.org, which explicitly values Individuals and Interactions over Processes and Tools.Granted, a shrink-wrapped set of people-friendly policies can be a good foundation for transforming a losing team into a winning team. Indeed, I actively promote both the Scrum methodology and the PMI-ACP certification as good things. But that does not mean just doing those things will automatically improve team performance. Instead, a true agile practitioner will ask simple breakthrough questions: Are we all on the same page? What agreements can the team install and self-enforce, to address those gaps? How can we customize our current methodology to support those agreements?

As I’ve mentioned here before, the methodology doesn’t matter. What matters are the principles you embrace towards delivering your project.

“We’re agile now, we don’t do any project documentation”.

 This common myth is seeded in the manifesto’s favoring of Working Software over Comprehensive Documentation. Granted, many projects waste money on piles and piles of reports that nobody reads. But, that does not mean we throw everything out the window.

Instead, a true agile practitioner will seek to understand why those documents are mandated. Sometimes, a better specification can often improve the quality or accuracy of the final deliverable. Sometimes a risk register or Gantt chart can help increase credibility and stakeholder support for a project. The document doesn’t matter; what matters is that we address the underlying need.

“Fixed-price contracts are immoral. All our projects will now be time-and-materials.”

 This is a fanciful interpretation of the agile manifesto stating its preference for customer collaboration over contract negotiation. Granted, many projects are launched as the result of zero-sum negotiations leaving a project team underfunded and understaffed. But that does not mean we refuse to have the conversation.

Instead, a true agile practitioner will strive to forge a positive working relationship with her sponsor with deeper questions: What are the client’s concrete business goals for this project? If push comes to shove, can we achieve the goal with only half the features to stay on schedule? Is it possible more budget would be approved for extra safety reviews?

Fixed-price doesn’t matter. Several people have offered agile contracting structures that support what does matter: a positive working relationship around project goals (for more info, see my PMI webinar on the topic of Agile Contracts).

“We’re agile now, so we don’t have to estimate. The project will be done when it is done”

This delightful gem is inspired the value the manifesto places on responding to change over following a plan. Granted, many projects are mindlessly judged on budget and schedule, regardless of how bad or how wrong the deliverable is. But that doesn’t mean we stop planning altogether.

Instead, a true agile practitioner will generate as much meaningful data as possible about our health of our project: Will we run out of money before we achieve our goals? Does our sponsor have enough data to make hard trade-off decisions? As General Eisenhower said “plans are worthless, but planning is everything.”

“That’s not agile.”

Guest what. I don’t care what you think is agile. I care whether we’re going to deliver. In the end, a project is judged not on the mechanics used, but on the objectives met. The agile movement was launched as a reaction against a focus on bad mechanics. If you’re falling in love with your agile mechanics as the silver bullet, then you’re dangerously close to losing your agility.

What about you? What silly things have you heard agile people say, often in direct contradiction to the Agile Manifesto?

[NOTE: This post was originally published as part of my recurring column, “The Agile Project Manager”, printed in PM Network magazine. Other installments and more info can be found here]

small house in person's hand

Want successful projects? Do less work

By | Blog, Uncategorized | 6 Comments

The most dramatic cause of project overruns is that we are doing more work than is absolutely necessary to achieve the high-level scope statement. But you can be the exception. Do not simply accept the project plan handed to you. Facilitate true innovation, which is delivering the most valuable business results from the least amount of work.

Read More