Agile ALM White Paper: Redefining ALM with Five Key Practices

Transcription

2 Introdution The pervasiveness of the Internet, soial media, and smart mobile devies have hanged the pae and global nature of business forever. New opportunities and threats onstantly appear and disappear, with inreasingly shorter frequenies. Customer expetations are higher and untiring they want more value, faster, and more often, and they are not afraid to tell the world about it. Companies are under onstant pressure to quikly adapt and innovate new business models to stay ahead of the ompetition. Their ability to do so is inreasingly tied to their ability to design, deliver, and evolve software. This presents a number of hallenges to the modern IT organization and alls for a new approah to Appliation Lifeyle Management (ALM). Traditionally, ALM has foused almost entirely on defining and enforing proess, and very little on identifying and delivering what ustomers atually need. Although it rightly aimed to improve onsisteny and quality, these often ame at the expense of produtivity and delivery. For at least two deades, traditional ALM has helped to reinfore the negative organizational behaviors and praties that reate roadbloks to prodution deployment: unstable environments, monolithi heavyweight tools, fragile builds, and ineffetive hand-offs between development, testing, deployment, and operations. Still today, it auses ompanies to build suboptimal software and suffer long delays in getting it into the hands of their ustomers. Agile ALM frees ompanies from the heavyweight proesses and tools that stand in the way of reating exiting and useful software. It regularly delivers working software into the hands of real users on a weekly, daily, or even hourly basis. This allows ompanies to quikly gauge ustomer interest, aommodate feedbak, and make ourse orretions to exploit new windows of business opportunity. While traditional ALM applied tools to enfore pre-defined standardized proess, Agile ALM is the appliation of tools to support people and the proesses that best suit the way they atually work when reating great software. This paper outlines the five key organizational praties of Agile ALM: (1) Evolve proess definition; (2) Embrae heterogeneity; (3) Build the right thing; (4) Pratie Continuous Delivery; and (5) Orhestrate, don't manage. It desribes how ompanies that keep these praties in the forefront of all their software delivery ativities will reap the benefits in inreased agility. In addition, it explains why it's important for ompanies to provide the right tools to support these praties, and how the wrong tools an get in the way. Agile ALM is the appliation of tools to support people and the proesses that best suit the way they atually work when reating great software Aurate data, transpareny, visibility Produtivity Quality Alignment with business initiatives People and proesses Evolve proess definition Embrae heterogeneity Build the right thing Pratie Continuous Delivery Orhestrate, don t manage Tools (inluding projet management, proess automation, testing) Tools enable transpareny and more aligned delivery if 5 praties are followed when applying them to SDLC proesses 2011 ThoughtWorks In. All rights reserved

3 #1 Evolve proess definition Agile proesses are generative, not presriptive. Proesses need to evolve as needed, not be presribed up-front. A presriptive approah generates omplex and ompliated proesses whereas a generative approah begins with a set of simple proesses and adds others as they are needed. - Jim Highsmith, author of Agile Projet Management Agile ALM reognizes that the most effetive proess for any software initiative annot be defined up-front; it must be ontinuously disovered, evolved, and refined over time. Suessful teams aept that they annot predit the future and instead set themselves up to adapt to the hanges and onstraints that will undoubtedly ome their way. They start with a vision, some baseline assumptions, and an agreed proess that is as simple as possible. They build into that proess' opportunities to regularly reflet and improve upon it to stop doing things that aren't working, do more of the things that are working, and aommodate new things that may have never ourred to them (or the business) before. Evolving proess definition requires tools that expliitly enable this kind of sophistiated on-the-fly tailoring and ontinuous improvement. Critially, this should not be onfused with, or traded-off for the more basi, up-front ustomization that is provided by traditional ALM tools and many presriptive Agile tools. On the surfae, these tools allow users to define their proess up-front by adding fields into a template, reating workflows, defining reports, et., but one the projet gets underway, they an no longer be further ustomized to aommodate unforeseen and badly needed proess hanges. Before long, the tools start to get in the way slowing things down when unneessary steps an't be eliminated from a workflow, and reating onfusion when new steps an't be added. Agile ALM requires tools to be agile and adapt to the way teams work, while they work. Companies that provide appropriate tooling and organizational level support for evolving proess definition greatly improve their prospets for ahieving business agility. It's a simple hain of ausality: teams that are empowered to ontinuously improve and make themselves more effetive produe better software more quikly. Tools that make them faster and do not obstrut, will get used. As they get used, projet data will be aptured. As projet data is aptured, business and IT stakeholders get real-time visibility into those projets. This real-time visibility then gives stakeholders the onfidene to steer and hange ourse in response to ompetitive pressures and new market opportunities. #2 Embrae heterogeneity If self-adaptivity ours within a projet, it's even more marked aross an organization. A onsequene of self-adaptivity is that you should never expet to find a single orporate methodology. Instead, eah team should not just hoose their own proess, but should also atively tune their proess as they proeed with the projet. While both published proesses and the experiene of other projets an at as an inspiration and a baseline, the developer's professional responsibility is to adapt the proess to the task at hand. - Martin Fowler, o-author of the Manifesto for Agile Software Development Agile ALM embraes the fat that every software projet is different. Just as proesses annot be ompletely defined up-front, they also annot be ompletely standardized aross all teams. For example, a new produt development team may need to work with loosely defined requirements in order to allow enough flexibility to respond to fous-group feedbak. In ontrast, a team adding enhanements to a prodution system in a heavily regulated industry may need to define strit development proedures to ensure ompliane ThoughtWorks In. All rights reserved

