Funding Software Projects

What does it mean for the enterprise to be agile?

What does it mean for the enterprise to be agile?Closely allied to establishing the business objectives in adopting agile practices, an understanding of what it means for an enterprise to be agile should be clear to everyone in the enterprise. This post summarizes what it means for an enterprise to be agile from the perspective of the senior executives and stakeholders.

“Agile” is a set of behaviors that help a business achieve its objectives. The most prevalent agile practice, Scrum, defines a set of project management-based behaviors that help practitioners (especially software practitioners) achieve those objectives. However, little is said in Scrum about how to be agile outside of the immediate environment of the Scrum teams. Team agility does not automatically engender enterprise agility.

Deciding where a so-called value chain starts and ends is going to vary according to the individual enterprise considerably, according to factors such as size, business area, degree of specialization, vendors and suppliers as part of the larger value chain (or even ‘ecosystem’). However, this is a bit like a “5 WHYS” analysis, you have to recognize where it makes sense to stop the analysis at. Mostly, a company’s corporate boundary makes a natural place to stop (though ideally the whole external supply chain would be synchronized and agile). However, this may be too great a challenge for many organisations to begin with, so smaller organizational units and business units within the enterprise may have to suffice for the initial vision and implementation.

As a reference point, for a hardware-based product company, the groups that might be considered for inclusion in the scope for enterprise agility could look like: Sales, Marketing, HR, Executive Management, Software Engineering, Hardware Engineering, Product Definition, Product Releasing, Product Testing, Technical Documentation, Project Management, Programme Management, Quality Assurance. Where any of these groups are excluded, there will probably be a detrimental reduction in overall agility.

Here are some of the major characteristics that an agile enterprise will typically exhibit, at the ‘manager’ and ‘senior executive’ levels (some apply more to some groups than others):

  • Commitment through close involvement and engagement with agile teams
  • Removal of organisational impediments and issues
  • Flexibly determining release content and being responsive to change: based on sustainable organisational capacity and economic value (including cost of delay); taking into account (test) results and feedback
  • Be Servant Leaders: inspire, motivate, lead by example: including: allowing teams to self-organise - “Self-organisation does not mean that workers instead of managers engineer an organisation design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviours that emerge from the interaction of independent agents instead of specifying in advance what effective behaviour is.” – Philip Anderson, The Biology of Business
  • Demonstrating trust, especially in avoiding delving into (and controlling) the detail: but note also that trust is engendered by successful delivery
  • Focusing on throughput of (valuable) work rather than on 100% Resource Utilization
  • Recognizing the differences between repeatable and highly variable knowledge work (avoid purely “widget engineering”)
  • Evolving legacy practices into new (e.g. by evaluating and challenging old Ways of Working): powerful corporate forces can be afoot, so this is not easy.

Leffingwell’s Scaled Agile Framework provides a suitable structure for scaling Scrum to enterprise levels and fills in on many of the executive roles and functions required for success in agile at the enterprise level.

Some useful links:

Next Stop Agile: All Change?

“Before we become agile, do we really need to change everything?”

I was recently asked this question by a client who is just starting on their agile journey.

The potential of agile to change everything often leads people to think that they have to change everything before they can become agile. Instead of seeing opportunities and potential they see obstacles and barriers, to the extent that they’re sometimes too scared to even dip their toes in the agile waters.

The introduction of agile values, and in particular agile practices such as iterative planning and backlog-driven development, will lead to changes in the quality and timeliness of the software produced. This in turn will provide you with lots of opportunities to improve other things such as organizational structures, communication channels, and funding procedures.

To get started there are a few things that definitely need to be changed. These will be focussed in three key areas:

  • Resourcing teams – the agile and iterative approach requires cross-functional teams. Testers for example will now be needed through-out the project, as will test environments;
  • Reporting progress – the regular iterative assessments can be used to replace monthly or other reports. There will be a switch towards concrete measures and away from “pseudo-measures” such as earned value;
  • Planning projects – projects will now be iterative and incremental rather than waterfall. The number and nature of the milestones will change, although you may choose to start your initial agile projects with a “requirements” phase and end with and “acceptance testing” phase. Note: the development will still be done iteratively with testing done every iteration - there will just be some priming of the pump before the iterations start, and some additional acceptance testing once the development is complete.

