|
|
||||||||||||||||||||
| Home > Software Quality News > Agile development can increase project ROI | |
| Software Quality News: |
|
||
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:
Once you have those, you can put the following practices to work. Work on one project at a time 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 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 "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 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 "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.
'); // --> |
|||||||||||||||||||||||||||||||||||||||||||||||||
| About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
| |
|
|||||||