Ok, this may seem like heresy, but Scrum isn't enough for organizations to succeed with agile on software development efforts.  Scrum provides techniques for the incremental definition and management of work and Scrum describes the roles, collaboration, and communication patterns for Scrum teams.  While these address some software development challenges, their are several others that must be considered to achieve the hyper-productivity that's possible with agile.

When I discuss agile with my customer/clients/prospects, I advocate a mashup of Scrum and Extreme Programming (XP) practices and activities.  Scrum provides the management framework and XP the developer and individual contributor best practices.  Additionally, if your practicing agile at any level of scale (more than 3 teams that are collaborating on a release), there are important "program management" and "product planning" activities that both Scrum and XP do not address.

So when I evaluate how agile an organization is, here are the key activities and practices I look for:

1. Cross-functional teams that include the customer (or their proxy), development, test, documentation and any one else required to create "the whole product"
2. Incremental delivery of production quality capabilities at regular intervals
3. Test-driven development that builds quality in from the beginning
4. Automated and unattended build, test and reporting and I maniacal focus on build quality

And for enterprise class agile, we've got to consider program and product management.  There are some in the Scrum community that advocate the "Scrum of Scrums" and "Super Scrum" for these activities respectively.  I've seen these used quite effectively. 

1. The Scrum of Scrums is a program management meeting.  It's run by a Scrum Master, attended by all Scrum Masters and Product Owners,  and typically occurs twice a week.  Its a tactical meeting where Scrum Masters discuss cross-team impediments, team acceleration or deceleration, and other topical issues.
2. The Super Scrum is a product planning meeting.  Its run by the Chief Product Owner, attended by all Product Owners and Scrum Masters, and is held about twice monthly.  The purpose of this meeting is to discuss long term product vision and direction and to continuously evaluate product-level backlogs and priorities.  For this meeting to be effective, it must stay at the vision, theme, and epic level.  Lets leave it to our teams to do the heavy lifting!

A successful agile implementation relies on the existence and interplay of all of these practices and activities.  It is not easy to get there and there are many practical challenges and considerations.  But with team and management support, and a fair amount of intestinal fortitude, the hyper-productivity of agile is within your reach!

After much prodding from Jeff McKenna, I finally got around to reading “Software By Numbers” by Mark Denne and Jane Cleland-Huang.  It’s an interesting read that focuses the software development process on delivering value to customers.  Denne and Cleland-Huang introduce minimum marketable feature (MMF).  The MMF represents the smallest possible decomposition of a feature/capability to which business value can be attributed.  The authors go further to define a software development value chain that is designed to optimize value delivery to the customer.  While I of course have some concerns with the model, I found the underlying financially driven approach very interesting.  It aligned very well with prior work that I’ve done in Project and Portfolio Management (PPM).

Software by Numbers got me thinking about Agile.   Specifically around incremental development and how it has an inherent advantages over traditional methods in delivering value to customers.  I wanted to push on this a bit so I built an ROI/NPV (return on investment; net present value) calculator.  These are well-established metrics for measuring how projects deliver value to the business and for evaluating various investment choices.   Check out the hyperlinks above for more information on NPV and ROI.  So I scraped the rust off my business math skills and built an ROI calculator using Excel.  The results are pretty much what I intuitively excepted.   Here they are:

Some assumptions made with the calculations are:

• Execution of the agile and traditional projects are assumed to be “perfect”.  The planned value is delivered on
• The total monetized value delivered by the agile and traditional team is $1 million.
• Value is not immediately realized on feature delivery.  The traditional project value is realized linearly the first year after the project completes.  Agile project value is fully realized within four months of delivery.
• There are 10 resources on the team with a loaded annual salary of $125,000.
• After all value is delivered, maintenance costs of 20% per year are incurred for years two and three.  That is, ongoing costs are reduced by 80%.  This assumes no major development work is delivered after year one.
• Cost of capital is assumed to be 15%

Its interesting also to look at the payback period.  The payback period basically states how long it will take to recoup your investment based on benefits received as a result of the project.  With the incremental/agile approach you achieve payback in half the time (14 versus 30 months)!  The graph below shows cumulative net benefits.  The payback period is basically the interval prior to lines crossing $0 on the y axis.  Each interval on the y axis on the chart below represents two months.

So what does this all tell us?  Deliver value to your customers early and often!  The benefits of agile’s incremental delivery approach are very quantifiable.  I'll be blogging more about agile ROI in the future.  The things I'll be exploring will be the impacts of failure and scale on agile development, how it can impact ROI, and how you can mitigate the risks!

