Ambysoft Essays About Education

On By In 1

Examining the Agile Manifesto

To address the challenges faced by software developers an initial group of 17 methodologists formed the Agile Software Development Alliance (, often referred to simply as the Agile Alliance, in February of 2001. An interesting thing about this group is that they all came from different backgrounds, yet were able to come to an agreement on issues that methodologists typically don’t agree upon. This group of people defined a manifesto for encouraging better ways of developing software, and then based on that manifesto formulated a collection of principles which defines the criteria for agile software development processes. The manifesto defines four values and twelve principles which form the foundation of the agile movement.

The Agile Values

The important thing to understand about the four value statements is that while you should value the concepts on the right hand side you should value the things on the left hand side (presented in red) even more.A good way to think about the manifesto is that it defines preferences, not alternatives, encouraging a focus on certain areas but not eliminating others. The values of the Agile Manifesto are:

  1. Individuals and interactions over processes and tools. Teams of people build software systems, and to do that they need to work together effectively – including but not limited to programmers, testers, project managers, modelers, and your customers. Who do you think would develop a better system: five software developers and with their own tools working together in a single room or five low-skilled “hamburger flippers” with a well-defined process, the most sophisticated tools available, and the best offices money could buy? If the project was reasonably complex my money would be on the software developers, wouldn’t yours? The point is that the most important factors that you need to consider are the people and how they work together because if you don’t get that right the best tools and processes won’t be of any use. Tools and processes are important, don’t get me wrong, it’s just that they’re not as important as working together effectively. Remember the old adage, a fool with a tool is still a fool. As Fred Brooks points out in The Mythical Man Month, this can be difficult for management to accept because they often want to believe that people and time, or men and months, are interchangeable.

  2. Working software over comprehensive documentation. When you ask a user whether they would want a fifty page document describing what you intend to build or the actual software itself, what do you think they’ll pick? My guess is that 99 times out of 100 they’ll choose working software. If that is the case, doesn’t it make more sense to work in such a manner that you produce software quickly and often, giving your users what they prefer? Furthermore, I suspect that users will have a significantly easier time understanding any software that you produce than complex technical diagrams describing its internal workings or describing an abstraction of its usage, don’t you? Documentation has its place, written properly it is a valuable guide for people’s understanding of how and why a system is built and how to work with the system. However, never forget that the primary goal of software development is to create software, not documents – otherwise it would be called documentation development wouldn’t it?

  3. Customer collaboration over contract negotiation. Only your customer can tell you what they want. Yes, they likely do not have the skills to exactly specify the system. Yes, they likely won’t get it right the first. Yes, they’ll likely change their minds. Working together with your customers is hard, but that’s the reality of the job. Having a contract with your customers is important, having an understanding of everyone’s rights and responsibilities may form the foundation of that contract, but a contract isn’t a substitute for communication. Successful developers work closely with their customers, they invest the effort to discover what their customers need, and they educate their customers along the way.

  4. Responding to change over following a plan. People change their priorities for a variety of reasons. As work progresses on your system your project stakeholder’s understanding of the problem domain and of what you are building changes. The business environment changes. Technology changes over time, although not always for the better. Change is a reality of software development, a reality that your software process must reflect. There is nothing wrong with having a project plan, in fact I would be worried about any project that didn’t have one. However, a project plan must be malleable, there must be room to change it as your situation changes otherwise your plan quickly becomes irrelevant.

The interesting thing about these value statements is there are something that almost everyone will instantly agree to, yet will rarely adhere to in practice. Senior management will always claim that its employees are the most important aspect of your organization, yet insist they follow ISO-9000 compliant processes and treat their staff as replaceable assets. Even worse, management often refuses to provide sufficient resources to comply to the processes that they insist project teams follow.Everyone will readily agree that the creation of software is the fundamental goal of software development, yet insist on spending months producing documentation describing what the software is and how it is going to be built instead of simply rolling up their sleeves and building it. You get the idea – people say one thing and do another. This has to stop now. Agile developers do what they say and say what they do.

Ambler's Observation:

It's generally not a good idea to mess with people
who issue manifestos. ;-)

The Agile Principles

