management

Multi-site teams: travel and the half life of trust

If you’re working on a distributed creative team, especially ones spread across timezones, today’s post from Steve McConnell is a great reminder that you’re not alone in your struggles:

Travel restrictions and offshore development

The article is right: there’s currently no substitute for travel at those kinds of intervals.  “The half-life of trust is 6 weeks” rings true.

Even in normal times, this is a heavy cost to bear, both for the company and for the people on the road. I’ve been at companies that have handled this “ok”, but never seen it be 100% positive and pleasant — this is a very hard problem.  There’s a reason why Microsoft largely kept everyone on the same campus for almost 20 years up to the late 90s — and a reason why you should think about keeping things simple that way as long as you can, too.

If staying single-site as long as possible is the first line of defense, the second line of defense is trying our best to minimize and partition multi-site development in careful ways — e.g. into distinct products, projects, or features — to minimize trust issues and cost of communication.  But this can only go so far in avoiding the issues of trust entirely. At some point (likely sooner rather than later), the worlds must meet, rules must be followed, decisions must align, and work on the product will overlap.

So, then, how do we design our processes and communication to be multi-site friendly? What processes and culture do we insist stay common or allow to be flexible?  How do we maintain the trust to coordinate the things that we must?  How can we hire more forgiving personalities for whom trust and camaraderie come easier?

There are certainly lessons to be learned from highly distributed open source projects (in particular, the tools they use and the ways they use them), but also cautionary tales of the borderline chaos that can ensue when the ties that bind are so loose and light.  And I’m waiting for a good tell-all to be written on Google and some other other more recent companies who have embraced highly distributed organizations.

Going back to Steve’s post and how there’s no substitute today for spending time in person: we can only  hope someone eventually finds a way to make multipoint video conferencing and techniques of remote socialization and team-building much more effective. It’d be great to not consume the time and energy of flying all over the planet — but that day doesn’t yet appear to be here.

Perhaps we could start with some company-sponsored network gaming to have some fun and get to know each other better? … of course, we then must decide which of the Bangalore, San Francisco, or Cambridge teams we’ll ask to get up at 7am to play.  Hmmm.

Comments (6)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Software development is like golf …

18th_hole_pic

Software development is like golf in that your chosen path to the pin is a primary problem.

The choice involves weighing your capabilities (people), the course (technology), and the conditions (market).

Confident you can do anything?  Bring out the big guns and send it over that treeline on the left. If you make it, you must land it among that sea of traps. This is the most common choice in software development, and the #1 reason why we so frequently turn “par 5″s into 10, 15, and 20s.

Don’t have a team of Tigers?  Then go long down the center if you can avoid that large sand trip on the left and lake beyond it. But is this abstract little map accurate enough?  Does it tell us about the 50 yards of soggy turf there in the middle?  How about wind howling left to right over the lake?  Unless you’ve played this hole before you don’t know.  What makes software development so tricky is by definition we never play the same hole twice.  Technology is changing around us, even while we make our own changes.

Want to make sure you don’t turn a par 5 into a 10?  Land it short of the traps on the fairway and take it from there with comfortable strokes. There’s a price to pay for this caution: no holes in one for you.  You’re less likely to be a hero this way, but in team-scale software development, the hero model will fail you are sure as a week in Vegas, anyway.

And, sometimes, the conditions are particularly bad.  In the downturn of 2008/2009, one could say the conditions for technology products are analogous to “a raging hurricane, with chance of nearby volcanic eruption and ash over the course.”  So take care. Be humble.  And may you keep both your work in progress and your golf scores down.

(apologies to all software developers offended by an anology from the “sport of salespeople and CEOs”.  Think of it as an analogy to bridge the divide)

Comments (6)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Accounting for opportunity and cost

A universal challenge for technology companies is having more demands to improve the product than we can implement.  This problem gets bigger as we get more successful.

