Since a few months I am involved in the development of Agile Benchmark, a web application allowing users to evaluate their development practices against "best practices" from multiple methodologies (Scrum, RUP, OpenUP, PMBOK, Lean), with emphasis on Agile principles.

I believe Agile Benchmark has huge potential, first because there is a strong demand to answer the question "how agile are we?" and second because to my knowledge there is no such tool readily available on the web (yet).

After a lot of hard work (one of the reasons I didn't post these last two months) the beta release is finally out. It's public and it's free, so have a look at it!

Your comments are appreciated!

Earned value management (EVM) combines the measurement of scope, schedule, and cost in a single technique. EVM helps bridge the gap between agile project management and management metrics, by defining variances that provides accurate project status for scope (corresponding to the value of what has/will be delivered), cost (both budgeted and actual), and schedule.

The variances measure how the project is doing relatively to these three dimensions of progress. A single variance will leave part of the truth out of the picture; therefore we have to look at multiple variances to get an accurate status.

Let me give you an example: a project is made of three tasks of identical value and cost. At a specific point in time, the schedule tells us that tasks 1 and 2 should have been completed. But only task 1 has been completed, therefore the project is behind schedule. However, the actual cost of work performed (i.e. for task 1 only) is lower than the budgeted cost of task 1, therefore the project is under-budget. Consequently, the project is late but cost less than expected to deliver this value. One typical explanation of such a situation would be that part of the team has been allocated to another project after initial planning, but that the remaining members of the team worked more efficiently than planned (probably because of the pressure of the project being late).

Anyone involved in projects can understand why EVM is useful, but what does it have to do with agile?

Remember that one of the founding principles of agile is that progress is measured in delivered value. EVM, as the name implies, also focuses on delivered value. But measuring value the agile way is overly simplistic and can lead to misinterpretation of the status. In Scrum for example, the burndown chart pictures delivered value over the project and during the current iteration. If you already used this technique you certainly felt that something is missing. Indeed, by moving items in and out of the product backlog in the middle of iterations we loose the ability to evaluate how the project is doing according to schedule. Similarly, the burndown chart assumes that an hour of work accurately reflects all costs, failing to reflect that different team members incur different costs, as well as other costs. Therefore the information we have prevents us from using the variances defined by EVM.

Agile methods fit perfectly with EVM in principles but fail to provide techniques to measure variances. This is one of the reasons that agile has so much trouble gaining acceptance among managers and remains confined in small-to-medium development teams (in most organizations). The vast majority of agile "project managers" (excuse the quotes) do not know how to communicate to manager types how the project is doing according to schedule and budget (or maybe there is no schedule or budget because, you know, we're agile now).

Some hard-core agile advocates might perceive EVM has an "old school" technique that would make agile less agile, but I frankly do not see how you could measure progress without adding some metrics to agile-as-it-is-now. EVM has the advantage of being simple enough to add very little project management overhead, while providing true management-level metrics.

Other practitioners share this opinions:

• Dan Rawsthorne, Calculating Earned Business Value For An Agile Project (2007), Agile Journal
• T. Sulaiman, B. Barton, T. Blackburn, AgileEVM - Earned Value Management in Scrum Projects, SolutionsIQ
• A. Cabri, M. Griffiths, Earned Value and Agile Reporting, Quadrus Development Inc.

When we think about business process reengineering (BPR), we picture complicated workflows that big shots from a prominent consulting company designed without much involvement from the people who actually work with these processes.

The reasons that so many BPR missions fail are quite obvious:

• Process engineers focus on management to gather information; they do not pay enough attention to the people who do the job
• Process engineers focus on documentation; they assume that documents reflect practices and that there is little tacit knowledge
• The process engineers' mission ends when they provide management with a huge stack of documents explaining how the processes should work from now on; there is no or little follow up for implementing the changes. The sponsors are supposed to champion the whole transition even though their power is limited
• Process engineers assume that people will enthusiastically embrace their solution despite the above

Read more »

This is the first in the list of agile limitations:

1. A team of stars
2. Fit with organizational culture
3. Small team
4. Collocated team
5. Where's my methodology?
6. Team ownership vs. individual accountability

Agile has been designed by experienced, smart, and high-achieving people. A friend wisely pointed out to me recently that they naturally designed agile for people just like them: stars. Not everybody's a Martin Fowler, a Ron Jeffries, or a Jeff Sutherland. You could have given them any project, with waterfall method or even no method at all, and they would probably have succeeded. Indeed, not every group can be motivated, experienced, and skilled enough to self-organize into an efficient team, come up with lightweight processes, and collaborate seamlessly to achieve that great agile teamwork.

Take average individuals in you workplace and imagine what would be the outcome if you trusted them to self-organize and to choose the best way (at micro-level) to reach the desired result, without any close supervision. You might be quite disappointed. I'm not saying that individuals are not qualified, I simply emphasize that it takes more than the average Joe to achieve agility.

Does your team have the agile potential?
Do you have the agile potential?
Do you have the raw individuals to form an agile team in your organization?
Be honest.

If you answered "no" to some of these questions, it doesn't mean that you cannot become agile. It means that there might be some intermediate steps to take before getting there. In my opinion, these steps typically involve adapting the work culture by progressively empowering teams and individuals, training, and hiring the right people.

Decades ago organizations could be competitive by implementing industrial era concepts that work well in a stable environment, such as centralized management, close supervision, well-defined functions and replication of best practices. Nowadays this would be a recipe for disaster. In today's information era we rely on principles that almost completely contradict what we were doing only twenty years ago.

Interestingly, the ways of working organizations are now striving for are quite similar to the agile principles that are gaining momentum in software development. The agile principles seem broad enough to cater to other areas. Therefore the question is: Can we leverage agile principles for activities other than producing software, such as managing business in general?

Source: Cirque Nova

We will go though agile principles (compiled from various sources ? see references at the end) and examine briefly what they mean from business management's point of view.

Leverage individuals and interactions

• Instead of controlling individuals, empower individuals and teams. Trust them to take the right course of actions to achieve results.
• Place accountability at the team level, not at the individual level.
• Instead of assigning responsibilities, let teams self-organize to ensure that each team member takes on a role he/she really wants, leading to optimal use of resources.
• Rather than distributing tasks, state the desired results and let the team decide how to reach it by allocating work units across its members ("implicit" leadership).

Hire adaptive people and reward contribution continuously

• Traditional HR emphasizes standardized behaviour and functions, which leads to silo thinking and inflexibility. The agile organization is only as good as its people. Hiring adaptive people is key to reap agile benefits.
• Develop cross-training to improve collaboration and enable workers to see things from different perspectives.
• Reward contribution continuously (monthly for example, instead of annually) based on the impact the person had on the value that has been delivered to the customers.

Develop specific strategies

There is no recipe for success. Replicating so-called "best practices" is risky at best. Design specific strategies to achieve each business objective.

Deliver value quickly and regularly

• Delivering value to customers is the main measure for progress. Measure progress by tracking value, not effort.
• Schedule incremental (aka iterative) delivery of results ? even if they are little ? to keep motivation high and the feedback loop short.
• Set up a project-based organization to ensure that teams are always working toward goals.

Improve continuously

Make sure processes are lightweight and that nothing is edged in stone. Team members are encouraged to bring small but meaningful improvements (Japanese kanban-style improvement).

Respond efficiently to change

• Plan only what can be planned; keep planning minimal and iterative.
• Elicit changes continuously from all stakeholders.
• Anticipate what you can.

Collaborate closely with stakeholders

• Keep close contact with customers.
• Make sure people that decide the what (ex: customer, business analysts), the why (ex: managers, marketing), and the how (ex: engineers, developers), work closely together.

Target technical excellence

• Encourage learning.
• Target superior quality.

Keep it as simple as possible, but no simpler

• Take the shortest path toward the solution (without compromising quality).
• Don't use agile as an excuse to cut corners.

Maintain low overhead

• Minimize resources that are not directly involved in delivering value to customers.
• Use processes and tools only when there is a clear need for them, and keep them as simple and as flexible as possible.

Encourage creativity and innovation

• Foster intellectual curiosity and experimentation.
• Create an environment where individuals have the opportunity to make a difference.
• Don't punish mistakes that are the result of genuine forward-thinking.

REFERENCES

7 Agile Leadership Lessons for the Suits, E. Nizker, CIO.com (2008)

Business agility: 8 steps to improve reaction time, BDC

Agile Enterprise, Wikipedia

Are You Ready for an Agile Future? S. M. Heathfield, About.com

Leadership for the Agile Organization, Michael Hugos, CIO.com (2007)

The Next Generation Enterprise: Creating the Agile Organization, M. Schweer, Talent Readiness (2008)

Agile Software Development, Wikipedia

PM Declaration of Interdependence, Wikipedia

The declaration of interdependence for modern management, A. Cockburn (2008)