The Grass-Roots Approach

Do you want to introduce a new way to manage development projects, or any project for that matter, that focuses on the business needs rather than the process?

The prospect of trying to change the way a large organization develops software or manages large information technology projects is a daunting and discouraging one. Anyone who’s been involved in a top-down, large-scale re-engineering of IT processes bears the scars to prove what a painful experience this type of wholesale renovation can be. Agile principles might help change this reality.

You don’t need to start a cube war to leverage agile methods in a way that makes your projects more successful. You also don’t have to be an expert in agile principles to effect a substantial change in the way your organization develops software. You can learn them as you go, trying them out a principle at a time and realizing the benefits without re-engineering your world. Better yet, you can do this without asking anyone for permission or telling a soul what you are doing.

Virtually all agile software development methodologies are based on the same principles, whether that methodology is Scrum, Extreme Programming, Crystal Clear or Agile Unified Process. As a result, you can start applying some of those principles in your organization to make your projects more successful without selecting a particular methodology. Over time, others will recognize your approach as being different and effective and will want to learn more about it. When you share the agile principles with them, you will start a grass-roots effort that will spread more quickly than you might expect.

Here are a few of the principles that I have used to introduce agile software development in organizations. For a more complete list of the principles behind agile software development, check out agilemanifesto.org/principles.html.

Build and Deliver Most Valuable Features First

When planning your project, ask your business partners which features or aspects are the most important and why. Probe the business value of each feature, and make sure you understand how they affect your company’s ability to compete in the marketplace and the dependencies between them. Then suggest building and delivering a small subset of the features in an initial delivery, picking the features that deliver the most bang for the buck first. Propose only the features you can deliver in a relatively short time and talk about delivering business value early on in the project. Pick a period that will raise a few eyebrows with your business partner — if it normally takes six months to go through a project cycle, pick only enough features to take three. Then, build and deliver those features to your business partner as quickly as possible.

The most important function of a software development team is to deliver valuable software as quickly as possible. The same applies to other projects. If you can organize your projects in a way to deliver the most valuable features first, you will make your business partners happy and they will promote your approach to software development for you. Trust me, it’s a lot easier to make the sale when the holder of the purse strings has already bought in.

Communicate Face to Face

Communicating to your stakeholders, project team members, business partners and others involved in your project is always more effective when it is performed face to face. The moment you see a problem being discussed via e-mail, get the right people in the same room and talk it out. Encourage others to do the same, and avoid the practice of creating “intermediaries” between disparate groups. This unhealthy but common technique is most often seen between business stakeholders and development teams. Let your development team and business participants talk to one another; don’t try to funnel all communication between them through a single “point of contact” or insist on strictly written communication.

If you teach your project team to communicate better, they will collaborate better. They will spend less time debating ideas and more time making progress. You can improve delivery simply by asking everyone to send less e-mail and make more phone calls or in-person visits.

Let Project Teams Organize Themselves

Project teams are more flexible when they aren’t caught up in “who does what.” Don’t pigeonhole team members into particular roles just because they have a particular title. Instead, use volunteerism or take turns filling different roles. Let people shift around as the needs of the project change, and don’t insist on one person always being responsible for a particular task.

Letting the project team choose who does what, rather than having it dictated to them by a project manager, resource plan or organizational chart, will have several important benefits. First, it will be easier to deal with absences of “critical” team members if roles are rotated based on the consensus of the team. Second, it will force the project team to gel into a cohesive unit quickly. Third, it will allow the project team to adjust for unexpected workload variations without intervention from above. When one team member falls behind, the others will pitch in and help. When someone finds their plate emptied, they will look around for work they can do and do it.