To help people to gain a better understanding of what agile software development is all about, the members of the Agile Alliance refined the philosophies captured in their manifesto into a collection of twelve principles. These principles are:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. For some reason many people within IT have seem to have forgotten that the goal of software development should be the development of software. Or, perhaps the problem is that they think that they need to define everything up front before they can start building software, whereas an evolutionary approach to development seems to work much better.

  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Like it or not, requirements will change throughout a software development project. Traditional software developers will often adopt change management processes which are designed to prevent/reduce scope creep, but when you think about it these are really change prevention processes, not change management processes. Agilists embrace change and instead follow an agile change management approach which treats requirements as a prioritized stack which is allowed to vary over time.

  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. Frequent delivery of working software provides stakeholders with concrete feedback, making the current status of your project transparent while at the same time providing an opportunity for stakeholders to provide improved direction for the development team.

  4. Business people and developers must work together daily throughout the project. Your project is in serious trouble if you don't have regular access to your project stakeholders. Agile developers adopt practices such as on-site customer and active stakeholder participation, and adopt inclusive tools and techniques which enable stakeholders to be actively involved with software development.

  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Too many organizations have a vision that they can hire hordes of relatively unskilled people, provide them with a CMMI/ISO/...-compliant process description, and that they will successfully develop software. This doesn't seem to work all that well in practice. Agile teams, on the other hand, realize that you need build teams from people who are willing to work together collaboratively and learn from each other. They have the humility to respect one another and realize that people are a primary success factor in software development.

  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. For a software development team to succeed its members must communicate and collaborate effectively. There are many ways which people can communicate together, and as you can see face-to-face communication at a shared drawing environment (such as paper or a whiteboard) is the most effective way to do so.

  7. Working software is the primary measure of progress. The primary measure of software development should be the delivery of working software which meets the changing needs of its stakeholders, not some form of "earned value" measure based on the delivery of documentation of the holding of meetings.

  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Just like you can't sprint for an entire marathon, you can't successfully develop software by forcing people to work overtime for months at a time. My experience is that you can only do high-quality, intellectual work for 5-6 hours a day before burning yourself out. Yes, the rest of the day can be filled up with email, meetings, water cooler discussions, and so on, but people's ability to do "real work" is limited. Yes, you might be able to do high-quality work for 12 hours a day, and do so for a few days straight, but after awhile you become exhausted and all you accomplish is 12 hours of mediocre work a day.

  9. Continuous attention to technical excellence and good design enhances agility. It's much easier to understand, maintain, and evolve high-quality source code than it is to work with low-quality code. Therefore, agilists know that they need to start with good code, to keep it good via refactoring, and take a test-driven approach so that they know at all times that their software works. We also adopt and follow development guidelines, in particular coding guidelines and sometimes even modeling guidelines.

  10. Simplicity – the art of maximizing the amount of work not done – is essential. Agile developers focus on high value activities, we strive to maximize our stakeholder's return on investment in IT, and we either cut out or automate the drudge work.

  11. The best architectures, requirements, and designs emerge from self-organizing teams. This is one of the most radical principles of the agile movement, one which I would love to see researched thoroughly by the academic community. The Agile Model Driven Development (AMDD) and test-driven design (TDD) methods are the primary approaches within the agile community for ensure the emergence of effective architectures, requirements, and designs.

  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Software process improvement (SPI) is a continual effort, and techniques such as retrospectives should be adopted to enable you to improve your approach to software development.

Stop for a moment and think about these principles. Is this the way that your software projects actually work? Is this the way that you think projects should work? Re-read the principles once again. Are they radical and impossible goals as some people would claim, are they meaningless motherhood and apple pie statements, or are they simply common sense? My belief is that these principles form a foundation of common sense upon which you can base successful software development efforts.

Why is This Important?

The Agile Manifesto provides a philosophical foundation for effective software development. Contrary to some of the criticisms you may have heard from the traditional community, the fact is that the agile movement is based on some very solid concepts and the methodologies clearly reflect that. Unfortunately the agile community currently suffers from low-end hackers claiming to be agile (e.g. the "we don't document therefore we're agile" crowd) and many traditionalists jump on that and say that agile is a bad idea. Yes, the "code-and-fix" approach to development is a bad idea, but code-and-fix isn't agile regardless of what these clowns claim. You might find my article The Criteria for Determining Whether a Team is Agile of interest because it describes how to determine if a team is truly agile or not and my The Threat of The New article which examines agile myths and misconceptions.


