David's Tech Blog

Recent work changes have led me to think more intensely about development methodologies, project management for small teams, and similar issues, and I’ve been reading more about Agile development. I am much more interested in the philosophical underpinnings, the values of Agile, the overall approach of Agile development, than I am in the specific practices that make up a particular “official” methodology such as XP or Scrum. So I was interested to see Brian Marick’s post on his Exploration Through Example blog entitled “What is Agile? — beats me, but I know it when I see it“.

To me at my current stage of thinking, the most important components of Agile development include:

• short release cycles with working software to the customer as often as practical
• safety, trust and openness in the development team
• frequent (almost constant) and informal interaction between members of the team
• open communication between the user and the developers
• transparency and visibility of information
• focus on solving the business issues
• adaptability
• emphasis on the practical over the ideal, but always pushing for incrementally better
• an attitude that fosters creative solutions, dedication to solving real problems, and ownership of the problems, process and solutions

I think that the Agile manifesto wraps a lot of this up. It embraces the following values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Reponding to change over following a plan

Agile processes focus on adapting to real needs, rather than trying to predict them and then sticking to the predictions regardless of how accurate they turn out to be. They focus on meeting the needs of people over the needs of the development process itself.

There is a lot in the various methodologies that is good, but to me the philosophy for development espoused by these ideas is what its about. Methodologies need to adapt to the situation, just as other components of planning and process must.

Most of the information I have come across in the “formal” Agile methodologies completely overlook or dismiss distributed teams. This is just not well connected to the real world. Instead of dismissing those of us who live in distributed teams (and the numbers are growing), we need ideas about how to reach the goals of Agile development in the reality we live in. That mostly means finding ways to work closely together, to have transparency, code review, collaborative approaches to working and coding, and high levels of interaction and trust in teams that might be physically together only rarely.

For me, the biggest component to success over the long term in development projects is in the relationships–in trust and open communication–between the members of the development team, between the developers and users and customers, and between the development team and management. If those are missing, things can quickly fall apart.  Building and maintaining these in distributed teams, and when the team is not local to the customer, is challenging.  The real world many of us live and work in day to day, the team, the boss, and the customer might be literally an ocean away.  In this world the values of Agile development that I outlined above hold just as true.  Its just the charts scribbled on paper, pair programming on one computer, and in person stand up meetings that do not.