Traditional software development happens sequentially with clearly defined stages and phases. Sequential development is popular because it is easy to follow from a team member perspective. Team members follow exact steps for every project and quickly learn the process.\n\nThis article is based on the book Becoming Agile by Gregory S. Smith, published by Manning Publications.\n\nIn an Agile process activities are frequently concurrent and often repeated. Team members focus on providing value and using the process and steps that best support the project. Applying Agile processes and techniques is not intuitive for team members with a background in sequential software development.\nTo address this issue I will present the Agile concepts from a sequential phase perspective. If you are familiar with traditional software development you will find the phase descriptions intuitive.\nBefore we continue, let me expand on what I mean by a generic Agile development process. Scrum and Extreme Programming (XP) are popular packaged Agile methods. These packaged methods come with several Agile practices and a suggested process for using them. Our generic life cycle will be different in that it will allow a development team to pick and choose the Agile practices that work best in their environment.\nXP and Scrum are superb Agile packages with strong followings and demonstrated success. Many companies have deployed these packages successfully. An issue with selecting a package, however, is some practices may provide minimal value in your environment or be difficult to implement on day one.\nConsider the XP practice of Test Driven Development (TDD). This is an excellent practice that provides benefits such as minimizing the time needed to trace down bugs and quicker deployment of code. No one can deny the value of these benefits. What can be challenged is the complexity of implementing a TDD process.\nA TDD process requires a disciplined development team and a mindset change. The development team needs to grasp the value of TDD and support it on a daily basis. This is a stretch for a team that is just learning the value of Agile principles. From my perspective you would not want to attempt to use TDD during your initial migration to Agile. TDD could be revisited once the Agile culture has begun to take hold and the team owns the new process. For reasons such as these, you will select the Agile practices that work best in your environment.\nRelated, an important aspect of our process is the menu system. We will outline a core flow that all projects should go through, but the required path will represent the least common denominator. It will be low on formality and best used on projects that need to be completed in a few days. The menu will provide options that the team can select as needed, or as the project requires more structure. To see an example, let\u2019s look at the menu that Acme Media will use in table 1.\nTable 1\nA key to being Agile is using the practices that best support a given project. In this example from Acme Media, the team should perform the tasks first list for every project. The steps in the second list are optional.\n\n\n\n\nRequired of All Projects\n\n\nProject worksheet (charter)\n\n\nOperational worksheet\n\n\nFeature card\/User Story exercise (cards optional)\n\n\n\n\n\n\n\n\nOptional Processes and Documentation\n\n\nElevator Statement\n\n\nDocument answers to Feasibility Discussion Guide questions\n\n\nCost\/benefit analysis\n\n\nFeature card documented.\n\n\nUser scenarios\n\n\nUse cases\n\n\nPrototypes and\/or mockups\n\n\nStand Up Meetings\n\n\nIteration plan\n\n\nMaintenance plan\n\n\nAdditional documentation as required by the team\/project.\n\n\nPair Programming\n\n\nDetailed schedule\n\n\nLaunch Plan\n\n\nInformation Radiator\n\n\nDemonstrations\n\n\nAction items from project retrospective\n\n\n\n\nFigure 1 illustrates the Agile phases and their relationship to each other.\n\nFigure 1 Agile process frequently occurs in parallel, but we will discuss them from a serial perspective to make them easier to learn.\n\nThe Agile phases\nThe 5 phases we will discuss are feasibility, planning, development, adapting, and deployment:\n\n\nThe feasibility phase is used to determine if an idea has enough merit to proceed to planning. An individual or small group will scrutinize the idea for customer value, company value, and risk.\n\n\nIf an idea is viable it will proceed to planning. The project team will be assembled at this time and the team will work together to identify features. Features will be examined for value and risk and eventually estimated so they can be assigned to an iteration plan.\n\n\nDevelopment iterations convert the iteration plan into working code. Features are built, tested, and demonstrated to the customer and stakeholders at the end of each iteration.\n\n\nThe team adapts between development iterations. Customer feedback is used to adjust the plan for the forthcoming iteration. The team also uses this window to evaluate their velocity (pace) and they adjust iteration capacity accordingly.\n\nWhen all iterations are complete the team deploys the working code into a production environment.\n\nNow let\u2019s examine the feasibility phase in detail.\nFeasibility\u2014defining and validating your vision\n\nPHASE OBJECTIVE: Determine if the idea has enough merit to justify going forward with more detailed requirements, planning, funding, and staffing.\n\nWhy am I here? Why are we doing this project? What is the value of this request? The feasibility phase pursues the answer to these questions and also evaluates the risk in pursuing an idea. The question that summarizes it all is, \u201cIs this request or idea viable?\u201d\nLet\u2019s look at figure 2 to get a better understanding.\n\nFigure 2 Many companies initialize a project without truly quantifying the value and goals. The Feasibility phase eliminates this issue by measuring the value before making a major investment in the project. Costs and benefits are compared at the end of the phase and the team makes a go\/no go decision.\n\nThe feasibility phase begins with an idea or request. The idea can come from within the team, a customer, or practically any source. The person who collects or provides the idea bounces it off of a supervisor or a management group that vets ideas. If the idea is given approval for further investigation of feasibility, the idea is assigned to a group or person for further research. It could be given back to the person who presented the idea.\nThe person assigned to the request then makes a decision on whether they can do the research on their own, or if they will need team members for help. To see it in practice, let\u2019s look at an idea within Acme Media.\nWes Hunter, a business analyst, has suggested that Acme start providing news alerts to cell phones. He bounced the idea off of Peggy Romani, the Product Manager for the News website and received a green light to go further on feasibility and research. Wes could see the business value of the feature and explain the value from a perspective of audience share and competitive advantage, but he had no idea how wireless technology worked or the architecture that would be required to support it. Wes requested the assistance of the lead architect, Keith Gastaneau, to help him work through the high level technical implications of pursuing the idea. In this instance the feasibility team will be Wes and Keith.\nOnce the team or person has been identified they continue the feasibility work. This additional work could include:\n\n\nTalking to customers\n\n\nPerforming a cost\/benefit analysis\n\n\nLooking at what competitors are doing in related areas\n\n\nResearching whitepapers on the subject from industry experts\n\n\nCheck compatibility with the current platform\n\n\nResearching technology needs.\n\n\nCreate use cases to better understand the idea\n\n\nUsability testing\n\n\nMockups\/prototypes\n\n\nThe Agile\/Lean concept of just enough applies here. We want just enough information to see if this idea is worth the effort needed to create a plan for it. Once the work is complete it is presented to the Product Manager or approving body for discussion. The feasibility investigator will present high level requirements, a guess at project costs (funds and resources needed), risks identified during the research, a list of benefits, and a ballpark project timeline. The meeting is concluded with a go\/no-go decision.\nThis decision only provides approval to continue the investigation and planning for the idea. It is not an endorsement to take the idea all the way through to delivery. Show stoppers can still be identified during planning and development, so an idea can be cancelled at any time.\nThe last step in the feasibility phase is the assignment of a planning team. If one person has been investigating an idea they will need a team to plan the idea after approval. Resources can be assigned informally or officially by a manager or management group. Team members can come from all areas of the project team, but you need to have representatives who have experience with the product. These team members will help estimate features at the end of the phase.\nThe team also needs the customer or a customer advocate to provide their input during the prioritization that occurs throughout the phase. It is desirable to have the planning team follow the idea all the way through to deployment.\nPlanning\u2014speculating and creating a living plan\n\nPHASE OBJECTIVE: Break the idea down into discrete pieces of functionality called features. Prioritize the features and assign them to iterations.\n\nThe first step in the planning phase is to orient all of the planning team members on the idea.\nFrequently the planning team will conduct an \u201cenvisioning\u201d meeting to help everyone synchronize on the benefits of the idea. The envisioning meeting can be viewed as a marketing meeting. The team pretends they are going to sell the idea to a customer. They identify the top 3 to 5 product highlights they would tell the customer about. In addition they create a summary of key features that will be delivered. The idea is becoming a project during this exercise.\nNote that the planning phase also continues the feasibility work. We gathered enough information to justify planning during feasibility, now we want to refine our financials based on the additional detailed gleaned during planning. See figure 3.\n\nFigure 3 The planning phase brings the project team together to quickly convert the idea into features. The features are prioritized, sequenced, and estimated during the phase. An iteration plan is created to initialize development.\n\nAfter features are identified the team goes through the feature card exercise. In this step the features identified during envisioning are fleshed out just enough to prioritize them and sequence them into the order they would be developed in. The team also uses the prioritization as another feasibility check. If a feature comes out of the feature card exercise as a low priority the customer may choose to remove it from the project.\nThe remaining features are estimated by the team at a high level, identifying the major tasks and resource types needed.\nThe last step of this phase is to assign features to iterations. The iterations are buckets of time that the team develops features in. A good time frame for an iteration is 2 to 3 weeks. The previous estimates are used to determine which features will fit into the available iterations.\nNote that each iteration is structured so that it provides value on its own. This allows deployment even if something prevents all of the iterations from being completed.\nThe main deliverable from this phase is the iteration plan.\nDevelopment\u2014exploring with a schedule\n\nPHASE OBJECTIVE: Create, test, and demonstrate features. Queue iterations for deployment.\n\nThe development phase begins with iteration 0. The iteration is so labeled because no features are delivered during it. This iteration is used to put the necessary foundation pieces, both business and technical, in place to start development. Some typical iteration 0 activities are:\n\n\nFinalizing contracts with vendors\n\n\nInitial architecture design\n\n\nPreparing the environments (OS, DB, Development tools)\n\n\nFunding\n\n\nIf you are building on an existing platform, with dedicated resources, you may not need an iteration 0. You can begin development immediately after planning.\nWhen the first development iteration starts the team will refine the tasks they identified during planning. This is very common because the team only provided enough information to estimate the features during planning. Once a project gets through the planning gateway the team knows it is coming and they will begin doing detailed analysis of the work they need to do.\n\nFigure 4 Development starts by establishing a foundation in iteration 0. Development iterations follow, delivering working code in subsets every 2 to 4 weeks. The working code is surfaced for a demonstration and customer feedback. When all iterations are completed the code is delivered to a production environment.\n\nThe development done during an iteration is not waterfall. The process will be one of collaborative development. The developer will create code to the minimum specification and demonstrate it to the customer. At this time the customer will identify requirements they missed, or issues with their initial requirements. The developer may also identify technical issues. The developer, customer, and team will work through these issues during the iteration, evolving the code until it supports what is needed at the end if the iteration, not necessarily what was requested at the beginning. Figure 4 illustrates the steps in Development.\nBuilding and testing occurs during an iteration. When an iteration is complete there is a review meeting to adapt (see Adapt in the following section).\nIterations are stored in acceptance environments until all iterations are deemed complete. At that time all of the work is deployed into the Production environment.\nAdapting\u2014reacting to new information\n\nPHASE OBJECTIVE: Review the output of an iteration and re-plan based on discoveries (see figure 5).\n\n\u201cAdapting\u201d is one of the special elements of Agile development. We expect change and we embrace it.\n\nFigure 5 The adapt phase surfaces working code for demonstrations and feedback. We use this period of time to validate we are on target with the customer\u2019s needs. We also use this timeframe to evaluate team performance and velocity.\n\nAdapting occurs informally throughout an Agile project, but it happens formally during the development phase. A review is performed at the end of each iteration to:\n\n\nDemonstrate the state of the features assigned to the iteration.\n\n\nGet feedback from the customers and stakeholders.\n\n\nRefine feature definitions based on feedback and better understanding\n\n\nIncorporate new information that has been discovered during the iteration.\n\n\nEvaluate the pace of feature development and adjust the next iteration accordingly.\n\n\nIdentify defects to repair.\n\n\nWhen the review is complete the project manager modifies the iteration plan based on the new information and the team proceeds into the next iteration.\nDeployment\u2014delivery, training, and revisiting and closing the project\n\nPHASE OBJECTIVE: Code delivered to Production environment, with all support needs in place.\n\nThe deployment phase typically begins after the last iteration is complete. We bundle all of the previously completed iterations and move the code to the production environment.\nOne of the advantages of iterative development is you can deploy at the end of each iteration if you so choose. Teams that do this usually have very little overhead in deploying, meaning the process can be done quickly with few resources.\nTypical tasks for the deployment phase are (figure 6):\n\nFigure 6 When all iterations are complete we kick into delivery mode. We train employees, customers, and support networks before putting the code into a production environment.\n\n\n\nTraining support and operations on the forthcoming release\n\n\nTurning on your communication plan to employees and customers\n\n\nFinalize documentation\n\n\nWhen applicable, enabling the marketing plan\n\n\nEnsure all pieces of the maintenance and support plans are in place\n\n\nRelease the code into Production\n\n\nWhere applicable, perform post-release QA in the Production environment\n\n\nPerform a lessons learned session with the team within 2 weeks of the release\n\n\nIn an Agile methodology you have considered deployment needs throughout the previous phases. Optimally the work done during deployment is tweaking and finalizing the training, maintenance, marketing, and communication plans.\nSummary\nAgile software development does not occur sequentially, but viewing it from a sequential perspective makes it easier to grasp the concepts. We will use a case study that follows a sequential process to accelerate your learning of Agile concepts.\nWant to Learn More About Agile?\nHow Agile Development Can Lead to Better Results and Technology-Business Alignment\nThe ABCs of Agile\n10 Questions To See If Your Company's Developers Are Agile\nSign up for our Development and Architecture newsletter\nAdopting an Agile process is a significant effort with a level of risk. To help mitigate this risk we will present an iterative approach that allows your team to add agility over time. You will add more agility to your process as knowledge increases and the organization culture becomes more accepting of Agile techniques.\nAcme Media will bring the 5 Agile phases to life by:\n\n\nUsing feasibility studies to validate the value of an idea.\n\n\nUsing collaborative planning to synchronize the team on project vision and to break the idea down into discrete features.\n\n\nUsing development iterations to refine our understanding of requirements and deliver working code.\n\n\nDemonstrating functioning code to the customer and adapt to their feedback.\n\n\nCompleting the project by deploying our code into the production environment.\n\n\nStopping to review our process and make adjustments to it, based on lessons we learned.\n\n\nBeyond the case study, I believe the template outlined in this article can also be used as a starting point for the Agile migration within your own company.\nAn Agile process is 50% of the work in migrating to Agile. The other 50% is establishing an Agile culture and environment.\nThis article is based on the book Becoming Agile by Gregory S. Smith, published by Manning Publications.