I'd like to thank Stan James, Lasse Koskela, and Ilja Preuss for their feedback regarding this article.

Suggested Reading

This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise describes the Disciplined Agile Delivery (DAD) process decision framework. The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation for scaling agile. This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting. Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process. Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams. Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process.

Are you being asked to manage a project with unclear requirements, high levels of change, and/or a team using Extreme Programming or other Agile Methods? If you are a project manager or team leader who is interested in learning the secrets of successfully controlling and delivering agile projects, then this is the book for you. From learning how agile projects are different from traditional projects, to detailed guidance on a number of agile management techniques and how to introduce them onto your own projects, we have the insider secrets from some of the industry experts – the visionaries who developed the agile methodologies in the first place. Managing Agile Projects is edited by Kevin Aguanno, a noted speaker and educator on agile project management, and includes contributions from many noted figures in the agile movement.

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.

The Agile System Development Life Cycle (SDLC)

I'm often asked by clients to facilitate workshops overviewing the ideas presented in the Agile Manifesto and agile techniques such as Test-Driven Design (TDD), database refactoring, and agile change management. One issue that many people seem to struggle with is how all of these ideas fit together, and invariably I found myself sketching one or more pictures which overview the life cycle for agile software development projects. I typically need one or more pictures because the scope of life cycles change -- some life cycles address just the construction life cycle, some address the full development life cycle, and some even address the full IT life cycle. Depending on your scope, and how disciplined your approach to agile software development is, you will get different life cycle diagrams. Your experience and team culture will also have an affect on the lifecycle you follow, something that we explicitly address in the Disciplined Agile Delivery (DAD) process decision framework.

The goal of this article is to describe the agile system development life cycle (SDLC), putting it in context from what you may have heard about within the agile community and more importantly within the context of your overall IT efforts.

This article covers:

  1. The scope of life cycles
  2. Concept: Pre-planning
  3. Inception
  4. Construction iterations
  5. Release iterations
  6. Production
  7. Retirement
  8. Enterprise IT Lifecycles

1. The Scope of Life Cycles

As we described in the book The Enterprise Unified Process (EUP) the scope of life cycles can vary dramatically. For example, Figure 1 depicts the Scrum construction life cycle whereas Figure 2 depicts an extended version of that diagram which covers the full system development life cycle (SDLC). Later in this article we talk about an Enterprise IT Lifecycle. My points are:

  • Solution development is complicated. Although it's comforting to think that development is as simple as Figure 1 makes it out to be, the fact is that we know that it's not. If you adopt a development process that doesn't actually address the full development cycle then you've adopted little more than consultantware in the end. My experience is that you need to go beyond the construction life cycle of Figure 1 to the full SDLC of Figure 2 (ok, Retirement may not be all that critical) if you're to be successful.
  • There's more to IT than development. To be successful at IT you must take a multi-system, multi-life cycle stage view as we show in the discussion of the Enterprise IT Lifecycles. The reality is that organizations have many potential endeavours in the planning stage (which I'll call the Concept Phase in this article), many in development, and many in production.

Figure 1 uses the terminology of the Scrum methodology. The rest of this article uses the terminology popularized in the mid-1990s by the Unified Process (Sprint = Iteration, Backlog = Stack, Daily Scrum Meeting = Daily Meeting) and also adopted by Disciplined Agile Delivery (DAD). Figure 1 shows how agilists treat requirements like a prioritized stack, pulling just enough work off the stack for the current iteration (in Scrum iterations/sprints are often 2-4 weeks long, although this can vary). At the end of the iteration the system is demoed to the stakeholders to verify that the work that the team promised to do at the beginning of the iteration was in fact accomplished.

Figure 1. The Scrum construction life cycle.

The Scrum construction life cycle of Figure 1, although attractive proves to be clearly insufficient in practice. Where does the product backlog come from? Does it get beamed down from the Starship Enterprise? Of course not, it's actually the result of initial requirements envisioning early in the project. You don't only implement requirements during an iteration, you also fix defects (disciplined agile teams, particularly working at scale, may have a parallel testing effort during construction iterations where these defects are found), go on training, support other teams (perhaps as reviewers of their work), and so on. So you really need to expand the product backlog into a full work items list. You also release your system into production, often a complex endeavor.

