August, 2013
There seems to be considerable debate and confusion
surrounding the concept of estimation as applied in the agile world. Many appear to argue that estimation has no
meaning outside of the agile team, but sponsors and stakeholders need something
to base their decisions on and estimation is a key component of it. Perhaps we need to reengineer our definitions
and objectives at the higher level.
Typically, management wants to know how much X will cost and how long it will take to deliver before
making the investment; where X is some bundle of deployed functionality with an
associated business value. Not an unreasonable
request in a traditional environment where the application is the focus of attention.
The investment decision is how much greater is the value than the cost (the
ROI). Unfortunately, the estimation process is subject to considerable
uncertainty prior to the initial stages of architecture and design (the
uncertainty decreases with subsequent stages but does not reach zero until
completion and deployment – and then the estimation of the O&M stage
begins) – not a good foundation to base investment decisions on.
If we change our focus from applications to delivering
business capabilities and adopt an agile development process, the concept of
estimation changes as well. For example,
in traditional (stovepiped) development much of the development is actually
producing redundant functionality (in terms of delivering business and
technical capabilities), but this is obscured by the focus on the app. For example, all apps provide error handling
and audit logging as well as security (authentication and authorization) – how many
times have these been (re)developed? The
same applies to business-related capabilities. If we can take a broad view of the
capabilities required and identify sources for providing them, much of the development
may be avoided altogether. This, of
course, is the benefit from adopting a SOA approach. If we adopt an agile development methods and
establish an agile team with an associated cadence, the estimation question
should be something more like: how much
value can we produce in a given amount of time?
Given that the team has a
cost for a given period of time (say, a year), and each delivered business
capability has a known value, we can still make investment decisions – what is
the net value produced from the investment cost.
Economics would say you should invest up to the point where
the marginal value derived equals the marginal cost of producing the next
increment of functionality (stories, capabilities). From this increments perspective, we should
expect the marginal value to be decreasing – because we are developing from the
product backlog in order of priority – so we build the highest valued items
first. Marginal cost should be flat or
decreasing as well – the cost of the team may be constant, but the cost of
producing the next item may go down as we build up and consume more (pre-existing)
shared services.
So, the investment decision changes from: is it worth
building this app? to is it worth funding
this agile development team for a year?
This approach can be applied to determine how big the team should be and
even how many teams should we engage. The
value delivered should be maximized because the most valuable capabilities are
delivered first (along with the capabilities they are dependent on). This should hold even if the priorities
change because the product backlog embodies those priorities.
