If you need to develop a piece of software, you can do it the traditional way or the agile way. You might have seen comparisons of both methods, but do you really understand the difference? Let's take a look at a true-to-life example.
Acme Inc. wants to develop a new software solution for use in their 1000 offices around the globe. Here's how the project could be done:
The Traditional Way
Megan, the senior manager at Acme hires Patrick, a certified Project Manager Professional (PMP.) Patrick is well versed in managing large projects using the traditional, waterfall approach.
Megan gives him the project charter, the budget and the time-frame. She gives him the needed authority and makes him ultimately responsible for the project and its delivery. (This is a very positive scenario. In most cases Patrick would be given all the responsibility but very little authority, which would make his job that much harder.)
January 1st. Patrick starts planning the project.
He meets with the stakeholders to collect the requirements and define the project scope. He then creates a work breakdown structure (WBS) and hires some consultants to help him decompile it to work packages and activities. He puts the activities in order, estimates their durations and the resources needed to complete them (all with the help of expensive experts, of course.)
He then estimates the costs for each activity and drafts the budget. The experts help him create a plan for controlling the quality of the work. He hires the development team and procurers all the other resources he'll need to complete the project. He develops a strategy for communication and documentation, he identifies the risks, analyzes them and plans risk responses.
May 1st. Patrick completed the plan.
Since he's an experienced PM, Patrick expects the scope, budget, time-frame and quality to be out of sync at this point in time. He faces the textbook scenario of too much work and quality requested with too little time and money given.
He renegotiates with Megan and the other stakeholders to compromise and balance the four project restraints.
July 1st. Patrick is ready to start the development work.
Megan is relieved. But she informs Patrick that the business goals have changed during the last 6 months and some of the project scope will need to change as well. Patrick runs through the established system for change implementation and adjusts the plans.
August 1st. The development work begins.
The developers can finally start programming. About time, too, since they have about a thousand items on their to-do list.
September 1st. Megan wants to see a working prototype.
She has stacks of documentation and slide shows but wants to see a working piece of software. Patrick promises to have it ready next month.
November 1st. Patrick demonstrates the first working prototype.
Megan and the stakeholders are not impressed. The prototype shows very little functionality and is highly unstable. Patrick explains that a lot of things have been started but they're not finished yet, so they can't be demonstrated. Megan is not happy. Nearly a year has passed and half of the budget is gone.
Having seen the prototype, Megan and the stakeholders have some new ideas. Patrick runs them through the change process and readjusts the plans. With more items on the to-do list he again needs to renegotiate the time-frame and the budget.
The developers add the new functionality to the unfinished product. They have to scrap a lot of work that they started and didn't finish. The product becomes even more unstable.
In the end it takes a year and a half to create the first version of the product. It has a lot of functions, but it turns out that most of them are not so useful anyway. The budget is overextended and the pressing release deadlines compromised the product quality. The developers are burned out, Patrick is stressed out and Megan secretly starts preparing her CV, just in case.
Patrick promises that he can have an upgrade ready with all the bugs fixed in 12 months.
Do you think this scenario is exaggerated? It's not. The traditional approach might work well enough for very small software projects, but with the more complex projects it can get a lot worse than described above.
The Agile Way
Megan decides to use Scrum, an agile development framework, to develop the project.
January 1st. The project begins.
Megan goes through a course to get acquainted with Scrum so she can actively participate in the business side of the project as a Product Owner. Of course Megan could also hire a Product Owner, but since she's the champion of the project at Acme, she wants to be personally involved in maximizing the value of the work.
She hires a group of developers and Scott, a certified Scrum Master, who will make sure the project is done the Scrum way and will coach the development team.
Megan prepares a short list of the most important product functionalities and the development team estimates how long it will take to get them done.
February 1st. The work begins.
Megan meets with Scott and the developers. They analyze the items at the top of Megan's list and the developers select the items they believe they can get done in 1 month. The next day they go to work.
March 1st. The first version of the product is finished.
Out of the 5 selected items, 3 were completely finished. Scott explains that this is normal and that the development team needs to find its bearings. Their estimates will get better with time.
The developers present the first version of the software to the stakeholders. There's not much in it yet, just the basics, but it's stable, tested and it's a solid foundation to build on. And it's completely finished, icons, graphics, and all.
Having seen the working product and having gathered the feedback from the stakeholders, Megan adjusts the to-do list (product backlog.) Some new items are added, others are dropped and the list is re-ordered.
The development team select the next batch of items from the top of the list that will be worked on during the next 30 days. The development team goes to work.
June 1st. Pilot release.
After 4 iterations of selecting the most important backlog items and getting them finished, the product starts to look impressive.
It doesn't have all the bells and whistles yet, but it can start handling some of the work it was designed to do. The product is tested, sturdy and ready for release. In fact, the product was always technologically ready for release. Megan was just waiting for the product to have enough functionality to be of use in a real-world situation.
Megan feels the software can now be released to some of the company branches as a pilot program.
September 1st. World-wide release.
After gathering the feedback from the pilot program and 3 more 1-month-long iterations of development, the product looks a lot more complete.
Megan feels it could be released to all the branches. It will need to be developed further, but she's now confident that with the secret Scrum weapon at her disposal, it'll not be a problem.
As you can see, the story has a happy ending: the software is done, released and stable, the developers are relaxed and challenged, since they were trusted to organize their own work and do what they do best. Scott is setting up a larger office to fit more Scrum teams and Megan? Megan is secretly preparing a letter asking for a raise... Yes, she deserves it.
Can you see the difference? The Scrum team delivered a well-rounded, releasable product that met everyone's expectations in the same amount of time that it took Patrick to complete the project plan.
As I always say: if you need to build a sky-scraper, hire a PMP. If you need to build software, hire a Scrum Master and teach your company to use Scrum.
It's not easy to shift the company's modus operandi towards agile. It might take months or even years for new mindsets to take root and for all the parties involved to learn the new ways. But if you're in the software business, you only stand to gain from it.