Once the teams have developed the capability to produce high quality software quickly and effectively, the door opens for even more improvements – in particular:

  • Just in time and just enough requirements – affecting the product owners, product managers and the business
  • Progressive funding models – affecting how you fund your projects
  • Agile contracts with suppliers – affecting your supplier relationships and contracts
  • Improved team cohesion and longevity – affecting line management and resourcing
  • Agile business change – affecting business projects and business programmes
  • Tools and infrastructure – affecting licensing and environments

And finally, opportunities are opened up for an agile organization, with further improvements to:

  • Line management
  • HR
  • Governance
  • Organizational Structures
  • Company Culture

It is always a good idea to brief all the management and business people involved in the projects and teams as they will be affected by the initial round of change, and will benefit from seeing the opportunities that an improved, agile, software development approach will provide.

The good thing is you don’t need to change everything at once, or even at all in many cases. Personally I would always bed in the first round of changes before worrying about the second and third lists of things. This approach values individuals and interactions over processes and tools, as it enables the development teams to improve without dictating to the other parties involved in the business. Once they see the opportunities opened up by agile development practices they will also want to embrace agility and improve their own ways of working.

Funding New Projects

In a prior blog entry I noted the traditional approach to funding new development efforts:

  1. the business gets an idea and writes a few sentences of description,
  2. IT tries to figure out what the business really meant and comes up with an estimate based on their best guess, and
  3. this amount gets locked in as a "committed" estimate to which IT is held accountable. 

The only thing that should be committed is the people who think this is a sane approach to funding projects.

A better model works like this:

  • The business identifies a set of desired business outcomes that they would like to achieve, along with the net present value of achieving those desired outcomes.
  • Based on this value, the business decides how much it is willing to spend to achieve those desired outcomes.  Usually this is based on the required rate of return of investments in the business.  This amount establishes an upper limit on the project that could deliver those outcomes.
  • The IT planning process then focuses on determining whether the desired outcomes can be achieved within the constraints established by the business planning process.  If they cannot, further funding for the project is stopped and more worthy projects are funded.  Several alternative approaches may be tried and rejected, and deciding project feasibility may require some prototyping and evaluation to determine viability.

This is how research and development funding works and, let's face it, software development has a lot in common with R&D: both deal with a lot of unknowns at the start of a project, so much so that it is usually not possible to precisely define the exact work that will be needed to achieve a particular end.  Both R&D and software are essentially exploratory: at the beginning of the effort the exact result is not known with a high degree of assurance so we have to evolve toward a solution.  The current funding model's assumptions that the solution is easily definable and therefore should be easy to estimate just doesn't work for most new software development efforts.

Fixed Scope + Fixed Schedule + Fixed Budget = Certain Failure

It is that time of year again, when organizations are putting the final touches on their project funding plans for tomorrow.  Over the past several months, a strange tale has played out across the globe, a farcical tale that if you tried to tell anyone outside IT about they would scarcely believe you.  It plays out like this:

Someone in the business gets something resembling an idea - not something fully formed, but at least an inkling that suggests that there might be some benefit achieved in developing something.  A few sentences are written about it and here is where the silliness begins.  All these little fragments of ideas are gathered together and then IT is asked to estimate the cost and schedule - based on little more than the few sentences of description.  If they are lucky they might get to ask some questions.

Everyone knows this is ludicrous, they will say, but they say they have no choice.  They put all manner of disclaimers on the estimates but these are forgotten over time.  What is recorded and remembered is a time and dollar cost estimate for each project - based on, remember, a few sentences of description.  This sounds so absurd that I know you would be laughing if you did not see it every year in your own organization.  But wait, it gets worse. Read More