Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Governing Agile Software Development

Greater Stakeholder Control

With the approach in Figure 1, stakeholders can change their requirements at any time, they can add new ones, and they can reprioritize existing ones, putting them in complete control of the scope. This works when the development team writes high-quality code that is loosely coupled and highly cohesive, when they refactor when required to keep their design of high quality, and when they have a regression test suite, which they run regularly. It's very easy to add new functionality to an existing code base in this sort of situation, particularly when the team invested a bit of time at the beginning of the project envisioning the architecture with a bit of initial Agile modeling.

Because Agile teams ask stakeholders each iteration how much they want to invest, our stakeholders are effectively in control of the budget—and rightfully so seeing as it's their money that is being spent. When stakeholders have insight into the actual status of a project team, and when they can change the funds that each team receives each iteration, they're in a position to actually govern IT projects. Figure 2 shows the current status of a collection of software development projects. The height of each stack indicates the relative amount of work the individual teams have left, the color of the stack indicates the current status, and the number of the top of the stack indicates the expected ROI of the system under development. With this sort of information, stakeholders can make intelligent governance decisions. For example, the projects with red status clearly need to be redirected, and I'd even consider canceling the low ROI one at this point. The yellow status projects also could use some help. From a portfolio-management point of view, I'd consider increasing the funding to the high-ROI green teams because I want to put my money into successful teams that provide the greatest value. In other words, with an Agile approach, stakeholders can start treating their IT investment as an investment. Following a traditional approach, it often seems that money spent on IT is more of a gamble than an investment, and I think that it's because of the lack of visibility and control that traditional teams provide to stakeholders.

[Click image to view at full size]

Figure 2: Continuous monitoring of teams.

Stakeholders are put in control of the schedule as a side effect of producing working software each iteration: We can be six months into a project and the stakeholders can tell us that we've delivered sufficient functionality to justify delivery into production. In combination with working in priority order, they can drive Agile development teams to deliver a system to the marketplace at the earliest opportunity.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.