4 Embraing heterogeneity requires tools that support the best proess for eah team one that is uniquely tailored to their irumstanes and needs. However, even though every projet is different, managers and stakeholders still need to have a omprehensive and onsolidated view of all projets in their organization. In addition to promoting proess diversity, tools must also support just enough onsisteny aross projets to failitate reporting roll-ups, governane, and other organization-level needs suh as ompliane. Companies that embrae heterogeneity build high-performane delivery teams and atually improve their ability to mitigate risk. Proess standardization often seems like a great way to redue risk and eliminate large failures. But by definition, standardization redues both the low-performing variations, and the high. This makes it harder for teams to exel, and often institutionalizes onsistent mediority, or even worse, onsistent failure. Instead, meeting ompliane and reporting needs with just enough proess onsisteny supported by the right tools, and allowing teams to uniquely tailor their approah provides greater visibility to manage risks as they arise while software is being delivered. #3 Build the right thing The pae of hange is aelerating, and businesses need to move fast to keep up. If you're not onstantly delivering working software, you're not getting feedbak on whether what you're delivering is useful. Overwhelmingly, the hanes are that you won't build the right thing first time. The longer it takes you to get feedbak and pivot, the more time and money you spend on building the wrong thing. - Jez Humble, author of Continuous Delivery Agile ALM embeds ustomers and business people into the day-to-day ativities of software teams. As members of the team, they see the software as it's being reated and provide immediate feedbak to help make regular ourse orretions towards building the right thing. In stark ontrast to this, waterfallbased methodologies ask stakeholders and analysts to define requirements up-front and hand them off to a development team whih then works in isolation to fulfill them. This rarely results in software that meets the business needs beause the defined requirements are easily distorted as the details hange or are misinterpreted during hand-offs from team to team. Traditional ALM tools attempt to address this disonnet by emphasizing the lifeyle of a requirement. They fore teams to heavily doument and move proess artifats through sign-off milestones. This fous on adhering to the defined proess and managing artifats diverts attention away from making sure the requirements are orret. The ommon result is either no software, or software that does not meet the needs of the ustomer or the business. Building the right thing requires tools that failitate dialogue and ollaboration at every point along the software development lifeyle: bringing business and projet teams together when high-level goals are initially defined, and helping them deompose the vision into more detailed requirements and implemented features along the way. Critially, these tools must help business people, analysts, and testers work together to orretly define aeptane riteria, as well as align the business, development, support, and operations teams to make regular deliveries into prodution the best way to ensure the team is building the right thing. Companies that fous on building the right thing over managing the lifeyle of artifats reate software that is more exiting and useful to their end users and ustomers. Through enrihed engagement with their ustomers, they disover new opportunities to reate value and build longer-term mutually benefiial relationships ThoughtWorks In. All rights reserved