You can download the excel spreadsheet for this ROI/NPV calculator here.

Sometimes I worry that we are wringing all of the agility out of Scrum with the high degree of prescription that I see some teams follow.  At times I see backlogs rigorously maintained and scrubbed.  Product Owners tightly managing how/when/if the backlog items flow out of the backlogs into a team's sprint.  And the the team maniacally focused on delivering exactly what was specified in each sprint.  The irony here is, that more often I am coaching my teams to execute exactly as I just described!

I struggle though with prescriptive scrum on how we can deal with innovation.  In my 20 years building software I have seen most interesting innovation come from the individual, not the team.  Yes, this will be heresy to the agile zealots.  But good Scrum Masters (team leaders) must find a balance between the team and the individual.  We must build an culture and environment where not only the team is empowered but where the individual is encouraged to innovate. 

Innovation can be encouraged with varying degrees of formality.  It may be that the culture encourages individual innovation in so far as it does not impact the team's velocity and their ability complete the committed work within a sprint.  This leaves it up to individuals and team to self regulate time not spent burning down the sprints story points.  This approach will work for some teams, but can certainly be abused with individuals "going dark" and leaving the burden of the sprint commitment with the rest of the team.

Another approach I've seen used is an "Innovation Day".  This is a plan day (or days) where the team is encouraged to innovate.  Its free form.  Individual activities may be pursued or the team may self organize into sub teams.  Have some fun with this.  It can be used as a tool for the team to relax and let off some steam after a major development efforts.  Also, you can have awards for the innovation.  Most creative, most utility, most ridiculous, ...

Lastly there is the "Innovation Spike" (a nod to Kent Beck's Architectural Spike here).  Jeff McKenna and I came up with this approach over one of the many discussions (therapy sessions) that Jeff and I enjoy together!  The innovation spike can be planned and managed in the context of prescriptive Scrum.  Here's how it works.  Firstly, you've got to decide to perform an Innovation Spike.  This will require buy-in and support from management, product owners, and the team.  If you can't get buy in, then forget about it. 

Assuming your selling skills are well honed and you've got buy-in, the first thing the Scrum Master will do is decide how much time to allocate to the innovation spike.  Don't over-engineer this.  Lets assume we have a team 9 people that has a velocity 45.  The Scrum Master decides to allocate two resources to the innovation spike.  The allocation of resources to a spike should be managed as well.  The selection should be open and transparent and an all inclusive rotation should be established.  The Scrum Master will then create a User Story titled "Innovation Spike" for the sprint with a story point estimate of 10 points.  The estimate is calculated by dividing the team's velocity by each resource's average contribution to the velocity.  This approach will keep the team's sprint to sprint velocity consistent.

So in review, here are three proposed ways of managing innovation with Scrum

• Informally
• Innovation Days
• Innovation Spikes

That's great you might say.  But what do we do with the cool new code, prototype, mock-up, or whatever that gets produced as a result of the innovation.  Just check it in, right?  WRONG!  The result of the innovation may be completely throw away.  It needs to make its way into the product using the prescriptive process.  Its evaluated in the context of the other items of the backlog.  The Product Owner makes an explicit decision to move it into a sprint.  Appropriate User Stories, Unit Tests, and Acceptance Tests are built, it's coded, and finally accepted into the sprint/product.

I've always felt, and said, that agile is a means to an end, not the end in and of itself.  So what is the end?  That's a rhetorical question of course.  The reason we build software systems is to deliver value to our customers or to the business.  Even a CMMI level 5 agile implementation will fail if its not driven in a manner that is delivering value.  I like to abstract the software value stream as follows:

Demand flows into the funnel in a variety of forms.  If you have an existing product, application or service, it may be an enhancement request or defect reported by a customer or user.  Or perhaps, a line of business you support may request a major new service in support of a new business initiative.  The request needs to be evaluated and measured not only against other new requests, but its value should also be assessed against existing products/applications/services in the portfolio.  It may make sense to eliminate or defer and existing investment in favor of the new request to optimize software value creation.

We can create and integrate the software value using traditional or modern (agile) approaches.  A traditional approach if well executed will deliver the value in a "big-bang" release.  There are some advantages with that.  But with current macro-economic conditions, wouldn't it be wise to deliver software value early and often.  With its proven models of incremental development, that's what agile promises.

We've must be persistent and rigorous in managing software value creation.  For every new asset we create, there is typically an ongoing investment required to support its operation and maintenance.  So if we're not diligent about managing the end of life of our assets, the aggregate maintenance cost will eventually dominate your budget and application development will be consume with keep-the-lights on activities rather than growing and transforming the business.