Agile, a Different Methodology
In the past year, Agile development methodologies have moved from the fringes to being considered a mainstream method for software development. The Agile movement started in the late 90's with the advent of Extreme Programming (XP), SCRUM, DSDM, Feature Driven Development and others. The Agile manifesto created in February of 2001 contained the core principles of Agile development. Why is this important to us?
Agile is important, because in the end, it has helped to bring business discipline to software development. Agile has a lot in common with Lean methods, exemplified by the Toyota Production System. Lean methods have begun appearing in Agile teams, bringing even more business focus to software development/IT teams.
Comparing Agile against what?
To get a sense of the high level view of Agile you can read the manifesto at AgileManifesto.org. The manifesto begins with four statements:
- Individuals and interactions over process and tools
- Working software over comprehensive documentation
- Customer Collaboration over contract negotiation
- Responding to change over following a plan
These statements may seem a little touchy, feely, so let us put some meat on the bone, to understand how to implement this in your shop.
For each of the statements in the Agile manifesto, concrete practices from Agile methods are used. Each statement is a section that will contain what practices are used to achieve the intent.
Individuals and interactions over process and tools
This statement may indicate to you that Agile has no process. In fact I have found this to be far from the truth. Agile does not throw process out the door, rather Agile says that Individuals and interactions trump the process and tools.
This shows in the frequent planning and daily standup meetings common to most Agile methods. In XP, Scrum, Lean the daily standup meeting is a staple. At this meeting all committed team members interact with each other via these questions:
- What did I do yesterday?
- What am I working on today?
- What is blocking my work?
The daily standup should help communicate project progress. In other words, what is communicated in the standup (individuals AND interactions), may need to supersede the project plan. It is during these meetings that hurdles are uncovered. But usually they are discovered in time to fix the problems quickly. If a technology is not working as expected, or the business logic actually conflicts with other logic, it is brought up in these meetings, and after the meeting the action plan is created.
Working software over comprehensive documentation
This phrase is best described by the practice of delivering software on a regular, fairly quick schedule. Normally in XP and Scrum, you work in iterations. The team selects the length of the iteration at the beginning of the project, and generally stays with that length for the duration of the project. Within an iteration, the team selects the stories or features they will complete. Once in that iteration, the stories that are being worked on cannot be changed. Any changes can be introduced at the beginning of the next iteration.
Normally, at the end of the iteration, there is a demo and planning meeting. In this meeting, your team demos the solution including the new features/stories to the stakeholders/customer. The intent is that if the customer likes this, the team could release that version of the software immediately. In practice this can mean that the team releases the software to QA or User Acceptance state where customers can test/use the new features. Other teams may release to production (think of all the google beta software you have used).
One note on iterations, the length is generally considered to be 1 week to 1 month. This is up to the team. Again, this decision should be made as a self determining team, it should not come from management.
Many Lean/Kanban teams do not use iterations, but they do frequent releases. The releases happen on a similar schedule as iterations. This allows the Lean/Kanban teams to release working software frequently.
The reason for valuing working software over detailed and comprehensive documentation is that the value delivered is the software. Documentation of your system should be baked into the process of delivering software. Agile does this, by encouraging good software engineering principles like Test Driven Development using automated unit tests and automated user acceptance tests.
Test Driven Development using unit tests, and acceptance tests, encourage test writing that serve as documentation. A well written unit or acceptance test should document the requirement the developer is testing for. When any maintenance is needed, different developers should be able to look at these unit tests and understand the requirements needed.
In addition, this suite of tests add a fantastic safety net for modifications later in the life of the software. If the software sits for a year before modifications, the new team can start development on new features, knowing that those tests ensure that they cannot break existing features.
Click here for larger image
Figure 1: Example of what unit testing frameworks look like
Page 1 of 2