Allan Kelly

There is more to calculating ROI than a simple equation. It can be affected by risk, time, and other factors—including whether your team is agile. Releasing software immediately after coding and testing accelerates feedback cycles, minimizes the cost of delay, and increases return on investment. Allan Kelly tells you how.

Using effort estimates as the only criteria for deciding whether work is undertaken could be leaving money on the table. Considering value—in particular, the effect of time on value, as in whether there is a cost of delay—makes for more intelligent conversations and better decisions.

You can use analytical methods to assign business value to a user story, of course, but another way is simple estimation. Allan Kelly describes an estimation exercise that combines the Scrum tool of planning poker with a TV show format to add some fun. You end up with enlightening conversation and revealed requirements.

Instead of choosing what to develop based solely on a cold, hard dollar amount, you might try approaching the person who originally requested a story—or who will be most affected by it—and asking, “What benefit will this bring you?” Armed with a list of stakeholders and interests, you can find out the real difference a story will make.

Allan Kelly says that ideally, companies should put a dollar amount on each planned business decision. But pinning down financial value can be hard, and besides, there are many other factors to consider, such as sustainability and customer service. He looks at various ways to assess the business value of user stories.

People will ask, “Can you use agile outside software development? In real business, not just in software teams?” Most experienced agile practitioners will instinctively want to shout, “Yes! Of course!” But intuition apart, where is the evidence? Allan Kelly found some examples and shares how agile works in environments outside software.

We all know we need to do retrospectives. And sometimes, it feels as if we go through the motions. Maybe with dialogue sheet retrospectives, we don’t have to. Here, Allan Kelly shares his perspective on dialogue sheet retrospectives.

In this personal and direct letter to customers, Allan Kelly pulls no punches and explains why IT projects don't always pan out for all of the parties involved.

Like "coach" and "ScrumMaster," "product owner" is a new term for a new role. While coach and ScrumMaster are completely new roles added by agile methods, the product owner is an extension of an existing role—or rather, it is an extension to two existing roles. Whatever the role is called, it is concerned with deciding what should be in the next iteration, prioritizing work, providing guidance on what is being built, and ensuring value is created.

The current economic downturn is a new test for Agile, until now Agile has been promoted in a growing economy. Proponents of Agile have emphasized how it improve competitive advantage and helps a company out-compete its rivals.

Now companies are concerned with simple survival. Today's managers are concerned with cutting costs, improving cashflow and managing without credit. Organizational change and process improvement are not top of the agenda. Promoting Agile in this environment is something new.

Despite our best efforts we need to know what we are going to code before we write the code. And as much as we might like to test before we write the code we can't really run tests until we have some code. Agile overlaps requirements discovery and implementation so coding can start with minimal or outline requirements but there is still a sequence.

The good news is: Agile is going mainstream; it is not some fad nor is it just for unwashed coders. Managers get it. The not so good news is: this means the approach to introducing Agile needs to change.

Agile Software Development started at the code face. Kent Beck's original Extreme Programming had little - if anything - to say about the wider organization and the role of management. Developers could - and did - just adopt practices like test driven development and stand-up meetings.

Within the Agile community retrospectives are widely seen as the mechanism for promoting learning and change. But many teams fail to hold retrospectives, or fail to act on the findings, thus they fail to learn and improve. If we are going to fix this we need to change our approach to retrospectives, and find new ways to learn and create change.