Posts Tagged ‘Agile’

Most agile practitioners have heard about the importance of having your scrum teams in a shared, co-located space. The team collaboration and high-level of communication that co-location provides is a large success factor for agile projects. But what if you live in the real world and your team is geographically distributed. Although it certainly poses unique challenges, you can still provide your team with a collaborative experience by implementing some simple practices.

The Tele-Window

If you have the bandwidth for it, I highly recommend setting up a high quality webcam conferencing solution to provide a window into each location’s department. This should provide ample face-time with your team members and provide a great venue for impromptu meetings. You can glance over at the “window” and see if team members are chatting. You can chime in or they can call out to you when they see you back at your desk. This window also comes in handy for the next tip, the roll-away scrum board.

Roll-away Scrum Boards

Depending on how many scrum teams you have, you can roll scrum boards within the viewport of your tele-window just before the daily standup for that project. At the end of the daily standup, you can take a screenshot of the scrum board and post it on a team wiki or other web-based tool.

Virtual Pair-Programming

As a big advocate of XP practices, I cannot overstate how important it is to have at least some pair-programming sessions with other team members.  Although difficult, it is possible to have a decent pair-programming session with geographically distributed team members.  If you’re on a Mac, you can use iChat to share the screen with your partner.  Make sure you’ve got some voice communication so you can decide who is driving and when.  Two people moving the mouse in all different directions simultaneouly is rather annoying.  On Windows, you can use the Windows Remote Assistance, Microsoft SharedView or download a third-party tool.

The most important factor to ensure success of your agile development projects in communication with your team members. When your team is geographically distributed you’ll find challenges in your execution. Make sure to be innovative and use the technology available to you in order to foster high levels of collaboration.

One of the most popular formats for writing agile user stories follows this template:

As a [role], I want to [feature] so that [goal]

Many organizations translate this into a spreadsheet where each column represents a different field the story writer can fill in:

I have used this template on almost every agile project I have participated in.  For the most part, it works very well. It typically provides a great launch point for additional discussions before it makes it into a sprint.

One of the most common mistakes I see when introducing the template (and agile stories in general) to a new team is a tendency to define every role as just a generic “user”. For example, I’ve seen user stories as generic as:

“As a user, I want to upload photos to a library so that I can use them on a post”

Although its syntactically correct, it is vital that we define a role and not a “seat” on the system. A more valuable user story would look like this:

“As a user designer content author, I want to upload photos to a library so that I can use them on a post”

Notice how this story now has a better context of who will be using the feature and how. This could provide valuable insight into the intended audience and how best to implement the feature — a designer may imply more advanced features while a content author would use the image as is.

Always avoid the generic “user” role in your user stories.

Hope this helps.

I recently read a Gartner research report about the changing space of software development methodologies and the PMO. It compared the PMO to an air traffic controller coordinating flights (ie projects) – scheduling them, coordinating resources for them etc. While this might be a valid comparison, I think the changing face of software development is leaning towards taking road trips as oppose to long flights.

The air traffic controller analogy is good but if the distance is short, sometimes driving a car is faster. I think if our aim as software development managers shifts to focus on delivering small chunks of functionality more often, we don’t necessarily need all the planning & scheduling that an international flight requires. Driving to a close destination within 100 miles or so is often faster than the airport parking, luggage check-in, security screening, boarding, possible flight delays, weather conditions etc (not to mention the high upfront cost of a flight). For short distances, driving a car is often the optimal choice.

For farther destinations, say from Miami to Seattle, a flight would definitely win over a drive with no stops. However, if we think of a Seattle as being the final destination, but having several stops along the way, it becomes akin to a road trip. Each stop in a different town adds value to the overall expedition. Everyone is enjoying the progress of the trip because they’re getting value out of each stop along the way. The car will need refueling (capital) along the way, but its a smaller cost than filling the plane with 50,000 gallons of jet fuel before takeoff. The analogy here is the benefit of high business value from fast, incremental delivery of application features.

Also, a flight requires coordination from several disparate and highly specialized teams (engineers, pilots, stewards, traffic controllers, etc). In the car analogy, the team is much more close-knit and cross-functional. Anyone can drive, a couple know how to drive as well as change a flat, someone knows how to change the oil as well as fix a flat – they don’t need to “borrow” someone from another project to change a flat. Everyone on this cross-functional team is committed to the success of the road trip whereas flight teams work on multiple flights (projects) all the time and need to be coordinated and assigned accordingly.

Without a doubt, coordination and management is necessary with any software development project.  However, the scale can change dramatically depending on how far you want to look ahead.  It also gives us more options to get around detours along the way.