Agile methods for software development are one of the hottest movements in the methodology field. Agile methods provide a means of adapting quickly for teams facing unpredictable or rapidly changing requirements. Agile introduces a structured approach to software development (more structured than most "bandwagon" enthusiasts realize). This structure ensures that the customer gets early and periodic views of their solution for continuous feedback, more assurance that they get a solution that solves their business needs, and a working solution in typically a shorter timeframe. Unfortunately, some folks think Agile is the "wild west" of methodologies and think it provides them license to throw-out all process and documentation. Those who think this are sadly mistaken and give Agile a black eye.
Agile can be very effective under certain circumstances, if people take the process seriously. Barry Boehm and Richard Turner's book, "Balancing Agility and Discipline: A Guide for the Perplexed", offer strong evidence to this effect. However, the teams will have to be appropriately structured to provide agile climate in which it can thrive and benefit the company and businesses they serve.
When viewing the Agile world, it must be recognized that there are different types of folks who are in this space. Each has different motivations. I see four groupings of people who are in the Agile space: the Champion, Work Horse, Bandwagon Enthusiast, and Deceiver. It is important to distinguish between them. In addition, people may move from one group to the next depending on how involved they get in the Agile space.
A champion knows Agile and I mean really knows Agile (e.g., creators, consultants, etc.). They make up a small, yet core, leadership in the Agile space and communicate the real meaning of what Agile is and what it means have it applied. The folks in this group are motivated to establish Agile and build upon it. They are also motivated to educate others on Agile and understand how to change cultures (e.g., a cultural change agent) to accept Agile. Companies have very embedded cultures that are typically slow to change and grasp new ideas so an Agile leader must have the ability to make culture change occur in an adoptable manner. In relation to culture change and adoption, Agile leaders need to:
- Make it very clear in what conditions Agile will work and avoid having folks say that it will work on any project. Communicate where there are challenges and share new ideas in the Agile space. There are some good resources for this including (but not limited too):
- Agile Journal - see http://www.agilejournal.com/
- Agile Advice - see http://www.agileadvice.com/
- Agile Wikipedia - see
- Be able to generate both buy-in to initiate a new Agile culture (usually in pockets within the company) and understand the notions of culture change. Positive cultural change involves understanding enough about the values and beliefs of the leaders of a company in order to improve performance. This requires analysis of the company culture, an ability to understand change patterns within a culture, and the ability to negotiate and facilitate change.
- Avoid condemning other methodologies. An example is the "Waterfall Conference" (see: http://www.waterfall2006.com/ ) which spoofs the waterfall methodology. While I find this funny because I have witnessed problems with using waterfall, many do not. Yes, I know we are a small group and get bashed ourselves because some people see Agile as a fad or a threat to another way of doing business. However, reverse bashing (even if in jest) only creates contempt and may impact acceptance.
The work horse has learned about Agile by trying to implement it on their own or with some help from others. They understand the structure that Agile needs to thrive, by either being bitten once already or by fully understanding the environment needed for Agile. These may be folks in the trenches who really understand the challenges of implementing Agile because their merit or bonus is tied to their success. This group cannot afford to be idealists, but are realists that learn the hard way when a new Agile culture collides with current company culture. They learn the importance of facilitating change and adapting. A lot can be learned from this group.
The bandwagon enthusiast sees benefit in jumping on the Agile train. Fads and trends rule the day so if Agile is "hot", then there will be folks who pretend to be enthusiasts. They "throw around" Agile terminology to give the appearance of knowing the field. The danger is that they pretend to know Agile well while not really understanding it and what it needs to thrive. Therefore inaccurate information is often disseminated without any bad intend (but it is incorrect information all the same). Some bandwagon enthusiasts will see the value of Agile and will become Agile work horses or champions - most will not.
The deceiver sees the Agile trend as an opportunity to abandon processes and documentation so that they can enjoy the wild west life. When reviewing the Agile Manifesto (see http://agilemanifesto.org/ ), they interpret the word "over" as "in place of". These are individuals are smart enough to know that many do not understand Agile. They deliberately twist the true intent of the manifesto. For example when the Agile Manifesto says:
- "Individuals and interactions over processes and tools"
Deceivers will re-interpreted it as
- "Individuals and interactions in place of processes and tools".
Agile values process, tools, documentation, negotiation, and planning. However, these concepts are viewed differently in the Agile world. Deceivers are the most dangerous because they undermine and obstruct the potential success that Agile may bring to an organization.
The Agile structure is typically not easily inserted into hierarchical company cultures. In making the shift toward Agile, important cultural adjustments must be considered. Included are some of the more important considerations (but not limited too):
Team Collaboration: Folks on a project team employing Agile need be dedicated to that project team. They will be working together all of the time. They cannot be multi-tasking between two or more projects. This promotes continuous collaboration that is a cornerstone to Agile methods for software development.
Team Location: In order to have collaboration, it is best that folks are working as closely together as possible. Many project teams employing Agile have dedicated and centralized work areas. Proximity promotes participation and collaboration.
Customer Participation: Project teams employing Agile must have easy and continuous access to the customer or customer representatives. This means getting significant time commitments from the customer. This can be quite challenging. The whole point of employing Agile is so the customer can get a continuous view of the evolving solution so they can adjust quickly to clarifications and new business demands.
Terminology: Companies have their standard terminology for methodology, reporting, and hierarchy. Agile introduces new terminology, methodology, reporting, and team structure. This requires some adjustment.
Project Reporting: It is important to note that reporting is different from standard company reporting. Most traditional companies ask for a Gantt chart to assess a project's progress. Agile teams typically provide Burn-down charts.
Embracing Change: The ability to truly respond to change while achieving goals is at the heart of a successful Agile operation. As an iteration is completed, customer changes should be welcome because this means that we are getting closer to what the customer wants. It can be difficult to accommodate change because we all want to know what is coming next so we can plan accordingly.
When listening to people talk about Agile, try to understand their point of view. What is their Agile persona (e.g., Innovator, Champion, Bandwagon Enthusiast, or Deceiver)? Do they understand what they are saying? Deceivers will purposefully send the wrong message using this as an opportunity to throw out all processes and documentation. Most bandwagon enthusiasts are involved because it is "hot" but not really invested in the method discarding it when the next "hot" thing comes along. Work horses will have in-depth working experience and will speak the hard truths about Agile, with the benefits and the warts. Champions are very pro-Agile advancing the cause and state of the practice. While employing Agile implies a cultural shift, the Agile community must continue to communicate the strengths and weaknesses. While no solution is a silver bullet, Agile can provide a nice silver lining for certain types of projects in the software development field.
References & Resources
- "Extreme Programming Explained: Embrace Change (2nd Edition)", Kent Beck and Cynthia Andres, 2004, Addison-Wesley Professional
- "Balancing Agility and Discipline: A Guide for the Perplexed", Barry Boehm and Richard Turner, 2003, Addison-Wesley Professional
- Agile Software Configuration Management (SCM) - Brad Appleton, Steve Berczuk, Robert Cowham
- Martin Fowler's article entitled, "The New Methodology" (see: http://www.martinfowler.com/articles/newMethodology.html
- Agile Manifesto - see: http://agilemanifesto.org/
- Agile Advice - see http://www.agileadvice.com/
- Agile Wikipedia - see http://en.wikipedia.org/wiki/Agile_software_development