A more realistic life cycle is captured Figure 2, overviewing the full agile SDLC. This SDLC is comprised of six phases: Concept Phase, Iteration 0/Inception, Construction, Transition/Release, Production, and Retirement. Although many agile developers may balk at the idea of phases, perhaps Gary Evan's analogy of development seasons may be a bit more palatable, the fact is that it's been recognized that Extreme Programming (XP) does in fact have phases (for a diagram, see XP life cycle).

Figure 2. A detailed agile SDLC.

Figure 3 depicts the agile/basic lifecycle described by the Disciplined Agile Delivery (DAD) framework. This lifecycle originated from earlier versions of Figure 2. Because DAD isn't prescriptive it supports several lifecycles. The lifecycle of Figure 3 is DAD's Scrum-based, or "basic", agile delivery lifecycle but it also supports a lean/Kanban type of lifecycle and a continuous delivery lifecycle (shown in Figure 4) as well. The idea is that your team should adopt the lifecycle that makes the most sense for the situation that you face.

Figure 3. The DAD agile life cycle.

Figure 4. The DAD continuous delivery life cycle.

On the surface, the agile SDLC of Figure 5 looks very much like a traditional SDLC, but when you dive deeper you quickly discover that this isn't the case. This is particularly true when you consider the detailed view of Figure 2. Because the agile SDLC is highly collaborative, iterative, and incremental the roles which people take are much more robust than on traditional projects. In the traditional world a business analyst created a requirements model that is handed off to an architect who creates design models that are handed off to a coder who writes programs which are handed off to a tester and so on. On an agile project, developers work closely with their stakeholders to understand their needs, they pair together to implement and test their solution, and the solution is shown to the stakeholder for quick feedback. Instead of specialists handing artifacts to one another, and thereby injecting defects at every step along the way, agile developers are generalizing specialists with full life cycle skills.

Figure 5. The Agile SDLC (high-level).

2. The Concept Phase: Pre-Project Planning

The Concept Phase, sometimes called Iteration -1, is the pre-project aspects of portfolio management. During this phase you will:

  1. Define the business opportunity. You must consider 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. A good strategy is to follow Outside-In Development's focus on identifying the potential stakeholders and their goals, key information to help identify the scope of the effort.
  2. Identify a viable for the project. 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 co-located, near-located within the same geographic region, or far-located around the world? As you can see there are many combinations of strategy available to you, and at this point in time 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.
  3. Assess the feasibility. During the Concept Phase 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 for now, and 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 the Concept Phase, and then if they decide to fund the project they will invest more effort during Inception. In my experience you need to consider four issues when exploring feasibility: economic feasibility, technical feasibility, operational feasibility, and political feasibility. 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. Remember that agile teams only have a success rate of 72%, compared to 63% for traditional projects, implying that almost 30% of agile projects are considered either challenged or failures. Therefore you should question the feasibility of the project throughout the life cycle to reduce overall project risk.

Concept Phase activities 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 the effort further.

3. Inception/Warm Up: Project Initiation

The first week or so of an agile project is often referred to as "Iteration 0" (or "Cycle 0") or in The Eclipse Way the "Warm Up" iteration. Your goal during this period is to initiate the project by:

  1. Garnering initial support and funding for the project. This may have been already achieved via your portfolio management efforts, but realistically at some point somebody is going to ask what are we going to get, how much is it going to cost, and how long is it going to take. You need to be able to provide reasonable, although potentially evolving, answers to these questions if you're going to get permission to work on the project. You may need to justify your project via a feasibility study.
  2. Actively working with stakeholders to initially model the scope of the system. As you see in Figure 6, during Iteration 0 agilists will do some initial requirements modeling with their stakeholders to identify the initial, albeit high-level, requirements for the system. To promote active stakeholder participation you should use inclusive tools, such as index cards and white boards to do this modeling – our goal is to understand the problem and solution domain, not to create mounds of documentation. The details of these requirements are modeled on a just in time (JIT) basis in model storming sessions during the development cycles.
  3. Starting to build the team. Although your team will evolve over time, at the beginning of a development project you will need to start identifying key team members and start bringing them onto the team. At this point you will want to have at least one or two senior developers, the project coach/manager, and one or more stakeholder representatives.
  4. Modeling an initial architecture for the system. Early in the project you need to have at least a general idea of how you're going to build the system. Is it a mainframe COBOL application? A .Net application? J2EE? Something else? As you see in Figure 6, the developers on the project will get together in a room, often around a whiteboard, discuss and then sketch out a potential architecture for the system. This architecture will likely evolve over time, it will not be very detailed yet (it just needs to be good enough for now), and very little documentation (if any) needs to be written. The goal is to identify an architectural strategy, not write mounds of documentation. You will work through the design details later during development cycles in model storming sessions and via TDD.
  5. Setting up the environment. You need workstations, development tools, a work area, ... for the team. You don't need access to all of these resources right away, although at the start of the project you will need most of them.
  6. Estimating the project. You'll need to put together an initial estimate for your agile project based on the initial requirements, the initial architecture, and the skills of your team. This estimate will evolve throughout the project.

