ASD is a set of principles and practices that allow you to build reliable software systems cheaper and faster than you would using more traditional approaches. The main characteristics of ASD include: incremental and iterative development, heavy customer involvement, and minimal overhead. At the end of the day, using agile methods significantly enhances your chances of building the right product for your customer.
How does it work?
A short cycle of "plan->build->get feedback" repeats over the course of the project until the customer is satisfied that they have received a product they like and deem useful and reliable.
 |
| http://www.mountaingoatsoftware.com/scrum/overview |
Is the notion of incremental/iterative development new?
No. Incremental/iterative development has been around for a long time (~ 1950s).
Then, how is ASD different?
ASD contributed significantly to promoting iterative development and making it work by incorporating a number of principles and practices that emphasize discipline, efficiency and business-value. Anecdotal evidence suggests a considerable increase in the project success rate compared to older approaches. Before ASD, iterative development had major issues such as:
- heavy up-front work (e.g. planning, requirement elicitation, design),
- lengthy iterations (e.g. up to years as in the spiral model),
- considerable overhead (e.g. documentation, processes, modelling).
- Up-front work is minimal. Because at the beginning of the project, we know the least about what we are going to build. Any attempt to pretend to know the requirements at that point is a gamble at its best. Making major decisions at this point is a risk with expensive consequences later in the process. Therefore, in ASD decisions on requirements and design are delayed until the last possible moment.
- Iterations are short. They range anywhere between one week to four weeks. Experts recommend two- to three-week iterations. This gives the team a chance to change course or mitigate risks in due time. It is also a very effective mechanism to get feedback from the customer on a regular basis. Moreover, having a short time-boxed iteration forces the team to think about a measurable deliverable (i.e. working system) with a clear increment to the previous deliverable.
- Anything that does not evidently provide business-value is considered useless overhead. Therefore, practices like documentation and modelling are only done on-demand.
Does ASD lack in planning?
Not at all. If anything, ASD does planning really well. There are three levels of planning: release planning, iteration planning, and daily planning. The beauty of this approach is that you always give your team the chance to adjust based on new information. If you fail, you fail early enough to be able to pick yourself up and continue.
Aren't daily meetings a waste of time?
No. When done right, daily meetings (aka. scrums or stand-up meetings) are a very efficient way to collect feedback about the previous day, and plan more work for the coming day. It should not take a team member more than 1 minute to tell the team: what they did the day before, what they are planning to do in the coming day, and what problems/obstacles they need help with.
In traditional approaches, it is extremely easy for someone to take a free ride for a long time until the team eventually realizes that these team members are not contributing anything! In ASD, daily updates prevents this from happening or at least exposes people who attempt to play such games. Having said that, it is important to point out that doing daily scrums does not make you Agile (as some managers seem to think). It is only one key part of a larger framework.
Is it true that Agile teams produce no documentation/design artifacts?
No. Almost every team will need to produce some kind of an artifact that might reflect the system architecture, the DB schema, the object model ... etc. What Agile teams do not do though is produce lengthy requirement documents that no one reads. If detailed documentation is necessary for accreditation/regulation/safety purposes, there is no question that it will be done as required. Agile teams also do not produce low level design artifacts unless they are really necessary for the reasons mentioned before. The key issue with artifacts is not actually producing them but keeping them up-to-date. An outdated requirement or design artifact might actually be more harmful than no artifacts at all.
Is Agile only appropriate for small enterprises and start-ups?
While ASD is especially good for small enterprises and start-up businesses, ASD has also been successfully practiced in major IT corporations such as IBM, Google, and Microsoft. Having said that, it is important to note that scaling agile methods continues to be a challenge. If you decide to use agile methods in a large organization, it is strongly recommended that you seek some serious consultation to solve possible inefficiencies (e.g. large and long planning meetings, communication with outsourced teams, design sessions ... etc). Even if you work in a small-to-medium organization, you may need to consult experts on how to overcome other adoption barriers such as the impeding culture of traditional development and the resistance of middle and upper management.
Everyone claims they're Agile. How would I know?
There are many different Agile methods and practices out there, and there are many different opinions as to what the minimum requirements are for agility. Generally speaking, you should expect Agile teams to maintain the following as a minimum:
ASD in general does not support the idea of a complete separation of testing and development. In that sense, some QA roles might be eliminated in an effective Agile team. Nonetheless, the absence of the role does not mean the job itself is not accomplished. Every developer is responsible for producing automated tests that prove the correctness of their code (as in test-driven development). As a QA, if you're doing something that can be done using an automation tool, then you may want to rethink your career. Nonetheless, many teams will still need security testers, usability testers, performance testers ... etc. In an Agile culture, these testers need to be well integrated into the team if at all possible.
Why is it that developers have to sit in an open environment not in their own private work spaces/offices?
After decades of building software - and often failing miserably at it - we have come to learn that communication is key to the success of any software development process. Placing team members in offices or closed cubicles has been found to be an inhibitor to effective communication. Team members find it easier to use emails or documents to communicate their questions or ideas or concerns compared to traveling between offices and floors to have a face-to-face conversation.
By seating everyone in an open space, however, communication becomes significantly easier. Synchronous communication starts to occur in a very smooth and casual manner. A phenomenon known as osmotic communication starts to happen as people overhear conversations that would eventually affect their tasks in a way or another. If a build has failed, everyone on the team knows. If the customer is entertaining some thoughts about a change in the course of the project, everyone is aware of that. No secrets. No hidden agendas. And no forgotten reports, ignored emails or delayed responses.
Needless to say, if the Agile team is distributed, then communication becomes an issue that needs to be addressed.
What is the state of ASD today?
I strongly recommend that you read the State of Agile Development Survey Results (6,042 responses).
Where can I get more information?
Not at all. If anything, ASD does planning really well. There are three levels of planning: release planning, iteration planning, and daily planning. The beauty of this approach is that you always give your team the chance to adjust based on new information. If you fail, you fail early enough to be able to pick yourself up and continue.
Aren't daily meetings a waste of time?
No. When done right, daily meetings (aka. scrums or stand-up meetings) are a very efficient way to collect feedback about the previous day, and plan more work for the coming day. It should not take a team member more than 1 minute to tell the team: what they did the day before, what they are planning to do in the coming day, and what problems/obstacles they need help with.
In traditional approaches, it is extremely easy for someone to take a free ride for a long time until the team eventually realizes that these team members are not contributing anything! In ASD, daily updates prevents this from happening or at least exposes people who attempt to play such games. Having said that, it is important to point out that doing daily scrums does not make you Agile (as some managers seem to think). It is only one key part of a larger framework.
Is it true that Agile teams produce no documentation/design artifacts?
No. Almost every team will need to produce some kind of an artifact that might reflect the system architecture, the DB schema, the object model ... etc. What Agile teams do not do though is produce lengthy requirement documents that no one reads. If detailed documentation is necessary for accreditation/regulation/safety purposes, there is no question that it will be done as required. Agile teams also do not produce low level design artifacts unless they are really necessary for the reasons mentioned before. The key issue with artifacts is not actually producing them but keeping them up-to-date. An outdated requirement or design artifact might actually be more harmful than no artifacts at all.
Is Agile only appropriate for small enterprises and start-ups?
While ASD is especially good for small enterprises and start-up businesses, ASD has also been successfully practiced in major IT corporations such as IBM, Google, and Microsoft. Having said that, it is important to note that scaling agile methods continues to be a challenge. If you decide to use agile methods in a large organization, it is strongly recommended that you seek some serious consultation to solve possible inefficiencies (e.g. large and long planning meetings, communication with outsourced teams, design sessions ... etc). Even if you work in a small-to-medium organization, you may need to consult experts on how to overcome other adoption barriers such as the impeding culture of traditional development and the resistance of middle and upper management.
Everyone claims they're Agile. How would I know?
There are many different Agile methods and practices out there, and there are many different opinions as to what the minimum requirements are for agility. Generally speaking, you should expect Agile teams to maintain the following as a minimum:
- Heavy customer involvement (especially in release planning meetings).
- Regular update meetings (preferably daily).
- Regular releases of working software (every month or so).
- A development environment that supports continuous and automated testing and integration.
ASD in general does not support the idea of a complete separation of testing and development. In that sense, some QA roles might be eliminated in an effective Agile team. Nonetheless, the absence of the role does not mean the job itself is not accomplished. Every developer is responsible for producing automated tests that prove the correctness of their code (as in test-driven development). As a QA, if you're doing something that can be done using an automation tool, then you may want to rethink your career. Nonetheless, many teams will still need security testers, usability testers, performance testers ... etc. In an Agile culture, these testers need to be well integrated into the team if at all possible.
Why is it that developers have to sit in an open environment not in their own private work spaces/offices?
After decades of building software - and often failing miserably at it - we have come to learn that communication is key to the success of any software development process. Placing team members in offices or closed cubicles has been found to be an inhibitor to effective communication. Team members find it easier to use emails or documents to communicate their questions or ideas or concerns compared to traveling between offices and floors to have a face-to-face conversation.
By seating everyone in an open space, however, communication becomes significantly easier. Synchronous communication starts to occur in a very smooth and casual manner. A phenomenon known as osmotic communication starts to happen as people overhear conversations that would eventually affect their tasks in a way or another. If a build has failed, everyone on the team knows. If the customer is entertaining some thoughts about a change in the course of the project, everyone is aware of that. No secrets. No hidden agendas. And no forgotten reports, ignored emails or delayed responses.
Needless to say, if the Agile team is distributed, then communication becomes an issue that needs to be addressed.
What is the state of ASD today?
I strongly recommend that you read the State of Agile Development Survey Results (6,042 responses).
Where can I get more information?
Many books and blogs are available to help you get started. A list of the books and blogs I would recommend as a start is below. Good luck!
Books:
Books:
- Agile Software Development: Principles, Patterns and Practices by Robert C. Martin
- Refactoring: Improving the Design of Existing Code by Martin Fowler
- User Stories Applied: For Agile Software Development by Mike Cohn
- Test Driven Development: By Example by Kent Beck
- Extreme Programming Explained: Embrace Change by Kent Beck
- Agile Estimating and Planning by Mike Cohn
- Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
Blogs:
- http://alistair.cockburn.us/Blog
- http://www.agilemodeling.com/essays
- http://martinfowler.com/agile.html
- http://www.mountaingoatsoftware.com/blog
- http://www.infoq.com/agile/
- http://xprogramming.com/category/articles
- Find a rich list of blogs here: http://agilescout.com/top-agile-blogs-200/
Footnote: My objective in this post is not to delve into details, but rather to give an overall understanding of what agile methods are, and answer questions I am usually asked. I would like to thank Ted Hellmann and Derar Assi for providing valuable feedback on this post.