Because our capabilities and those demands shift over time — if we want to maximize the value of what we deliver to the customer, then we want to tackle things in a prioritized fashion, knowing we simply won’t get to it all in any one release cycle.

And this prioritized breakdown better supports moving to a lean/ kanban workflow.

How to best analyze and prioritize all these requests, then? We want to be able to do it systematically, regularly, and have these priorities reflect (the best we can) the sweet spot of both the market value of an idea, and the engineering cost to create it1.

This last part is difficult, but especially important.

Say we have a few alternative design ideas for satisfying a need. Because it may appear “anything is possible” in software, we may be tempted to try to deliver exactly “what the customer wants.” Let’s say that’s design A.  Unfortunately, developing design A could be a bad choice, because it could easily take many times the effort of a very similar and nearly as appealing choice B, just because it asks for some functionality that doesn’t neatly fit into our existing system and available components around us.  A fundamental principle of software engineering is that even a small shift in requirements can cause a huge shift in cost and/or risk of development.

It’s similar to choosing to fit within the limitations of available off-the-shelf parts for a home remodel — it is obviously much cheaper than buying custom.

But “off the shelf” is an unfortunately non-obvious, slippery concept in the shifting world of software.  To reuse something, whether it’s your own code or someone else’s, there’s often a chain of “if”s you have to walk down: “We can save 2 months of effort by using this nice library IF we assume customers want Windows .NET only; IF we use C#; IF we take a dependency on .NET Framework 3.5 SP1 to get the libraries we need; IF we only do features A, B, D, and E, and punt on C, because it would require we rewrite and replace the library…” and every such path is usually followed by a “BUT, if we do that, then we are locked into not doing …”.

In most cases, developers on your projects won’t know all the alternatives and consequences until they’ve delved deeply into the design and usually into the code.

This is one of many reasons why two strategies are so important in getting (re)prioritization right for software engineering:

  1. Include both marketing and engineering equally in the decisions of what features to prioritize.  Systemically account for both world views, while coming to one decision.
  2. Plan to adjust your feature set over the course of the project, as your team learns new things.  By allowing for small adjustments and sacrifices in the requirements, you can dramatically lower the project cost and risk.

#2 is common advice for a host of reasons.  #1 can be achieved with the right people, and a structured decision making method like perpetual multivoting, or a Delphi decision making method that will be described in a future post.

When the right people are paired with the right process in this way, the spigot of innovation will open wider, benefiting both you and your customers.

Notes

(1) We actually want the sweet spot of the triumverate of Voice of the Customer (VOC),  Voice of Technology (VOT), and Voice of the Business (VOB) — so we can prioritze the work that will deliver the most value to our customer, with the lowest effort and risk, with the best financial outcome for our company.  In many companies, we break these perspecives down (for better or worse) into specializations: sales represents the pure VOC, marketing VOB, and engineering VOT.  So the challenge is — finding a sweet spot means getting perspectives from several people, often with very different backgrounds and communication styles, who wouldn’t normally be caught dead getting drinks at the same pub with each other …

Comments (2)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Management Improvement Carnival #50