Figure 6: The Agile Model Driven Development (AMDD) life cycle.

The 2013 Agile Project Initiation Survey found that the average time to initiate an agile project took 4.6 weeks. Figure 7 depicts the range of initiation periods. Differences are the results of the complexity of the domain/problem space, technical complexity of what you're trying to accomplish, availability of stakeholders, ability of stakeholders to come to agreement as to the scope. and ability of the team to form itself and to obtain necessary resources.

Figure 7. How long did it take to initiate an agile project?

4. Construction Iterations

During construction iterations agilists incrementally deliver high-quality working software which meets the changing needs of our stakeholders, as overviewed in Figure 8.

Figure 8. Agile software development process during a construction iteration.

We achieve this by:

  1. Collaborating closely with both our stakeholders and with other developers. We do this to reduce risk through tightening the feedback cycle and by improving communication via closer collaboration.

  2. Implementing functionality in priority order. We allow our stakeholders to change the requirements to meet their exact needs as they see fit. The stakeholders are given complete control over the scope, budget, and schedule – they get what they want and spend as much as they want for as long as they're willing to do so.

  3. Analyzing and designing. We analyze individual requirements by model storming on a just-in-time (JIT) basis for a few minutes before spending several hours or days implementing the requirement. Guided by our architecture models, often hand-sketched diagrams, we take a highly-collaborative, test-driven design (TDD) approach to development (see Figure 9) where we iteratively write a test and then write just enough production code to fulfill that test. Sometimes, particularly for complex requirements or for design issues requiring significant forethought, we will model just a bit ahead to ensure that the developers don't need to wait for information.

  4. Ensuring quality. Disciplined agilists are firm believers in following guidance such as coding conventions and modeling style guidelines. Furthermore, we refactor our application code and/or our database schema as required to ensure that we have the best design possible.

  5. Regularly delivering working solutions. At the end of each development cycle/iteration you should have a partial, working solution to show people. Better yet, you should be able to deploy this solution into a pre-production testing/QA sandbox for system integration testing. The sooner, and more often, you can do such testing the better. See Agile Testing and Quality Strategies: Discipline Over Rhetoric for more thoughts.

  6. Testing, testing, and yes, testing. As you can see in Figure 10 agilists do a significant amount of testing throughout construction. As part of construction we do confirmatory testing, a combination of developer testing at the design level and agile acceptance testing at the requirements level. In many ways confirmatory testing is the agile equivalent of "testing against the specification" because it confirms that the software which we've built to date works according to the intent of our stakeholders as we understand it today. This isn't the complete testing picture: Because we are producing working software on a regular basis, at least at the end of each iteration although ideally more often, we're in a position to deliver that working software to an independent test team for investigative testing. Investigative testing is done by test professionals who are good at finding defects which the developers have missed. These defects might pertain to usability or integration problems, sometimes they pertain to requirements which we missed or simply haven't implemented yet, and sometimes they pertain to things we simply didn't think to test for.

Figure 9. Taking a "test first" approach to construction.

Figure 10. Testing during construction iterations.

I would rather fail three weeks into a six-month project than ten months into a six-month project.

5. Transition: The "End Game"