5 #4 Pratie Continuous Delivery Keeping your software prodution ready from the beginning of the delivery proess has several benefits. First, it means releasing is a low-risk, push-button proess. That means you an do it more often, whih means you an show it to users to get feedbak more frequently, test it under realisti onditions more frequently, and get the only real measure of produt progress. In short, it means you an deliver higher quality software faster, and redue waste in your delivery proess. - Jez Humble Agile ALM ontinuously delivers a few features every few days or weeks, instead of a bunh of features every few months. Pratiing Continuous Delivery ensures that the path to prodution is lear kinks in the release proess are ironed out early and preditability beomes the norm. In traditional ALM, releasing software is often a stressful and error-prone ativity. Awkward manual hand-offs aross the silos that segregate Development, QA, and Operations via role-speifi tools ause long delays. They also introdue errors that later manifest as prodution instabilities and outages. In ontrast, Agile ALM integrates all these perspetives into the software reation proess from the very beginning and every day thereafter, ensuring that everyone's needs are met and automating as muh manual ativity as possible. Continuous Delivery requires tools that failitate detailed tehnial ollaboration and ontext sharing. The tools should help testers, analysts, business people, operations, and developers test the right things and quikly find and fix the things that are broken. They should redue or even eliminate errors by automating where possible every validation step on the path to prodution, e.g. funtional testing, performane, seurity, and general operational aeptane testing. Companies that pratie Continuous Delivery, and provide the appropriate tools to support it, build preditability and repeatability into their release proess. This rigor affords them the onfidene to release new features whenever they want trying out new ideas quikly and adapting their approah to aommodate ustomer feedbak and exploit new windows of opportunity. And, beause they release early and often, they also ahieve earlier returns on their software investments. #5 Orhestrate, don't manage Governane is about monitoring investment and risk, not heking-off proess steps. In fat, the key to effetive exeutive projet oversight is separating governane from operational proesses, evaluating investment and risk at key projet milestones and generating the data for that evaluation through iterative delivery. - Jim Highsmith Traditional ALM has historially onfused proess ompliane for governane. It introdued and reinfored the notion that the main role of management is to mandate a single set of proesses aross all software teams. To ensure proess adherene, traditional managers typially provided heavyweight tools to enfore the workflow, trak artifats, and report progress. Unfortunately, still today this results in many teams spending the majority of their time managing artifats and working around mismathes among proesses, tools, and reality all at the expense of delivering working software. This is the main ause of the misalignment that is so prevalent between management and projet teams in many ompanies today. Agile ALM instead alls upon ompany leaders and managers to beome orhestrators, making sure the work being done is aligned with business goals, removing obstales, fixing bad projets, understanding 2011 ThoughtWorks In. All rights reserved

6 the portfolio, and helping to spread best-praties aross teams. This means providing leadership and tooling to support the key organizational praties: (1) Evolve proess definition; (2) Embrae heterogeneity; (3) Build the right thing; and (4) Pratie Continuous Delivery; and fousing attention on oordinating teams to make suessful, business-aligned delivery a regular ourrene. Orhestration requires tools that provide radial transpareny and visibility into every orner of the organization. They must make it easy to roll-up and summarize status in real-time, and see dependenies among individual projets and initiatives. They should also make it easy to zoom in and see where the risks and bottleneks are or onversely, where things are going well and should be highlighted and potentially repliated aross other areas of the organization. Companies where leaders orhestrate as opposed to just manage proess ompliane ahieve muh greater alignment between management and software teams. Applying the right set of tools enables real-time visibility aross all areas of business, analysis, testing, development, and operations, making it easier to see wrong-turns and roadbloks and keep software initiatives aligned with business objetives. Conlusion In Traditional ALM, tools often drive proess. In Agile ALM, people drive proess, and tools adapt to support the proess. The right proess annot be defined up-front, nor an it be ompletely standardized aross all teams. The best way to manage risk is radial visibility, not omplete standardization. The best way to deliver software that meets business needs is through onstant ollaboration, not managing artifats. The best way to get software into prodution regularly is to pull the pain of deployment forward and break down operational silos. And, the best and most business-aligned software initiatives have leaders who orhestrate, instead of just manage. The best tools for Agile ALM must support the five key organizational praties. They must: Enable teams to disover and evolve their proess on-the-fly Support the unique needs of every projet, as well as the organizational needs for onsisteny Failitate onstant ollaboration among pratitioners and stakeholders at all levels Automate testing and deployment to enable Continuous Delivery Provide omplete transpareny and visibility for leaders, without reating work for projet teams Companies that embrae the five key organizational praties of Agile ALM and provide appropriate tools to support them - inrease their agility and their ability to ompete. They reate better, more exiting software, and get it into their users' hands faster. Through better software, they disover new ways to engage and reate value for their ustomers. They try out new ideas quikly, and they ontinuously adapt in-line with ustomer feedbak, shifts in the market, and hanges in business strategy ThoughtWorks In. All rights reserved