Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Wednesday, November 16, 2005

Agile Project Management for Distributed Teams

There seems to be a growing trend towards distributed teams. Developers work at one location, and customers do business at another. Or testers are outsourced, working with developers and customers in another timezone. Sometimes even the development team is virtual, with different team members working remotely.

Whether this will continue or not remains to be seen, but with the strong focus on people and communication that Agile techniques encourage, dealing with remote teams can create a bit of a challenge.

So what works well for distributed teams in an Agile setting? Can you use index cards, whiteboards, and big visible charts to communicate? What about daily standup meetings?

In my own experience trying to use agile methods in this kind of environment, a few tweaks were in order. Here are a few things that worked for me:

  • We needed a little more documentation than when the team was co-located. Functional specifications are a little more important when the customer is 3000 miles away. These can be as simple as a few screenshots or drawings with some commentary, and should be easy to read and understand. It's just a way to capture and remember the collective understanding of the team when you can't ask questions in real time.
  • We used a web-based planning tool to collaborate and provide visibility into project status across time zones and physical locations. Index cards are fine for teams in the same office space, but unless you're going to FedEx them back and forth, you'll need another way to share and update project information like user stories, detailed tasks and estimates, and other project artifacts. Customers can check in when they have a chance, if they want to see where their pet feature stands.
  • If you can't coordinate daily meetings due to scheduling or timezone issues, try at least a weekly update meeting, possibly using a Web conferencing software package like WebEx if you want to demonstrate features or do a walkthrough. In my experience, as much as we tried to involve remote customers by sending them draft documents or prototype software, the best results and feedback came from live walkthroughs of software, or even of documents for discussion.
  • Travel. There's nothing like face to face conversation, even if it's only once a quarter or twice a year. Plan for it, budget it, and do it. It's sometimes the difference between a distributed team, and a wide-area disaster.

If nothing else, Agile techniques are about adapting to change, even for the process itself. Distributed teams need a few more tools in the toolbox to work with Agile processes, but the same philosophies of rapid feedback, people over process, and close communication can still be practiced.

I'd love to hear about other experiences with distributed Agile teams, drop me a line (dave at extremeplanner dot com) or leave a comment.

For more on agile tools and techniques: http://www.extremeplanner.com

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

Tuesday, November 08, 2005

Organics and Mechanics in Agile Development

Do XP and other agile methods appeal to some people because of their organic nature? And do others mistrust or actively denounce these methods for the same reason?

I recently read an article from Rands In Repose, titled Organics and Mechanics. A fun read, which to summarize, says that Organics are more intuitive people who gather information somewhat chaotically (at least to outside observers), and are more focused on the big picture than the pixels. Mechanics, by contrast, prefer to understand how things are structured down to the bits, and will ask detailed questions until they get this understanding. Organics and mechanics, therefore, are constantly annoyed by one another.

To apply this to software processes, I think one of the draws of XP is it's emphasis on people. Ideas like "40 hour work week", "pair with others", "close communication", "onsite customer", etc. have strong pull for those with the need to feel connected to the people on a project, not just analyze bits and bytes.

As an admitted Organic with traces of Mechanic, I see software development as a creative endeavor intended to solve people's problems. However, this process also needs some structure applied to make it consistent and reliable, key attributes when you need to deliver to customers. Agile methods allow the creativity, personal contact, and focus on communications that us Organics love, but also applies rigor in the form of prescribed practices.

XP, for example, insists on adhering to the disciplines of fixed iteration timeframes, merciless refactoring, test-driven development, and maybe most important, not working on things that have not been prioritized and approved.

So these practices, along with project tracking and metrics, can satisfy the Mechanics need for hard numbers. What are the detailed tasks for this story? Where are the unit tests for this feature? How many running, tested features have been completed? What work is remaining, and how likely are we to finish it?

The ideal development team has a blend of both Organic and Mechanic mindsets. This captures both the big picture and vision, as well as the small details that need to be worked out before you can deliver useful, reliable software with consistency.

