ORLANDO, FLA. -- When following agile software development practices, it's typical for managers to question the return on investment (ROI) for using that methodology. What does it mean for your organization's bottom line profits?
It actually means a lot, says James Shore, principal at Titanium IT and author of the book The Art of Agile Development. You can use your agility to increase the value of your project to its stakeholders, Shore said during a session at the Better Software Agile Development Practices conference last week.
And by increasing the value, as well as lowering the cost of a project, you can increase the ROI on the project, he said.
"I'd like you to take responsibility for increasing the value of your software so you don't have to worry about shorter deadlines and your job being outsourced," Shore told the session attendees. "As a member of the team you can decrease costs by using Agile, and you can use agile to increase value. There's no limit on how high value can go."
Before you can get started doing this, Shore said there are three things your team must have or do:
- You must be more concerned with increasing value than meeting a deadline.
- You have to have a way to do agile development
- You must have some business experience on your team
Once you have those, you can put the following practices to work.
Work on one project at a time
By working on one project at a time, you can earn more money, Shore said. So, you want to work on the first project and release a version after three months. Then switch to the second project and release a version of it after three months. While you are working on the second project, you are making money on the first project, Shore continued.
This may be difficult for some organizations to do, as those involved in the project you aren't working on won't "feel loved" even though the products will be released at the same time, but it adds more value and money.
Release early and often
You want to release the most valuable half of the software first. By doing so, you can make money while you work on the remaining half, Shore said. "You can make two months of free money on a six-month project," he said.
Shore gave this real-world example for how that can be achieved:
There are two projects. For one, there are two releases, and for the other there are five releases. The total cost for each project is similar -- $4.3 million for the project with two releases, and $4.712 for the project with five releases. However, the revenue generated for the first project is $5.6 million, while the second sees revenue of $7.8 million.
The investment on the projects also differs greatly. Project 1 has $2.76 million invested in it, while project 2 has $1.64 million invested in it. This results in a payback of $1.288 million on project 1 and $3.088 million on project 2.
The net present value at 10% for project 1 is just $194,000, and it is $1,594 million for project 2. And you get an internal rate of return of 12.8% for project 1, while project 2 has 36.3% -- a very respectable return, Shore said.
"The only difference between the projects is the way they were planned," Shore added.
Organizations can recognize similar returns if they think in terms of "minimal market features," he said.
"Think of the smallest thing you can deliver that has value. Decide what adds the most value -- sets you apart -- and do that first," Shore said. "And to deliver more often, you have to do less in each release."
Adapt your plans
User and stakeholder feedback is critical when doing agile software development. When you get their opinions, you can better create software that meets their needs.
"You're always going to know more about what users want after you collect information and do demos," Shore said. "At a minimum, do a release, collect feedback and make changes."
And with agile development, you don't have to wait long to adapt your plans. Release every one to four weeks and adapt your plans often, he said.
"Find excuses to change your plans because that means you're learning. Focus on what you don't know," Shore said.
Keep your options open
With agile development, you're learning and changing things as you go, so make sure you're able to change your plans, Shore said. You need to be ready to ship or change directions at any moment.
Do this, for example, by making sure user stories are arranged in a way so that each can be released on its own -- that they don't depend on a future story in order to be released. Forget about working by application layer -- UI layer, business logic, database later -- and instead work by feature.
"You need to work in a way that focuses on business value," Shore said.
Plan at the last possible moment
When planning your project, you don't need to work out all of the details at the beginning, Shore told the audience. If your release is three months away, maybe all you need to know is the vision. But if you're releasing in two months, you'll want features. And if you're releasing in on month, you'll want user stories.
"You don't need specification until you're actually building," Shore said. "Identify at the last moment the details and make decisions about the details. Adaptive planning can increase value as it allows you to adapt to issues that come up."
Adaptive planning like this can be a real cultural challenge. But Shore points out that it doesn't mean you can't make commitments. "The key is you want to be able to change that plan if needed," he said.