1 / 27

Tales of Agile Adoption From the Trenches

Learn about the challenges and successes of Agile adoption in organizations and how it can drive faster delivery of high-quality applications.

echarlie
Download Presentation

Tales of Agile Adoption From the Trenches

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Webinar No “Easy Button” Tales Of Agile Adoption From The Trenches Kurt Bittner, PrincipalAnalyst August 13, 2014. Call in at 12:55 p.m. Eastern time @ksbittner

  2. What is driving Agile adoption?THE NEED FOR FASTER DELIVERY OF HIGH-QUALITY APPLICATIONS

  3. Your only security is in being the disruptor. Disruption demands delivering fast and frequently, with high quality. 2009 USAA Bank introduces mobile check deposit. Competitors view it as a novelty. 2011 One in four consumers want mobile check deposit. One in two mobile banking users want mobile check deposit. 2012 Sixty-five percent of consumers at least somewhat likely to switch banks to get mobile check deposit. Today Mobile check deposit is “table stakes”; those banks that don’t have it have lost customers. Mobile banking is causing shifts in bank investments away from traditional branches, and has changed the way banks interact with customers. Disruption is everywhere

  4. Demand for mobile and cloud applications are behind the trend • Increased customer expectations • Mobile, cloud becoming the dominant means of customer interaction • Customers expect the same capabilities across all channels • Delivering exceptional experiences means integrating all channels Source: February 12, 2014, “Navigate The Modern Application Delivery Landscape” Forrester report

  5. Organizations are struggling to keep up “How often does your development team release mobile apps?” Base: 172 professional software developers and 87 IT developers building mobile applications; Source: Forrester’s Forrsights Developer Survey, Q1 2013

  6. Shorter time-to-feedback = faster time-to-value Feedback drives improved customer experience and business results The faster the feedback, the less waste. The less waste, the lower the cost. Faster feedback means better results to customers, faster. Happier customers = more customers, increased revenue. Increased revenue and lower cost = better business results. Source: November 18, 2013, “Measuring Mobile Apps” Forrester report

  7. Agile adoption at a large multinational organization CASE STUDY Why it worked Leveraged the passion of people who want to improve — bottom-up. Recognized and rewarded results. Willingness to break with old ways, and remove people who could not or would not change. Understood impediments and worked to remove them. Supported behavior change with automation: build, test (API), static analysis. What they did Common understanding of Agile principles (training) Teams self-selected to change the way they work. Fifteen pilots selected with high probability of success Marketed new approach to business to get buy-in. If no buy-in, pilot was not selected. Started with behavioral change; no additional tools. Working in new way showed dramatic result without capital investment. Supported with critical infrastructure — environments, automation, build and test. Scaled up and out, team by team. Broke down “fiefdoms” through transition to servant-leader model.

  8. Agile adoptionWHAT WORKS AND WHAT DOESN’T Anti-patterns Start with a top-down mandate to change, based on what an exec has heard at a conference Send everyone to training Set milestones for Agile adoption based on number of people/teams working Agile Don’t change the governance model; measures projects against schedule milestones Don’t require the business to change Don’t require Ops to change Punish mistakes; “hold people accountable” Successful change is bottom-up, with support from leadership to clear obstacles and change culture Patterns Start with a developer who sees a better way to work, convince peers to try a new approach Engage with a supportive business that wants to work in a new way Team shows improved results, gets attention of leadership. Leadership supports change, clears obstacles, invests in change; “servant leader” culture Measure teams on cycle time, business contribution; celebrates results Learn from mistakes Change proceeds team by team, with “opt-in”

  9. Typical Agile adoption challenges Developers QA Engaging continuously Increased testing frequency Moving to API testing and “continuous testing”, away from manual UI testing Architecture More frequent engagement with Agile teams Architecture through refactoring Architectural testing versus manual inspection • Working in small batches • Delivering frequently • Engaging with the business • Taking on business analysis and testing responsibilities • Unit testing for everything Business Management Operations • Continuous involvement • Working in small batches • Applications are the business versus support the business • Moving from committing by planning to committing by executing • Progress = tested, demonstrated functionality • Provisioning dev and test environments on demand • Infrastructure as code — configurations under version control • Automated deployments between environments

  10. Big batches of work don’t work for application deliveryWHY WOULD THEY WORK FOR AGILE TRANSFORMATION? Benefits of “small batch” change Quick results with small investment “Opt-in” change lets people choose when and how to change. Low complexity as long as dependencies are minimized Scale up when ready Not everyone needs to change, at least at first. Lead by example Risks of “big batch” change A lot of energy, time, and money are invested before any result is achieved. Forced change meets resistance. Coordination complexity Progress stops when external energy is no longer being supplied. Inevitable disappointment when progress is less than expected “Blame the approach,” or even “Blame the person who got us into this”

  11. The role of managementLEADERSHIP MATTERS Anti-patterns The executive cheerleader — encouraging but not involved in the game Measuring utilization to determine effectiveness Promoting a culture of individual accomplishment and “accountability”; promoting “heroes” Rewarding predictability, and punishing mistakes Encouraging an “us-them” culture “The customer is always right.” Successful change is bottom-up, with support from leadership to clear obstacles and change culture Patterns Clearing obstacles, including people who get in the way Measuring cycle time, customer satisfaction and throughput to determine effectiveness Promoting a culture of shared accomplishment across business, application development, QA and Ops Encouraging innovation and experimentation, and tolerating mistakes so long as learning results Dissolving the walls between roles and functional areas “The customer doesn’t always know what they want, but they know what they don’t want when they see it.”

  12. The “waterfall approach” IS THERE A PLACE FOR IT? The short answer is “no”, but it may be the best they can do.

  13. “Build it, test it, and fix the things that go wrong. Repeat the process until the desired reliability is achieved. It’s a feedback process and there is no other way.” David Packard Co-founder of HP

  14. A typical “hybrid Agile” approach Req’ts and user stories UI design and wireframes Beta test Release 1-2 week cycles Pros Cons • Incremental change, incremental results • Postpones addressing the real challenges • Business engagement • DevOps and delivery Minimizes change Minimal business change No ops change Some benefits in build-test cycles

  15. Leading organizations use a different approach • Rapid feedback loops drive innovative solutions • Customers are part of the feedback loop • “Small batches” = less disruption, lower risk • Faster to market with smaller feature sets • Silos dissolve; extended product teams are cross-functional • Handoffs are eliminated; “one team” product development • Less planning, more doing • “Commit by delivering,” not by planning • The ability to pivot is a strategic advantage • Product composition • Market strategy • Organizational structure and processes Source: July 22, 2013, “Continuous Delivery Is Reshaping The Future Of ALM” Forrester report

  16. Optimizing the value delivery stream • Delays are often due to resource over-utilization; fix these first. • Reducing task time is secondary, once wait time is eliminated. Source: February 12, 2014, “Application Delivery In The Modern Age” Forrester report

  17. Agile: a small-batch WIP management approach Sprints provide a convenient way to manage small batches of work. Demonstrations provide feedback that reshapes the backlog and reduces waste. In the absence of an Agile approach, “maintenance” releases are often inherently small-batch.

  18. Configuration information (settings, users, permissions, accounts, installed software, properties, . . .) saved in SCM tool Scripts necessary to build new environments from configurations saved in SCM tool Environments automatically created, configured and populated with test data using automation Infrastructure-as-code in practice Configuration info SCM repository Deployment automation Configured environment Test data Configuration info Test data Test data management Service virtualization

  19. The continuous delivery cycle Small batches of work Integrated development environments (IDEs), editors/compilers/debuggers, application design tools, content management systems, packaged application customization tools, code review and collaboration tools and sourced components and services Release management, release automation, and change control software What remains after testing has been automated is largely exploratory, and usability testing performed manually. With high levels of automation, this testing requires less coverage and focuses on spot-checking specific capabilities. Source code control systems and related asset management tools. Can involve code analysis and unit testing as part of a precommit process. Environment management Continuous integration tools Automated API-based testing frameworks, static code analysis tools, typically called from CI tools Automated API-based testing frameworks, typically called from CI tools Automated API-based testing frameworks, static code analysis tools, typically called from CI tools Release management and release automation software Representative tools and technologies Source: February 12, 2014, “Navigate The Modern Application Delivery Landscape” Forrester report

  20. API testing in action UI — presentation layer Test harnesses API layer Resource layer (including other applications)

  21. Loose coupling enables independent change Each layer and service can change independently from all the others Services are versioned to allow interfaces to evolve Resources can be replaced without affecting applications Risk is reduced by isolating and eliminating dependencies The unit of release becomes an API change, not an application Applications and services can choose when they “upgrade” to a new interface UI layer API layer Resource layer (including other applications)

  22. Maximize utilization ➔ maximize throughput Maximizing throughput minimizes wait time Work moves through the delivery pipeline faster. Even though people are less busy, more useful work gets done because there is less scrap. Organizational silos tend to emphasize utilization over throughput; focus everyone on the same measure. Maximizing utilization maximizes WIP and waste With everyone as busy as possible, most work is partially completed most of the time. Waiting for someone else? Start something new. Unfortunately there is someone downstream of you, too. When things change, a lot of that partially completed work gets scrapped. The more delays and handoffs, the more documents and ceremony, creating more delay.

  23. Typical benefits realized • Infrastructure as art ➔ infrastructure as code • Reduction in production incidents due to environment configuration errors • Elimination of “it works fine in my environment” excuses • Reduction in mean-time-to-repair (MTTR) by eliminating wait time for environment provisioning • Big batches ➔ small batches Maximize utilization➔ maximize throughput • Decreased scrap and rework due to reduced WIP • Faster cycle time and reduced MTTR • Faster time-to-feedback, resulting in better solutions • Manual builds ➔continuous integration Manual testing ➔ automated API-driven testing • Reduced labor cost • Improved consistency • Faster cycle time • Improved quality • Reduced governance and compliance costs • Improved effectiveness of governance • Integrated architectures ➔ loosely coupled services • Faster cycle time and reduced MTTR • Lower total cost of ownership through reduced maintenance costs and obsolescence avoidance

  24. Typical performance measures • Cycle time • The time it takes to go from idea to business value realization • Mean-time-to-repair (MTTR) • The average time to takes to fix a defect or resolve an incident in production • Revenue per (application delivery) employee • A measure of the economic productivity of the application delivery organization • Technical debt • A measure of the amount of corrective work that has been postponed • Lower technical debt means less risk and higher reliability • Revenue acceleration or lost revenue avoidance • The value of being able to realize a revenue stream earlier, typically expressed as NPV • The value of correcting an error before it causes revenue to be lost • Customer satisfaction scores, net recommender scores, app ratings • Measures of the happiness and loyalty of customers • Innovation rate • The percentage of the application development spending focused on new capabilities versus maintaining existing capabilities

  25. What can you do to deliver faster? STRATEGIES FOR SUCCESS Release decision 1. Create a delivery pipeline. 3. Automate the delivery pipeline. 8. Use faster delivery to drive business strategy and execution. 2. Break down big efforts into small batches of work. 7. Eliminate “release drama.” UAT/ exploratory testing Idea proposed Develop, commit and build Understand needs and invent solutions Customer value Functional testing Deploy solution Load, performance, security, . . . testing 5. Adopt loosely coupled architectures. 4. Use continuous testing. 6. Treat infrastructure as code. Source: April 15, 2014, “The Eight Tenets Of Faster Application Delivery” Forrester report

  26. Kurt Bittner kbittner@forrester.com @ksbittner

  27. Forrester’s Forum For Application Development & Delivery ProfessionalsBUILD SOFTWARE THAT POWERS YOUR BUSINESSOctober 16-17, 2014 · SwissÔtelChicago· Chicago, IL http://forr.com/add14 Use Promo Code “ADD14WEB”to save $100! Register before September 13 to save an additional $200. In the age of the customer, winning requires innovation in customer management. And what is the key to innovation? Software. This Forum is not just for those selecting the technology. If you are touched by software, then this is the Forum for you. Join us to learn how to: Design processes and architectures that deliver customer engagement and drive competitive advantage.  Turn big data and analytics into business strategies.   Design and deliver world-class digital and mobile solutions.

More Related