Agile Metrics - June 2006
Metrics is a very hot topic. Managing and measuring Agile projects are particularly challenging. For this month's issue of the Agile Journal, we received so many abstracts for articles that it was difficult to choose only a few. So we bent our own rules a bit and accepted a larger number of articles, addressing a wide range of ideas and best practices. I guess this is a great problem to have and I hope you appreciate the wealth of experiences!
read more>>
|
|
Calculating Earned Business Value For An Agile Project It is apparent that agility works, whatever that may mean. However, many software projects remain artifact-driven and waterfallish. Why is this? The most common excuses are that agility is too developer-centric, that it is too lightweight, and that feedback to business is hard to understand. In particular, many managers in larger companies miss their metrics. In this paper we address this last problem by defining a new metric, Earned Business Value (EBV), that replaces standard Earned Value Analysis (EVA) metrics, and can be calculated in an agile project. Using EBV, teams can gain better understanding of a project's progress and determine when and where to reallocate resources or change course.
Read More >> |
|
|
|
|
Using Metrics To Help Drive Agile Software The promise of agile development is to deliver high value software more quickly, while remaining responsive to change. But change tends to cause software rot where simple modifications ripple throughout the application, exercising the design in unexpected ways. Avoiding software rot and maintaining design integrity requires frequent refactoring to ensure code remains clean and concise with minimal dependencies between modules. Code quality and design metrics offer objective advice in identifying areas of the application that are solid candidates for refactoring, while coverage metrics provide the guidance and courage necessary to undertake the refactoring effort.
Read More >> |
|
|
An "Agile Maturity Model?" Becoming an agile IT organization is a process of continuous improvement and evolution in a number of different areas such as requirements gathering, project management, and development. This can be fulfilled in many different ways, with process changes enabling or inhibiting responsiveness to greater or lesser degrees. Ordering the different ways to evolve by degree of agile affinity defines a lightweight "maturity model" that allows an organization to asses current state, set targets, plot a c... Read More >> |
| |
|
|
5 C's of Agile Management Anyone who has ever been responsible for managing software development projects knows that software is not easy. Successfully coordinating and dealing with project sponsors, customers, team members, technology issues, and changing requirements challenges even the most experienced project leader. Leading projects in an environment that embraces both rapid delivery and change can prove even more daunting. Yet individuals with the desire to change the fundamental rules of the software game and acce... Read More >> |
| |
|
|
Iteration and Release Retrospectives: The Natural Rhythm for Agile Measurement At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (Agile Manifesto principle 12)
A cornerstone of agility is the team's commitment to continued reflection and adaptation. For most teams, there is a natural cadence to this process as iterations occur frequently, typically every one to two weeks apart, and releases occur every two to four months. As such, the iteration boundary represents a frequent opportunity for im... Read More >> |
| |
|
|
Rhythms As Agile Diagnostics A healthy agile project has several typical rhythms such as releases, iterations, stand-up meetings, builds kicked off by continuous integration, and the red-green-red test cycle of a developer. These rhythms have healthy ranges (such as a stand up meeting lasting less than 15 minutes) and characteristics (such as that same stand up meeting not containing design discussions). When they fall out of these ranges or do not display the appropriate characteristics, they indicate that something is wro... Read More >> |
| |
|
|
Best Practices In Global Agile Development For Product Innovation Agile over the wire and how to make it work.
In our experience, pure-play Agile development is destined to fail in a global delivery model. The basics of Agile, such as the emphasis on face-to-face communication, close interaction between teams and an adaptive approach to product development, are not possible while engaging an offshore team. However, by injecting process adaptations, Cognizant has successfully enabled some facet of "specially customized" Agile methodologies. In fact, a larg... Read More >> |
| |
|
|
 | FEATURED BOOK: Agile Management for Software Engineering - by David J. Anderson David Anderson is the "Peter Drucker" of agile software management! This mind-blowing book manages to successfully synthesize and synergize the theory and methods of Agile software development together with those of Goldratt's Theory of Constraints (TOC) and Reinertsen's Lean Production. By translating TOC's "throughput" into Lean's "flow" of business value in the form of working software, Anderson manages to align them into a practical and comprehensive "management science for s... Read More >> |
| |
|
|
CASE STUDY: Rally Software Development And ISV Customer The Importance of Iteration Acceptance Metrics
One of the fundamental goals of a software team is to have a stable and predictable development process. Stable and predictable means better expectation management and fewer surprises. The percentage of stories accepted within an iteration is an excellent metric to gain this stability and predictability. We define an accepted story as one that has been successfully completed and tested, is defect free, and has been approved by the product owner... Read More >> |
| |
|
|
|