Lots of people see agile development as a magic bullet.
It’s not.
However, it is a good idea, and one that development teams should definitely use.
“Now hold on,” you say. “Before you get too deep into opinions, I’m not even sure what agile development is.” Well, here we are going to explicate agile development so you can both appreciate its advantages and understand that it’s not the panacea to management problems.
The first thing to look at is the Agile Manifesto, the product of a meeting in 2001. Those present wanted to improve the software development process, and this is what they came up with:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
Agile methods had existed before the Manifesto was created, but this document brought the principles together and labeled them “agile development.” The people who created it wanted to make the software development process more flexible and effective; in effect, more agile. It is more people-focused than the traditional waterfall method of software development and allows developers to adapt their work to meet customers’ changing needs.
That being said, agile development doesn’t change the actual amount of work that needs to be done on a project. Rather, it breaks the work down into bite-sized pieces that can be processed in two-week “sprints” rather than trying to plan, develop, and refine the whole project all in one lengthy gulp.
Let me explain a little more. The traditional waterfall method was the main method used before agile development and still has its hooks in the production process today. A company uses it has an assignment called Project X. Using the waterfall method, the company moves Project X sequentially from one team to another, passing it down the “waterfall” until it reaches the bottom; i.e. completion. There are a few issues with this method. First, no team can work on the project until all the prior teams have done their part. Second, if a bug gets into the project and isn’t caught until the end of the waterfall, when the completed project is tested, it’s difficult and pricey to go back and figure out where the problem occurred in order to fix it. Third, and along with the same lines, if a customer’s needs change during the production process, it’s hard to adjust to meet them. Fourth, the waterfall method puts pressure on the development team to have a long-term project done in a certain amount of time when, at the start, they don’t know what mishaps or changes might happen along the way. Conclusion? The waterfall method sucks.
On the other hand, agile development breaks the production process down into iterations, or sprints. Sprints can vary in length, but at Jive they are two-week work cycles that have the goal to develop specific features belonging to the overall project, test the features, and have them ready to demo by the end of the sprint. Each sprint is like a mini-waterfall in that all of the development steps are followed through to completion. However, the rapid iterations make the agile method much more effective. Developers only commit to a sprint’s worth of work at a time, so if customers change their minds about what they want, it’s easy to plan that into future sprints. Agile also takes stress off the developers because they don’t have to know how much they can do in three months—they just have to figure out what they can commit to for two weeks. And if they overbook themselves in a sprint and have to work overtime to get it done, they can reevaluate and adjust for the next sprint. In addition, developers are constantly reporting on their work in daily stand-ups and end-of-sprint retrospectives, which helps them stay accountable.
Altogether, agile development is much more flexible and people-conscious than the traditional waterfall method. However, note that agile development does not advocate flying by the seat of one’s pants. Product managers should be planning at least a few sprints ahead so the project as a whole can move forward in a timely, orderly manner. Agile in no way means lack of organization.
So to conclude, agile development is a great way to improve project management, though it won’t work properly unless implemented right. At Jive, we do use it right, and it rocks our management system every sprint.