Why Duplicating Effort on Software Projects Could be a Good Thing

So one thing I never hear software people complaining about would be "We have too many people and too much money for this project."

In fact, this situation actually occurs more than you would think in venture funded companies. Once a small startup gets an infusion of cash, the expectation is that they will build out their services to a larger scale, hire more employees to do that, and become a huge success or die trying.

But as we think about the constraints of resources, time, and scope, what is the Agile approach when time and scope are fixed, but resources are not? What should a newly funded startup do to maximize their chances of success over a fixed timeframe?

One option that is rarely talked about (and I admit, possibly because it's not such a good idea) is to run parallel development efforts. This would mean duplicating effort, but also getting a couple of chances to innovate and create a better product.

For example, if you set out to build the next great social networking platform, how can you make it better, cooler, and more compelling? Possibly by creating two or even more teams within your company, and having them try different approaches.

Sound like madness? Maybe, but here are some possible benefits:

1. You'll probably get good ideas from one team that the other didn't think of
2. You'll probably get a better *implementation* of the same idea from one team than the others
3. With more teams, the chances of one coming up with a breakthrough idea is much higher.
4. There's nothing like a little healthy competition to get some serious productivity, creativity, and execution rolling. It's a powerful motivator.
5. You'll get the opportunity to use pieces from each team's effort to make an exponentially better product (not necessarily the code, but certainly the design concepts).

In a sense, this happened at Microsoft back in the 90s when Windows 95 was being created at the same time as Windows NT. The teams liberally "borrowed" ideas from each other, and both products wound up better off as a result.

There are some obvious challenges to this kind of approach - namely what to do with "losing" teams, and the effect of competition on company culture and harmony. But even applied in the small, this approach could have an impact.

Imagine if you applied this concept to specific features rather than a whole product. Maybe take just a week, and have 2 or 3 pairs or individuals flesh out ideas on the feature, then see how it plays out.

I can't imagine this would work in all kinds of situations, but in a venture funded startup looking to become the next big thing, it might be the simplest thing that could possibly work when resources are plentiful.

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Agile Project Collaboration and Restaurants

The software development world keeps trying to come up with good metaphors for what a software project is like. "It's like building a bridge", some say, or "Like manufacturing a car", others say.

I think a much better analogy, especially for the dynamic between the customer and the development team, is ordering food at a restaurant.

As a customer, you know what kind of food you like, how hungry you are, and you might have something in mind to impress your date, whether it's your wife, a client, or your boss.

As a chef, you know what makes food taste good, what the best way to combine ingredients is, how quickly your staff can make a certain meal, what foods are freshest, and how much things cost to get.

Naturally, as restaurant customers, we tend to order what's on the menu, which the chef has thoughfully specified in advance. This would be analagous to certain types of systems that a software team has written before, or are available as an off-the-shelf component (e.g. a blog, user forum, poll, etc.).

If some software customers used the same approach in a restaurant as they did in trying to get systems developed, the converstation might go like this:

Customer: I'd like some chicken, but it needs to be the size of a turkey, and I want it to taste like beef. Don't make it too salty, and it should cost less than a can of tuna. Oh, and can that be cooked in 3 minutes?

Chef: Well, the largest chickens known to man are slightly smaller than a turkey, we could get you that, but they don't taste like beef. We could add some beef sauce, but it won't taste very good. Extra-large chickens cost double what normal chickens do, and take at least 20 minutes to bake. I guess we could chop it into tiny pieces and deep fry it in 3 minutes, but it won't look or taste good. Sorry, but it will cost you about 10 dollars for this, a can of tuna is 60 cents.

Customer: You incompetent fool! If you can't handle this, I'll find a chef who can! My 12-year old nephew cooks all the time, and he can make eggs in 3 minutes flat, and they're really cheap, too. A chicken is just a grown-up egg, right? Why can't you do better than my nephew with all of your experience and training? Are you trying to cheat me???

Sound familiar?

Now this might seem silly in a conversation about food, surely a chef knows more about how to best prepare something that we might like. A more typical request in a "made to order" restaurant might be:

Customer: I really like chicken, but not spicy or with heavy sauce. And I'm watching my health, so too much grease or salt is a problem. Can you make me something tasty?

Chef: Of course: I could make a fresh tomato and spinach pesto chicken with boneless, skinless chicken breast with a fabulous balsamic reduction that just hits the spot.

So what's the problem in software? Is it really that hard to express requirements and constraints, and to let the experts suggest options and approaches?

The main issue as I see it is a question of trust. In a restaurant, you'll know in about 20 minutes if the chef understands your needs and can deliver something tasty. If it works out, you'll gain trust, and certainly you'll want to order from him again.

In traditional software, it can take a lot longer than 20 minutes, or even 20 weeks to see the first results. If the outcome isn't pretty close to what you talked about, trust goes down, fear goes up, and you wind up with some serious issues.

Agile software approaches to project planning and collaboration operate more like the restaurant. Order something, try it, maybe ask for less salt or more cream next time, and repeat.

Before long, you'll develop a great rapport between development team and customer, and you can start talking about what's for dessert.

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Agile Project Management: What's In It For The Customers?

One question I'm asked frequently is how Agile project management is different from traditional project management.

Normally I start talking about iterations, planning, user stories, and the like, but I get a decent number of blank stares in response.

I like to think I'm pretty good at explaining things, so I tried to figure out what was missing from my description. Is it the terminology? Do I need more examples? Is this something that non-techies just can't comprehend?

Then it hit me - like all other concepts, products, or services, Agile project management needs to be explained in terms of it's benefits, not it's attributes. The real question people were asking me was "How will this benefit me?", not "How does it work?"

So without further ado, here are the benefits of Agile project management for software teams in customer terms:

1. More Requirements Flexibility (Ability to Undo Screw ups) - because of the quick development cycles that produce working software, an agile approach keeps mistakes shallow, and let's you correct your mistakes or in company political terminology "refine your solution".

2. Reduced Project Risk (No Need to Explain Lengthy Delays and Cost Overruns) - because of the frequent planning and estimating sessions (at least once per month), you'll know very quickly if the project is off schedule, and you'll have control over what to do to get it back on. This leads to better predictability, less embarrassment, and happier stakeholders.

3. Transparent Project Management (Trust, But Verify) - having visibility into which features (stories) are being worked on, and being able to actually use the software after each iteration means that you can verify progress instead of relying on a set of lines on a Gantt chart. This helps with both internal teams and outside consultants.

4. Early Delivery of Value (Can I Have That Now?) - because Agile projects deliver the most important things first, you can decide to deploy a system much earlier than planned if business circumstances dictate that. Sometimes there is enough value in the top 10 features that the remaining 100 can wait. And delivering value is sort of the point of most of our jobs, after all.

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

The High Cost of Management Indecision

Rob Walling writes about the high cost of management indecision on software projects.

Essentially, the argument is that even wrong decisions allow developers to keep momentum and push a project forward. The cost of reworking areas winds up being less than the cost of delaying, doing nothing, or switching to other tasks. Here's an excerpt about the cost for a team of 10 developers:

If we decide not to make any decisions we lose 10 times $822, for a total of $8,220 per week. Let me say that again: blanket indecision loses $8,220 per week; making decisions (including bad ones) loses $1,680 per week. That's a difference of $6,540 per week.

It's actually a pretty powerful argument for doing everything possible to lower the perceived cost of making a decision for managers or customers. Perceived cost is that fear-driven idea that if you make a certain decision, you'll be stuck with the results forever if it doesn't work out, due to the high cost of changing it.

This is exactly the problem that Agile methods were designed to solve. By reducing the perceived cost, we encourage our customers to make more timely decisions, learn from them, and adjust as needed without incurring high costs.

Of course, this doesn't necessarily apply to technical decision making. "Should I use a database or direct file storage?" is a question that doesn't need a final answer right now. The right question for technical decision points is "How can I encapsulate that?" That lets developers move forward while keeping the cost of future change low.

If it truly does cost more to delay management decisions, wouldn't it be wonderfully freeing to start making some?

Even if you don't have all the possible information you'd like?

Even if you could be wrong?

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Agile Variations for Distributed Software Teams

So you've read the latest article or book on Agile methods, and go forth eagerly to implement them in your organization.

One little problem: your team is distributed, but all of the books you've read mention something about "co-location". That's another word for "together", meaning everyone on the project is in the same place: customers, developers, product owners, testers, documenters, and even those guys who make boxes to put software in if you like that sort of thing.

What's an aspiring Agilist to do when the team isn't together?

First off, let's define "not together". There are three main types of distributed teams, each with its own unique challenges:

1. Type A: All developers are together, all customers are remote
2. Type B: Multiple development teams in different locations (but each team is together)
3. Type C: "Virtual" team where nearly everyone works remotely (e.g. from home, in various offices, etc.)

OK, now that we understand the different types, let's look at the challenges each one has, and how we can tackle them.

Type A projects (all developers together, remote customer) generally have to be aware of getting out of touch with the customer. Out of sight can mean out of mind. This is especially true on an outsourced project, where the customer might only be interested in talking once a month or so.

The biggest risk for Type A projects is that the team starts making major decisions without input from the customer, which can lead to software that is not aligned with the customer's needs. Going back to basic Agile principles, we decide that freqeuent communication is the best way to deal with this. A daily meeting to quickly disucss progress, obstacles, and goals for the day might be just the ticket.

But having a daily call might not be enough. How do we handle those little decisions that need to be made all day long? If you're building a blogging system and the customer asks for a way to schedule new posts for the future, did they want them to autopublish or just have a reminder sent? A remote team might build in support for both, just in case. An Agile team needs to ask the question, and only build what is needed for now, not waste the customer's money on a guess. So alternative communications channels become important. Instant messaging clients, email, and message boards can be good informal channels for extra communication throughout the day if phone calls aren't feasible.

On to Type B projects (multiple dev teams in different locations). Here, the main issue is that each team may be highly functionial, but may have trouble communicating well with the other development teams. An example would be an in house IT team working with an outsource vendor. Again, frequent communication is important, as with Type A projects, but there is usually something very simple that can dramatically improve working relationships. Ready for it?

Type B teams should all meet in person at the beginning of the project. As in physical proximity, having a beer or soda together, chatting about hobbies, technology, or which breed of cat is superior.

Why is a face to face so important? Without it, human nature drives us to an "us versus them" mentality, also known as "those guys in Nebraska screwed up again" (I have no direct knowledge of any Nebraskan development disasters, this is just an example.)

Type B teams should also consider rotating a member of each team to spend time with another team on a monthly basis. Cross-pollination doesn't just work for bees, it can improve human endeavors as well.

On to Type C teams - the new "virtual workforce" we've been hearing about. Unlike the first two types, these folks never see anybody. This turns out to be strangely beneficial. Because everyone is on the same level, these individuals are either lonely and isolated, or pretty happy with their arrangement. We can influence the outcome towards the latter by setting up frequent communication and having an initial in-person meeting as with the first two types. Virtual teams can suffer from poor quality of communication though, and may need to supplement with group collaboration tools like shared whiteboards to supplement daily calls, emails, IM, etc.

For Agile afficionados enamored with pair programming (developers working on a task together), it's possible to setup virtual desktop and keyboard sharing (using VNC or similar software) along with an Internet phone line (e.g. Skype) to do this. Some folks acutally prefer the physical separation so that the after-effects of Joe's garlic pizza binge from the night before aren't quite so...awakening.

Having a "virtual water cooler" like a chat room can also help provide informal channels for team cohesion and bonding that can make a big difference in the final outcome of a project.

Overall, distributed teams aren't an ideal way to work, but given their reality, we can apply Agile principles to work effectively. Perhaps not as effectively as with a co-located team, but isn't the goal to do the best we can with what we've got?

How's your distributed team bridging the gap?

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams