The Eight Stages of an Agile Approach That Works

Transcription

1 The Eight Stages of an Agile Approach That Works An Overview of the OutSystems Approach to Agile Introduction With the experiences gathered through 500+ Agile projects, the OutSystems team has developed and refined a repeatable way to enable the efficient and successful delivery of enterprise-scale Agile projects. In essence, defining an Agile method that works. This approach includes the concepts applied, the tools used and the activities conducted for successfully delivering web business applications. By leveraging the Agile Platform and Agile Network, organizations are able to adopt Agile development methods and scale their Agile projects across their IT organization. At OutSystems, we believe that being Agile requires not only a set of adaptive processes but also tools that make everyone involved with the project, agile. This includes the complete Agile delivery team management, development team members, business users and all key stakeholders. Eight Stages of an OutSystems Agile Project The OutSystems approach to Agile is comprised of the following stages as depicted by the graphic below: 1. Budgeting 2. Project Initiation 3. Iterative Development Sprint Planning, Development & Testing and Product Demo 4. Training 5. Production Launch 6. Tuning 7. Wrap-up 8. Maintenance Let's take a closer look at each of these stages OutSystems All rights reserved Page 1 of 5

2 1. Budgeting The major concepts applied during the budgeting stage are User Stories, Sizing and the Project Timebox. We gather user stories to define the project scope. User Stories are high-level requirements defined in business terms. These descriptions of what the Business Manager wants the application to do are collected in days versus the more traditional requirements gathering processes that can take weeks or even months. Each user story is decomposed into a set of high-level features, which are then sized to determine the effort required to deliver them. The effort or size of each feature is based on its planned pattern of implementation; for example, listing, sorting, searching, editing, etc. Once all features are sized, the project timebox can be defined. The timebox for the project is based on the set of in-scope user stories and the estimated time to complete each feature and the actual project team composition. The project timebox defines the overall budget for the project in terms of resources and number of days to deliver the defined functionality. At OutSystems, we adhere to the timebox principle we hold the budget and the timeline sacred for each project and each sprint that makes up the project. In other words, the budget and timeline are fixed. To be truly Agile in the budgeting stage, we use the Agile Sizings component of the Agile Network. The Agile Sizings component allows us to scope a project based on heuristics accumulated from over 500 highly successful Agile projects. This tool automates the sizing calculations based on patterns, as well as project and application parameters. When the sizing is complete, the Sizing tool provides the initial project plan as defined by the OutSystems approach to Agile. 2. Project Initiation The Project Initiation stage is where we start the actual project. We take the user stories and features then load them into the Agile Projects component of the Agile Network. This is called bootstrapping the project. The user stories and features are now loaded into the project backlog. The project backlog is the list of requirements to be delivered. Once the project is bootstrapped we then conduct a kick-off meeting to bring everyone upto-speed on the project scope, roles, responsibilities, risks, sprint demo session dates, etc. At this point, we can apply scope analysis. Scope analysis involves more detailed requirements analysis including external interface analysis for dependencies. Scope analysis also involves prioritizing the requirements based on the value they provide to the business. We ask questions like: What are the most critical business user profiles? What are the most frequent user stories or use cases that involve those profiles? What are the use cases and user profiles that contribute most to the application s ROI? The result is a project backlog that is a prioritized list of requirements. As part of the project bootstrapping process, the project sprints are identified in the Agile Projects component. A sprint is an iterative cycle of about 2-3 weeks in which a portion of the application is developed. At the end of each sprint, the project team delivers a working, vertically integrated portion of the final application. The length of a sprint is defined in the original plan provided through the Agile Sizings component. Throughout the remainder of the project, the Agile Projects component will be the primary tool used for managing the day-to-day tasks of the project. This component is composed of various tools to facilitate project initiation, planning, execution, controlling, reporting and closure. It includes specific tools for managing Agile projects like backlog management, sprint planning, requirements management, etc. 3. Iterative Development (Sprints) Sprint planning is the first major activity of the iterative development stage. The sprint planning activity involves reviewing the project backlog and collaborating with the business team members to decide which user requirements will be included in the current sprint. This process is called Sprint Backlog Settlement. During this process, feature negotiation and prioritization takes place between the Engagement Manager and the Business Manager to establish priorities for the sprint and balance the overall project time box. The goal of Sprint Backlog Settlement is to identify the high-value requirements to be included in the sprint s backlog without exceeding the sprint s timebox. Once the sprint backlog is defined, a detailed analysis of the OutSystems All rights reserved Page 2 of 5

