A couple of posts ago we talked about Agile’s business values; now we want to talk about business requirements.

It is important to deliver requirements with the highest business value in each iteration so that the client receives quantifiable results. Businesses are under pressure to deliver results and, for the most part, they cannot sustain a competitive advantage if they have to wait an extended period of time for business value from the developers.

Not all requirements have the same value to the client; some requirements are essential to the business’ objectives whereas others, like infrastructure improvements, may be perceived as having little business value. Some requirements that reflect business value should be prioritized high for each iteration. This way, in each iteration, the developers deliver business value to the recipient.

In conclusion:

• Identifying the requirements of a system that are important to the client is often the most important phase in measuring successful software development projects
• Prioritizing requirements so the client receives software that provides quantifiable results with each iteration or release benefits business development
• Better business value is delivered with each iteration

Couldn’t your business develop better through identifying and prioritizing your requirements?

The last couple of posts have been about the importance of development tool stacks and what tools are available. This post moves on from there to discuss how Agile delivers business value in every step of the development process.

In software development projects, more teams have been adopting the Agile methodology instead of the Waterfall model because of the advantage of the former in delivering business value quickly and efficiently. The development cycle using the Waterfall model often takes a year or more, which means at the culmination of a project, the initial requirements of the project will most likely be outdated. This results in new software that may have less value in the market for the client than originally planned. One benefit of moving to Agile processes is having short iterations so the team can adapt to changing requirements and complete valuable and relevant deliverables in a faster timeframe.

A frequent stumbling block inherent in the traditional development process often arises when identifying system requirements. In this phase, the developers work with the client to establish the functionality of a system or more specifically what will be built. This is when the business value of each requirement is evaluated. Problems often arise at this point because the client does not know exactly know what they want or they may think they do and then change their mind as the project moves forward.

In Agile, the client can continuously give feedback on what has already been delivered. The developers can then update the requirements and their business value based on the desires of the client. To achieve this, a developer would be best served by working with Agile development tools that offer complete management visibility of projects throughout the entire development process and into production. This makes it easy for changes to be made during the process, and the client can realize their business value along the way.

Wouldn’t you rather make changes with each iteration than at the end when the project should be complete?

In our last blog post we discussed the importance of your development tool stack when transitioning to Agile development, now we’ll take a closer look at what tools are available.

All of the components in your tool stack interact with each other and with your overall development process. As you transition to Agile development, many of the components in your tool stack that were helping you do traditional development are now working against you in two ways. First, they aren’t helping you do Agile development well, and second, they are actually working actively against your efforts to be Agile. You may also be missing some support structure that you need and tools that can help you leverage your effort.

At one extreme of tool stacks for Agile development is a stack that has no support for Agile whatsoever.  An environment like that may include tools that are poorly suited for Agile development such as CVS and Bugzilla – and it would be missing support for Agile Project Management, unit tests, and Automated Build Management. This environment would actually work against your transition to Agile development.

At the other end of the spectrum is a tool stack built entirely out of tools that were purpose-built for Agile development and linked together into an integrated Agile solution. We spend a lot of time watching the industry and from our perspective; there are really just two choices out there today. One choice is IBM’s Rational Team Concert. Team Concert is a good system but it is immature, expensive, and there don’t seem to be many deployments.

The other option is to build a custom solution using individual tools. For instance, you could use GIT for source control, Hudson for automated build management, and Excel and your existing issue tracking system for Agile project management. There are two problems with this combination. First, the only component purpose-built for Agile development is Hudson. Second, using Excel for backlog management doesn’t scale very well.

The solutions currently available are all either too complicated or too expensive. Wouldn’t a best-of-breed, fully-integrated solution supported by a single vendor be better?