So why is this so hard? Too often, Organics are drawn to only the Organic parts of agile methods. The warm, fuzzy communication, the daily customer contact, the pair programming, the rapid feedback are all like honey-flavored butter on Organic bread. The lure of running a project in the Organic way, without all of those annoying rules can seduce a team into forgetting that there is freedom in discipline.

Similary, a Mechanic-heavy team can forget that they are building software for people, and fall prey to over-analysis and over-engineering of solutions. They often say things like "Well, it's more in keeping with my architecture to build it this way, even though it's not really what the customer wanted."

Detractors of agile methods correctly criticize pure Organic implementations of agile methods for their lack of rigor and discipline, and call it "code and fix" development. When correctly applied, Agile methods have both Organic and Mechanic side in balance. Ying and yang. Dogs and cats playing together in harmony.

What are some telltalte signs of inbalance? You'll hear a lot of noise about "lack of visibility". Or maybe something about how people aren't working hard enough. These are very dangerous signs. It means that the Mechanics on the team aren't getting what they need. If you're customers are Mechanics, this could spell doom for project. Same applies to your boss, CEO, or investors.

So let balance be your guide to running an agile project. To Organics, try to think like a Mechanic every now and then. Get a little structure going. Measure your progress once in a while.

And Mechanics, get out of the details and meet your customers. Understand your business better. Maybe even add some pizazz to your software.

How can you tell if your Agile team is balanced? It's pretty simple really. Both the development team and the customers will be happy. Not just for a month or two, but over a sustained time period. You could even put up a "happy meter" on your wall (to keep the Mechanics happy). But make it attractive and maybe a little abstract for the Organics among you.


For more on agile tools and techniques: http://www.extremeplanner.com

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

Thursday, November 03, 2005

Are your projects succeeding by accident?

If you dance around in the morning, and that evening it starts raining, does that mean that you executed a perfect rain dance? Or do they have nothing to do with each other?

One of two things is certainly true: Either your dancing had some effect on the eventual outcome, or it did not. You may not know which, but if you did, wouldn't it help inform future behavior during a drought?

And so it goes with software projects. Overzealous managers hear about a big successful project, and then attempt to duplicate that success by imitating it.

"Ah", they say, "Project MegaCost used the new BURP (Big Unproven Reactionary Process) methodology and it was wildly successful! We have to use that also!"

And so imitation replaces coherent thought, and reason is stifled by restrictive rules.

"We must create an Analysis Breakdown Diagram that traces to the Object-oriented requirements Statechart," says the project lead.

"But why exactly do we need that?" you ask. Seconds later, an army of BURP consultants storms the room.

"You must be educated", they say. "You just don't understand, you're stuck in the traditional mindset of getting things done efficiently. BURP will free your mind, and let you predictably reach your goals, or at least appear to be doing so in each phase."

Needless to say, the project is months behind schedule, although a nice stack of documents is piling up, and each of them traces back nicely to the requirements. Except, of course, that the requirements have sort of changed since last year when you were capturing them. Time to update all of those documents and trace matrices!

The CIO blames the BURP consultants, who retort that the company isn't correctly implementing BURP, and are missing several essential Use Case Dependency Matrix Flowcharts. Hilarity ensues.

"But why didn't BURP work here?", complains the CIO. "It worked for Project MegaCost!" And then it dawns on him...maybe that project succeeded for other reasons. Maybe it was even the...gasp...choke...PEOPLE!

Software projects are all different, due to the nature of software itself. It's a little different for each context and application, even if the domain is similar. And this kind of variation needs a mindset of adaptation. Keep things simple, and be ready to adjust as you get new information.

Success breeds complacency, so a successful project team needs to be on the alert for the next danger lurking around the bend. Even if an approach worked wonderfully in a certain context, chances are a different circumstance may require adjustments to that approach, not blind adherence to a method.

So the next time you make it rain, ask yourself if it's the dance you did, or if you just live in Seattle.


For more on agile project management: http://www.extremeplanner.com

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