John Hunter asked us to host this edition of the Management Improvement Carnival, and of course, we are delighted to oblige! Here are some recent articles about topics that are near and dear to our hearts. Submit your nominations for management posts to include in future editions of the Carnival.

  • Australia learns about outsourcing costs by Kevin Meyer: The decision to outsource work overseas is often driven by a mass-production mentality that yields predictably disappointing results.
  • Blinders of Supply Chain Complexity by Kevin Meyer: Another day, another article trying to figure out how to simplify global supply chains…
  • Starbucks queue by Kevin Meyer (sorry just can’t get enough of Kevin this month): A simple visual control can help your friendly coffee shop staff level out response times in the face of irregular demand (something about this example looks familiar!).
  • Is kanban only suitable for mature teams? by Karl Scotland: As Lean methods take root in the world of software development, some familiar questions appear regarding their adoption.
  • Exploit the workers! by Pascal Van Cauwenberghe: A provocatively titled anecdote about applying Theory of Constraints to software development teams.
  • Real Options by Al Priest: An everyday example of using real options to make decisions under risk and uncertainty.
  • Is ‘Design To Cost’ better than ‘Estimation of Cost’: I think so! by Tom Gilb. “[Time and cost estimates] are an old custom, intended to prevent overruns, and to give management some feeling that the job will get done in time at a reasonable cost. But they do not in fact prevent overruns or assure value.”
  • Nailing the nominals by Eric Brechner. It is easy for engineers or methodologists to get carried away with exotic optimizations. You have to start with everyday discipline about the basics.
  • 7 habits of highly effective program managers by J.D. Meier: Microsoft has a lot of Program Managers. What do the some of the best ones have in common?
  • Are cocky developers worth it? by  Eric Spiegel.  Prima donna software developers can be encouraged by a heroic “performance review” culture.  But as Mary Poppendieck says, software development is a team sport.
  • Where did middle managers come from? by Jeffrey Krames:  A new anecdote from a conversation with Peter Drucker, which leaves the reader wondering…where should middle managers be heading?

Comments (6)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Getting lean to survive the downturn

Promising startups are exiciting. But during a downturn, they can also feel a little too exciting.

Funded startups are always on the clock:  Time till the next funding round. Time till cash flow positive. Time till a public offering.

In a severe downturn the clock keeps ticking, but it becomes harder to bet on closing that next big sale or funding round.  Financial visibility declines.  Management must aggressively take action to steer the corporate ship to account for the increased external risk and uncertainty: 

  1. Re-prioritize to focus on the highest probability, nearest term revenue opportunities
  2. Cut spending to preserve cash
  3. Look carefully for unique opportunities in the surrounding turmoil

The more severe the downturn, the more aggressively these actions should be taken.  Yet traditional organizations are poorly equipped to handle this change:

  • Forward-looking plans and budgets that were carefully set in stone, now break rather than bend.
  • Severe bottlenecks appear throughout the organization as the ratios between dependent teams and specialists get thrown off by hiring freezes or layoffs (“We were counting on that team to deliver their part of the project, but they’re all laid off!” or “How can we hit the same schedule with half the test team?”)
  • An organization that isn’t practiced at delivering value on short cycles and dynamically re-prioritizing, will find their plans churned and capacity to deliver shredded.

The reason why lean thinking is so powerful is it embraces change. When the market is in turmoil, change is legion and organizations that apply lean thinking stand the best chance of surviving, or even thriving.  To best satisfy the 3 goals above, take steps in the lean direction to:

  1. Get closer to the customer. Listen to their priorities. Tighten the feedback loop.
  2. Break projects into smaller pieces and deliver them on shorter cycles.
  3. Drive the organization with clear but dynamic priorities, rather than long-term dates, deliverables, and deadlines. 
  4. Break dependencies between projects and between specialists.  Give small teams everything they need to deliver on their own faster schedule.
  5. As change churns the organization, regularly ask “where is our bottleneck now?” and do what it takes to resolve it.
  6. Break the “union mindset” of specialization. Ask everyone to attack the bottleneck wherever it is.  Retain generalists who can thrive in an environment of change.
  7. Don’t let people and organizations be spread thin.  Focus on the highest value deliverables.  Do less, but get those priorities done faster.

These are all great practices for any company, especially a creative startup.  Lean thinking gives an organization the tools to think about opportunities and capacity in a highly dynamic, scalable way. In a downturn, nothing could be more critical or valuable.  The urgency of a downturn may, in fact, be the best opportunity to adopt changes that will pay off even more when things turn up again.

In a nasty downturn, do not ask for whom the bell tolls.  Embrace change, get lean, and make darn sure the bell does not toll for thee.

Comments (6)

Print This Post Print This Post

Email This Post Email This Post

Permalink

Close
E-mail It
Socialized through Gregarious 42