Channels ▼
RSS

C/C++

Scaling Scrum


The Full Development Picture

Construction is only one part of the overall software development lifecycle. Figure 2 presents an overview diagram of the Agile lifecycle which encompasses the ideas presented in Figure 1 and extends them to address the full range of software development issues. This lifecycle explicitly includes the concept of phases because the activities that you perform do in fact change throughout the span of a project. I've adopted the normalized terminology described in the sidebar plus other common agile phase terminology—many agile teams refer to project initiation effort as "iteration 0" and transition as the release phase. In the Eclipse Way, the Agile process followed by the Eclipse development team, they use the terms "warm up" and "end game" respectively. In Agile and Iterative Development (Addison Wesley, 2004), Craig Larman uses the terms "pre-game" and "release" for these phases. The Open Unified Process (OpenUP) uses the terms Inception and Transition respectively. Sadly, many people consider the concept of phases to be antithetical to agility, yet in practice they seem to be a fundamental lifecycle concept.

Figure 2 encompasses several critical activities to scale Scrum to meet your real-world development needs:

  • You need to do some initial requirements and architecture envisioning at the beginning of the project to address basic questions around scope, cost, schedule, and technical strategy. Few projects are funded without acceptable answers to these issues.
  • To ensure the quality of your work, you should have an independent test team that works in parallel to the development team. This team reports change stories back to the team who then treats them exactly like a requirement—they're estimated, prioritized, and put on the work item stack (see "Scaling Test-Driven Development", www.ddj.com/architect/205207998).
  • The "work item stack" contains all of the potential items of work that a team may need to address, not just stakeholder requirements. For example, you need to set up people's workstations, fix defects, people attend training, they take vacations, they review the work of other teams, and so on. These are important activities that must be planned for accordingly.
  • Iterations can be any length, not just 30 days, and an individual team needs to determine which is best for them. As Dr. Dobb's 2007 Agile Adoption Survey (www.ddj.com/architect/200001986) found, the most popular iteration length is two weeks.
  • Effective agile teams prove their architecture with code early in the project (this is the Elaboration part of Elaboration and Construction). Although purists claim that you should prioritize based solely on business concerns, the reality is that it behooves you to address technically risky requirements early in the lifecycle. Luckily, business value and technical risk often go hand-in-hand, so you rarely need to "game" your work item stack much to accommodate this strategy.
  • The Transition phase provides time to successfully release software into production. This effort includes training people, finalizing testing, finalizing documentation, pilot/beta testing, and deploying the system; see "The Agile End Game" (www.ddj.com/architect/198800565) for more detail.
  • Enhancement requests and defect reports are identified once the system is in production and treated as new work items that must be prioritized.

[Click image to view at full size]

Figure 2: The Agile Software Development Lifecycle. The full development lifecycle must address project initiation, construction, and deployment.

Since the late 1990s, I've written that effective software development is serial in the large, iterative in the small, delivering incremental releases over time. Over the past few years the rhetoric around agile software development has unfortunately drowned out the "serial in the large" part of the message, forcing many people to rediscover proven techniques and strategies. If the lifecycle of Figure 2 makes sense to you, and you'd like to extend Scrum to address these issues, I suspect that you'll find that the OpenUP, downloadable free of charge at www.eclipse.org/epf, will be of interest to you.


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.
 

Video