Dr. Dobb's | Iteration Negative One

Much of what occurs during Iteration -1 involves the preproject aspects of portfolio management.

It was a bright and sunny day, and suddenly an agile software development project began. The previous day, someone had an idea for a new system and decided that an agile team should be formed to build that system. So she mentioned the idea to both her business and IT colleagues and they all agreed that it was a good idea to do this. Luckily, sufficient funding was available and a qualified agile development team was waiting to be put to work. More importantly, no one else had plans for either the funds or the project team. With full stakeholder support, funding, and the right people for the job, the project was off to a great start.

If only it were that easy. Getting a project started is often a long and difficult process involving significant political maneuvering over many months, if not years. Organizations have limited resources and many opportunities in which to invest those resources. As a result, you must choose wisely when it comes to starting up a potential IT project if you want to truly maximize stakeholder return on investment (ROI). This is true of any IT project, including agile ones.

A common concept within the agile community is that of "Iteration 0," called "Sprint 0" by Scrum teams, which I described in "Initiating an Agile Project" (www.ddj.com/architect/188700850). It is during this iteration that you do the fundamental work of getting your project team organized. You'll do some initial requirements envisioning to better understand the scope, and more importantly drive your myriad of stakeholders to a reasonable concurrence as to that scope. You'll also do some initial architectural envisioning to identify a potential technical strategy. In parallel, you will be bringing people into the team, setting up workstations, doing initial planning, and whatever else it takes to initiate the project. These activities are all important, but they presume that someone has made the decision to go ahead with the project to begin with. So this "first" iteration, which we originally tacked on to most agile methods once our exuberance wore off and we realized that there was a bit more to software development than construction, isn't really the first iteration after all because work occurs before Iteration 0 can begin. To keep the number scheme consistent let's call this "Iteration -1" ("Sprint -1" for the Scrummers among us).

Iteration -1 is something that Mike Vizdos, of Implementing Scrum (www.implementingscrum.com) fame, and I called the "preInception phase" in the Enterprise Unified Process (EUP) (www.enterpriseunifiedprocess.com). The EUP expands upon the system development lifecycle (SDLC) to address the full IT lifecycle. Figure 1 shows the full lifecycle for agile within IT organizations, depicting the difference in methodology scope. SDLCs focus on developing a release of a system, whereas a system lifecycle addresses the full life of a system, from the initial concept all the way until it is finally retired and pulled completely from production. The IT lifecycle encompasses the activities required for all of the systems that support your organization, adding cross-system issues such as portfolio management, enterprise architecture, and reuse into the mix.

[Click image to view at full size]

Figure 1: High-level Agile IT lifecycle. Agile projects must fit into the overall IT lifecycle just like nonagile projects.

Agile Portfolio Management

Much of what occurs during Iteration -1 is the preproject aspects of portfolio management. When a project is first proposed, an initial investment will be made in defining it, identifying a viable strategy for the project, and assessing its feasibility. This effort can and should be as agile as you can possibly make it—you should collaborate with stakeholders who are knowledgeable enough and motivated enough to consider this potential project and invest in just enough effort to decide whether to consider funding it further.

To define the project further you will want to look at the bigger business picture and focus on market concerns. This includes exploring how the new functionality will improve your organization's presence in the market, how it will impact profitability, and how it will impact the people within your organization. This exploration effort should be brief—not all projects will make the initial cut so you only want to invest enough effort at this point to get a good "gut feel" for the business potential.

Although traditional methodologies will recommend developing a vision document, I prefer Outside-In Development's (www.outside-in-thinking.com) focus on identifying the potential stakeholders and their goals, key information to help identify the scope of the effort. At this point in time, strategic business ideas start to turn into tactical decisions, something that will continue into Iteration 0 and beyond. Yes, there's a fuzzy line between Iteration -1 and Iteration 0 efforts—your organization must implement these activities in a manner that fits the context of your own unique situation.

There are several issues to consider when identifying a potential strategy for the project. For example, do you build a new system or buy an existing package and modify it? If you decide to build, do you do so onshore or offshore? Will the work be solely done by your own development team, by a team from a system integrator (SI), or in partnership with the SI? What development paradigm—traditional/waterfall, iterative, or agile—will you follow? Will the team be collocated, near-located within the same geographic region, or far-located around the world? As you can see, there are many combinations of strategies available to you, and at this point you may only be able to narrow the range of the possibilities but be forced to leave the final decision to the project team in future iterations.

During Iteration -1 you will want to do just enough feasibility analysis to determine if it makes sense to invest in the potential project. Depending on the situation, you may choose to invest very little effort in considering feasibility; for many systems, just considering these issues for a few minutes is sufficient, whereas for some systems you may choose to invest days, if not weeks, exploring feasibility. Many organizations choose to do just a little bit of feasibility analysis during Iteration -1, and then if they decide to fund the project, they will invest more effort during Iteration 0.

Your feasibility analysis efforts should also produce a list of potential risks and criteria against which to make go/no-go decisions at key milestone points during your project. The various flavors of the Unified Process (UP)—such as OpenUP, Rational Unified Process (RUP), and Agile UP—have specific milestone reviews that are critical decision points that enable effective portfolio management. Dr. Dobb's 2007 Project Success Survey ("Defining Success," www.ddj.com/architect/202800777) found that agile teams reported a success rate of 72 percent (traditional projects had a success rate of 63 percent), implying that almost 30 percent of agile projects are considered failures. Disciplined agilists know that you also need to question the feasibility of the project throughout the lifecycle: Just because you're delivering working software on a regular basis doesn't mean that it's a good idea to do so.

Agile Enterprise Modeling

As Figure 1 depicts, portfolio management activities don't exist in a vacuum—they're supported by both enterprise business modeling and by enterprise architecture modeling. In the EUP, we split these two disciplines, with enterprise business modeling focused on the business side of the enterprise and enterprise architecture focused on the technical aspects that support the business. Many organizations, particularly mid-size ones, choose to combine these two disciplines because the people performing them work closely together and are often one and the same. Each strategy has its strengths and weakness, so choose the approach best suited to your organizational culture. Enterprise models are crucial for identifying potential systems, determining feasibility, and identifying viable implementation strategies because they provide context for these efforts.

Unfortunately, many agilists are leery of enterprise modeling due to the many anti-patterns exhibited by traditional enterprise modelers (see www.agilemodeling.com/essays/ enterpriseModelingAntiPatterns.htm). Many traditional enterprise modeling efforts run aground when the enterprise modelers focus just on modeling and not on executing the concepts captured in the models. If you choose, enterprise-level modeling can in fact be performed in an agile manner, and at www.agiledata.org/essays/enterpriseArchitecture.html, I describe a collection of techniques for doing exactly that. The main strategies are to keep the documentation light, to work iteratively and collaboratively, and to work actively with the development teams to implement the systems called out in the enterprise models.

The length of Iteration -1 will vary by organization and by system. Sometimes a potential project is identified, fast-tracked, and initiated in a matter of weeks. Sometimes a project languishes in your stack of potential projects for months or even years before it receives funding to kick off Iteration 0. The portfolio management activities encapsulated in Iteration -1 are critical to the success of your IT organization, making Iteration -1 an important part of your overall system lifecycle.

Thanks to Sally Elatta for the interesting conversation that we had around this topic.