3 requirements is conducted. By further detailing the requirements to define their design and implementation approach, it will become evident that some may be impossible to implement or alternative implementations may need to be identified. The impact of these changes need to be assessed to determine if these requirements need to be shifted to the next sprint or lesser value requirements be removed from the sprint backlog. Remember, we hold the timebox sacred for each sprint and the overall project. All through the sprint planning activity, the Agile Projects component is used to record the sprint backlog, change requests, issues and risks that arise because of the continuous planning process. The Development and Testing activity begins in each sprint once the sprint backlog is settled. At the start of this activity, the Delivery Manager and each member of the delivery team works together to detail the design, identify the tasks, make delivery commitments and finalize the expected effort for each of the assigned work items. As the team progresses in developing and testing the features, they do so using the visual design and development approach provided by the OutSystems Agile Platform core components Integration Studio, Service Studio and Service Center. On a daily basis, the Delivery Manager conducts a 15- minute standing-only Scrum meeting to synchronize the team s direction. At least once a day or more frequently, all team members upload their work to the Agile Platform and integrate with the other team member s work, ensuring that all work completed is made available to the rest of the team. The project s Delivery Manager uses the Agile Projects component to manage the team s workload. Similarly, each team member uses the Agile Projects component to record completed effort against each work item on his or her task list. At the end of each Sprint, the delivery team provides a demonstration of the working application to the business team members. At this time, a vertically integrated version of the application is presented to the Business Manager and key business users. During each demo session, the end users and QA team members will provide feedback using the Agile Platform s Embedded Change Technology (ECT) so that all input goes directly to the Agile Projects component for immediate assessment and possible addition to the project s backlog. Beginning with the initial sprint, the formal demo signals the start of what we call the Continuous User Acceptance process. Because sprints are short and frequent, the users and Quality Assurance engineers will be continuously testing the delivered application functionality and identifying issues, enhancements and functional errors. This shift in testing greatly enhances application quality and user adoption. Once the demo is completed, the set of features accepted by the Business Manager are signed off and closed. Any changes or new requirements are logged into the project backlog and discussed during the next sprint planning session. Whether or not these are incorporated into the next sprint backlog is discussed during feature negotiations. It should be noted that new requirements or changes of higher priority will inevitably displace lower priority items that are in-scope. This is to be expected. This is one of the benefits of the OutSystems approach to Agile. By constantly aligning with the business, we can be assured that the application delivered meets the needs of the business. A note about teams, roles, and responsibilities: The OutSystems Agile approach looks at the project team as composed of two teams the Engagement Team and the Delivery Team. The Engagement Team is composed of the Business Manager, Users, and the Engagement Manager while the Delivery Team is composed of the Delivery Manager and the Developers. Developers include all the technical roles required for the project. The responsibilities of a Project Manager or a Scrum Master are divided between the Engagement Manager and Delivery Manager. In keeping with the need for greater and constant business involvement while at the same time setting and managing expectations, the Engagement Manager becomes the conduit for the business. The Engagement Manager will need to fully understand the end-to-end process as well as the business vision. The Engagement Manager represents the business to the Delivery Manager who aligns the developers with the business need. The Delivery Team, which is headed by the Delivery Manager, is responsible for delivering the features agreed upon while keeping true to the timebox OutSystems All rights reserved Page 3 of 5

