Channels ▼


Disciplined Agile Change Management

Work Item Pools

One lean approach to work item management is to treat work items as if they're in an options pool, not an ordered stack. This strategy explicitly recognizes that there are different ways to prioritize work items — the "standard way" based on stakeholder value, time-dependent strategies with defined delivery dates, the occasional emergency/high-priority work item that must be expedited, and the intangible team health work items captured in personal requests. Anyone can identify work items and place them in the pool, although the product owner (if one exists) is most likely to focus on doing so. The entire team, including the product owner, is responsible for pulling work from the work item pool appropriately. A particular work item is determined whenever the team has the bandwidth to pull new work into their process.

The primary advantages of this approach are that it is flexible enough to address several prioritization schemes and that it doesn't require any investment in backlog/stack grooming.

The disadvantages are that it requires teams to be responsible and disciplined enough to pull work out the pool in a fair and appropriate manner. This discipline requires teams to consider a variety of issues, including stakeholder value, risk, team health, and enterprise issues. This method also can be very threatening to traditional organizations accustomed to telling teams what the priorities are. It requires strict control over the number of work items to be expedited (everything can't be of utmost priority, otherwise the other categories are never addressed). Another common problem is that teams new to agile/lean may prioritize team health considerations or infrastructure work over delivering stakeholder value. This strategy really does require significant discipline to pull off.

No Strategy At All

Finally, there is always the option of having no change strategy at all. This nonexistent strategy is valid for very small or simple projects. The primary advantage is that there is no overhead to this approach. The primary disadvantage is that there is significant potential for low value work to be implemented because nobody is prioritizing things. My experience is that the no-strategy approach is a sign of an ad-hoc project team posing as an agile team.

Choice Takes Discipline

In most situations, my advice is to adopt the work item stack approach because it is fairly straightforward and workable for most situations. Then, after you become comfortable with it (and if your organizational culture allows it), move towards the lean work item pool strategy. You should adopt a formal change management process only when it is actually mandated by regulations. If you are in a regulatory compliance situation, you should closely read the regulations to ensure that you're not over-complicating your compliance strategy.

The primary point of this article is that each of these strategies has advantages and disadvantages and none of them is perfect. Your team will need the discipline to choose the strategy that is best suited for your situation. The DAD framework provides contextual advice to help you navigate these important process decisions, but these are ultimately decisions that you must make.


Visit the Disciplined Agile Delivery website for more information about the DAD process framework.The Disciplined Agile Delivery book is described there in further detail.

The article Examining the Big Requirements Up Front (BRUF) Approach summarizes the disadvantages of taking a BRUF approach to requirements specification.

Acceptance test driven development (ATDD) is overviewed in the article Agile Testing and Quality Strategies.

A comprehensive approach to dealing with non-functional requirements (NFRs) is described in Beyond Functional Requirements on Agile Projects.

The challenges surrounding traditional change management are described in The Change Prevention Anti-Pattern.

The Agile Scaling Model (ASM) is a PDF document that describes eight software process scaling factors (team size, geographical distribution, regulatory compliance, domain complexity, technical complexity, organizational distribution, organizational complexity, and enterprise discipline) and overviews how they affect your agile strategy.

The Surveys Exploring the Current State of Information Technology Practices page links to the results of all the Dr. Dobb's surveys that I've run over the years.

My [email protected] blog discusses strategies for adopting and applying agile strategies in the complex environments.


Dr. Dobb's invites you to fill out the June 2012 State of the IT Union Survey. The goal of this ongoing survey series is to find out what IT professionals are actually doing in practice. The survey takes about 5 minutes and your privacy will be completely protected

At the end of the survey, you will be given the chance to be entered into a draw for one of ten copies of Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise by Scott W. Ambler and Mark Lines, published by IBM Press in June 2012.

The survey results will be summarized in a forthcoming article by Scott Ambler. Furthermore, this is an open survey, so the source data (without identifying information to protect your privacy), a summary slide deck, and the original source questions will be posted at so that others can analyze the data for their own purposes. Data from previous surveys have been used by university students and professors for their research papers, and the same will surely be true of the data from this survey. The results from several other surveys are already posted there as well, so feel free to take advantage of this resource.

Scott Ambler is a Senior Contributing Editor to Dr. Dobb's. Follow him on Twitter.

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.