It was a dark and stormy night. Dave sat at his desk staring forward. Frozen. The ominous glow from his email inbox exposed his eerie pallor, the sweat on his brow and the ever-so- slight panic in his eyes. “I should have been home hours ago,” he thought to himself. His heart was racing. He had to choose. Tomorrow his boss would take a sip from his Starbucks cup and announce, in his I–had-a-GREAT-sleep-last-night voice, “Dave is going to share our development approach and who we’re going with for our very important business-saving software development project. Take it away Dave!”
Dave had been so confident. Everyone told him fixed price/fixed scope. “This is the way to go,” he thought. “It controls my triple constraint of time, money and scope. Everyone will be happy. The CFO wants fixed cost, sales wants a concrete delivery date, and we know for sure the features we want for our users. Fixed Price/Fixed Scope is a guarantee that I get what I need. Right?”
Dave looks one more time at the email open on his screen, a last minute contender for his development project. “But this is a different animal,” he thought. “This feels risky, but kind of makes sense. Fixed budget but a variable scope? Hmmmm.”
When choosing a development team to build a software product, our first question is usually, “How much will it cost?” We are all driven by that bottom line. We believe that by fixing the cost, the vendor takes on the risk, and we will get the product we desire. However, much like construction and manufacturing workflows, fixed cost/fixed scope development projects generally demand a sequential design process. Often, waterfall methodology is chosen. In the waterfall methodology each stage — conception, development, testing — are completed, and then developers move on to the next step. Once a step has been completed, developers can’t go back to a previous step, not without either scrapping the whole project and starting from scratch or incurring extra costs to revise.
This process relies heavily on initial requirements. The whole product is only tested at the completion of development. If bugs are written early, but discovered late, they may have affected how another code was written. The temptation to delay thorough testing is often high, as these delays allow perceived short-term wins of staying on schedule.
This kind of plan doesn’t take into account a client’s evolving needs. If the client realizes that they need more than they initially thought, and demands change, the project will come in late and impact the budget negatively.
That’s not much of a guarantee. Dave put his head into his hands, rested his eyes for a moment, and then read on.
As an alternative, Agile development came about as an attempt to mitigate the disadvantages of the waterfall methodology. Instead of a sequential design process, the agile methodology uses an incremental approach.
Developers start off with a simplistic project design and begin to work on small clusters of features. Development and testing is done in weekly or monthly iterations. Customer feedback and changes are expected, rather than dreaded. At the completion of each iteration, project priorities are re-evaluated. This allows clients to ultimately get the product that meets their business needs, instead of the one they built on speculation and unknowns. This is especially critical for clients that need to keep up in a fast-moving, ever-changing industry.
Testing at the end of each iteration allows for bugs to be caught early in the development cycle and corrected. Because testing is carried out thoroughly and features are completed at the end of each iteration, the product can realistically be launched at the end of any development cycle, making it more likely to meet the launch date, even if not all features of the project have been completed.
Dave leans back in his chair and looks up at the ceiling. “The product I want and need, and the flexibility to make changes based on what we learn? I like that idea.” he muses. “But how do we ensure that happens?”
Enter the Product Backlog.
The Product Backlog is the customer’s Holy Grail in the Agile development process. Simply stated, the Product Backlog is the ultimate to-do list. It is a list of all required deliverables. Its contents are ordered by importance to achieve full business value. Priorities can change in the Product Backlog and requirements can be added and removed. The Product Backlog is the evolving driver of all development.
The Product Owner creates the Product Backlog. The Product Owner is the representative of all stakeholders. He/she is the voice of the customer and brings the product vision to the Development Team. As the project progresses, the Product Backlog tracks in descending order from top priorities to lower priority items.
Dave looks down at his watch and takes a deep breath. He likes the idea of a Product Backlog. Essentially, it is his lever to control what is being built. He is intrigued by having a Product Owner, his “voice”, and carrier of the vision. He likes knowing that a hand-selected team of expert developers will be dedicated to his project. He wonders for a moment how that team will work together and if they can all get on board and pull off the project by the due date and within budget?
Team Velocity is a metric used by Agile teams to measure how much work the team can successfully complete in an iteration period. It is a useful measurement when estimating how long a project will take. Figuring out Team Velocity is a pretty simple equation. The number of tasks a team is able to complete successfully is determined by reviewing past iterations. Once this has been calculated, the total number of project deliverables is divided by the average number of tasks completed per iteration. This determines the number of iterations required to complete the project.
Team Velocity may increase as the team gets used to working together and as the project deliverables become better defined in the Product Backlog. Team Velocity can also be adjusted to meet timeline requirements by adding or removing team members or by making adjustments to the project's scope. Most Agile shops charge per iteration or per month of development, so once Team Velocity has been determined, rough project cost estimates can also be carried out.
Dave comes to the end of the email and sighs. He feels that this approach is almost like building his own in-house team and he imagines having that go-to team for future projects. It will be nice to have a team to collaborate with and who understands his needs and vision.
“Working late tonight?” he asks.
“Just finishing up.” Dave replies as he reaches to unplug his laptop.
“Looks like the storm has cleared up out there.”
“In here too.” Dave smiles, grabbing his car keys and shutting the door behind them.
To be continued…
Shoot me an email at us@bandofcoders.com and let’s start talking.
By Tina Venema