4 It is therefore imperative that the Engagement Manager and Delivery Manager work in concert to ensure that the solution delivered meets the needs of the business. One of the checks and balances that this model affords is that the Engagement Manager can ensure that the Delivery Manager delivers as expected while the Delivery Manager can ensure the Engagement Manager does not over commit. 4. Training The training stage is where we pass ownership of the application to the business. In a typical training session, students are taught how to use the application. The focus is on making sure students learn. The OutSystems approach to Agile takes a different slant on training. The focus is on getting extended feedback about the application. Thus, training is a two step process. First we train key business users and front-line individuals that will carry on the work to assist all other users in learning to use the application. In a well designed and intuitive application, users learn the application with minimal to no formal training. Second, which is the main focus of training, is to enable and empower these key individuals to receive and provide feedback so that the application can continue to evolve as the business evolves. As the number of users grow, there will be more feedback to evolve and improve the application keeping the application in pace with business and process changes. Feedback is encouraged through the Embedded Change Technology (ECT) mechanism which is built into every application. Using ECT all user feedback will automatically be logged to minimize disruption in the rollout process and subsequently during everyday use. in preparation for full application rollout and end-user adoption. 6. Tuning The tuning stage is a key part of the OutSystems Agile approach. It is based on our accumulated experience across 500+ successful projects. During this special sprint, two key activities are conducted application performance and functional tuning. During functional tuning, outstanding issues are resolved and any remaining low-priority project backlog items are assessed for delivery. These items are assessed to determine if they can be considered as adoption boosting functionality. Adoption boosting features increases the probability of the users liking and immediately using the new application. From the delivery team s perspective, this stage is very intense. There will typically be multiple production deployments each day using the 1-click-publish feature of the Agile Platform as the team conducts functional tuning. The intent of multiple deployments is to resolve any outstanding issues and to implement as many "adoption boosting" features as possible, while continuously collecting feedback from the users through the Embedded Change Technology. While the developers are busy pushing new versions to production, the application, system and network administrators are conducting performance tuning to ensure that the application and the environment meet or exceed service levels. In performing the tuning tasks, the delivery team continuously uses the OutSystems Agile Platform components Integration Studio, Service Studio and Service Center as appropriate. At OutSystems, we believe that the success of a project equates to being On-Time, On-Budget and have 100% User Adoption. 5. Production Launch During production launch, the application is published to production using the Agile Platform s 1-click publishing technology. Depending on the nature of the application, the production launch might be targeted to a limited set of users and be running in parallel with any replacement systems. As soon as the application is in production, the delivery team begins tuning the application. This stage is a mandatory part of our Agile approach and is critical 7. Wrap-Up The wrap-up stage officially closes the project. During wrap-up the tuned application is fully signed-off in production. Using the Agile Projects component, all remaining project backlog items are discussed and either archived, prepared for the next release of the application or identified as items to be applied during the maintenance stage OutSystems All rights reserved Page 4 of 5

5 8. Maintenance The objective of the maintenance stage is to ensure that the application continuously supports the business through evolutionary maintenance. This means that as the business changes, so should the application. Therefore, this stage consists of a series of 1 to 2 week sprints depending on the changes or new features identified in an ongoing basis. These sprints continue to follow all the primary activities in a regular sprint and leverage all the necessary tools required to keep the delivery team Agile. At OutSystems, we believe that the promise of Agile cannot be fully realized without enabling technology that shortens delivery cycles, increases software development agility, project predictability, responsiveness to business change and overall development team productivity. At OutSystems, it is all about Agility! More information If you would like to have more information about OutSystems and its products please contact our regional offices: OutSystems US 2603 Camino Ramon, Suite 200 San Ramon, California USA Tel: Fax: info@outsystems.com OutSystems Benelux Planetenbaan AK Maarssen - The Netherlands Tel: +31(0) Fax: +31(0) info.nl@outsystems.com OutSystems Portugal Rua Central Park 6, 2A Linda-a-Velha - Portugal Tel: Fax: info.pt@outsystems.com To get hands-on with our Agile Platform try our free trial: OutSystems All rights reserved Page 5 of 5