During Transition, also known as the "end game" or deployment, we release the solution into production. Not that for complex systems the end game may prove to be several iterations, although if you've done system and user testing during construction iterations (as indicated by Figure 7) this likely won't be the case. There are several important aspects to this effort:

  1. Final testing of the system. Final system and acceptance testing should be performed at this point, although as I pointed out earlier the majority of testing should be done during construction iterations (ideally, you just need to rerun your regression test suite to see that it works). You may choose to pilot/beta test your system with a subset of the eventual end users. See the article Agile Testing and Quality Strategies: Discipline Over Rhetoric for more thoughts on testing.

  2. Rework. There is no value testing the system if you don't plan to act on the defects that you find. You may not address all defects, but you should expect to fix some of them.

  3. Finalization of any system and user documentation. Some documentation may have been written during construction iterations, but it typically isn't finalized until the system release itself has been finalized to avoid unnecessary rework Note that documentation is treated like any other requirement: it should be costed, prioritized, and created only if stakeholders are willing to invest in it. Agilists believe that if stakeholders are smart enough to earn the money then they must also be smart enough to spend it appropriately.

  4. Training. We train end users, operations staff, and support staff to work effectively with our system.

  5. Deploy the system. See my article entitled System Deployment Tips and Techniques.

As you can see in Figure 11, on average agile teams take 4.6 weeks to transition their system into production according to the November 2010 Agile State of the Art Survey. As you can see in the figure there is a wide range of time taken. I believe this variance ranges based on the complexity of the solution, the amount of deployment automation (teams that have adopted a continuous deployment strategy automate many of the technical aspects of transition), the comprehensiveness of the agile testing effort during construction, the need for manual efforts such as training and educating end users (or support or operations staff), and the organizational complexity of your environment.

Figure 11. Amount of time experienced agile teams invested in releasing/transitioning their solution into production.

6. Production

The goal of the Production Phase is to keep systems useful and productive after they have been deployed to the user community. This process will differ from organization to organization and perhaps even from system to system, but the fundamental goal remains the same: keep the system running and help users to use it. Shrink-wrapped software, for example, will not require operational support but will typically require a help desk to assist users. Organizations that implement systems for internal use will usually require an operational staff to run and monitor systems.

This phase ends when the release of a system has been slated for retirement or when support for that release has ended. The latter may occur immediately upon the release of a newer version, some time after the release of a newer version, or simply on a date that the business has decided to end support. This phase typically has one iteration because it applies to the operational lifetime of a single release of your software. There may be multiple iterations, however, if you defined multiple levels of support that your software will have over time.

7. Retirement

The goal of the Retirement Phase is the removal of a system release from production, and occasionally even the complete system itself, an activity also known as system decommissioning or system sunsetting. Retirement of systems is a serious issue faced by many organizations today as legacy systems are removed and replaced by new systems. You must strive to complete this effort with minimal impact to business operations. If you have tried this in the past, you know how complex it can be to execute successfully. System releases are removed from production for several reasons, including:

  1. The system is being complete replaced. It is not uncommon to see homegrown systems for human resource functions being replaced by COTS systems such as SAP or Oracle Financials.

  2. The release is no longer to be supported. Sometimes organizations will have several releases in production at the same time, and over time older releases are dropped.

  3. The system no longer needed to support the current business model. A organization may explore a new business area by developing new systems only to discover that it is not cost effective.

  4. The system is redundant. Organizations that grow by mergers and/or acquisitions often end up with redundant systems as they consolidate their operations.

  5. The system has become obsolete.

In most cases, the retirement of older releases is a handled during the deployment of a newer version of the system and is a relatively simple exercise. Typically, the deployment of the new release includes steps to remove the previous release. There are times, however, when you do not retire a release simply because you deploy a newer version. This may happen if you can not require users to migrate to the new release or if you must maintain an older system for backward compatibility.

8. Enterprise IT

I'd like to end with a discussion of the Enterprise IT lifecycle. One way to depict this is shown in Figure 11, the Enterprise Unified Process (EUP) lifecycle. This lifecycle explicitly shows that there is a wide range of activities involved in Enterprise IT that go far beyond solution delivery. This is something the agile community is currently working to address.

Figure 11. The Enterprise Unified Process (EUP) lifecycle.

9. Recommended Reading

This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise describes the Disciplined Agile Delivery (DAD) process decision framework. The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation for scaling agile. This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting. Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process. Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams. Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process.

9. Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.


Leave a Reply

Your email address will not be published. Required fields are marked *