Agile software development and the technique of time-boxing go hand-in-hand. Agile development methods are characterized as being able to adapt quickly to changing realities by incorporating planning, requirements analysis, design, coding, testing, and documenting tasks to release mini-increments of new functionality.

Requirements management tools enable implementation of a successful requirements management process. Tools are available for every budget. Set out clear evaluation criteria to pick the best-fit tool for the enterprise.

Technology Point
Having identified a business need for new software, IT managers must make the decision to either build a custom application or purchase a commercial-off-the-shelf (COTS) product. Regardless of the choice, IT must make sure business needs are adequately understood so that it can deliver a suitable solution. In some cases, the build versus buy choice can depend upon what the business requirements are (e.g. whether customization is necessary or cost effective).

Scrum and other agile methods recognize that responsiveness to change is an important aspect of delivering projects. They also recognize that software development is evolutionary and creative. By managing changes through Adaptive planning, Scrum provides a simple yet effective method of planning and tracking project progress. In this article, we will examine what is needed to sustain Adaptive planning and improve Team's responsiveness towards customer needs.

We will examine the following factors:

•Just-enough planning
•Evolving plan, scope driven by budget and/or time

Flavors of Agile

Agile forms of development are increasing in popularity as the need for projects characterized by changing requirements become the norm. For many project leaders, waterfall development connotes a single image of a development method characterized by clear steps for developing software in successive stages. Everybody gets waterfall – the method has been around for years and is ingrained in business practices.

Agile methods also have differences to consider. The differences can be looked at across the following criteria:

•Size of development team. Considering the adoption of methods, the size of the development team is one of the main decisive issues.
◦XP and Scrum, for example, are focused on small teams (e.g. <10 people).
◦FDD and DSDM claim to be capable of scaling up to 100 developers. Note that with agile, when the development team gets larger so does the amount of documentation and communication and this tends to make the project less agile.

Enterprises are moving towards agile software development methods to increase productivity and project quality. Agile projects must adhere to agility best practices to increase their success.
Best Practices

There are seven best practices for operating agile projects. These best practices span every size of IT organization and generally apply to all agile projects. Follow these practices to optimize agile software development and drive improvements to the projects' bottom line.

Scrum is an agile approach to software development. Rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the team. This is done because the team will know best how to solve its problem.

As a ScrumMaster, I was asked this question many times. Sometimes I had enough time to explain, sometimes not. But every time it was challenging to provide a clear picture of what a ScrumMaster really does.

To help myself and other ScrumMasters, I have started to write down general activities, which characterize the role of the ScrumMaster (see below).

The priority of activities varies by company.

1.Keeps Scrum process running
2.Ensures a proper power balance between PO, Team, Management
3.Protects the Team
4.Moderates in the Team
5.Helps to organize (e.g., Meetings)

In the late 1990’s several methodologies began to get increasing public attention. Each had a different combination of old ideas, new ideas, and transmuted old ideas. But they all emphasized close collaboration between the programmer team and business experts; face-to-face communication (as more efficient than written documentation); frequent delivery of new deployable business value; tight, self-organizing teams; and ways to craft the code and the team such that the inevitable requirements churn was not a crisis.

http://www.agilealliance.org/show/2