Creating Agility at Different Speeds

Transcription

1 Creating Agility at Different Speeds Wolfgang Platz, Founder and CPO 2016 Tricentis All rights reserved.

2 The Plateau of Agile Development 2

3 Anyone with an ear to the software development world knows that Agile Development and DevOps are the hottest buzzwords out there - the phenomenon du jour. It s no wonder either. As the customer-centric era of digital disruption spans on, enterprises are forced to innovate at ever increasing speeds. Agility and continuous testing are a must for survival. The chart below depicts the rate of Agile adoption within a seven year period. In 2006 Agile methodology began to pick up speed, reaching a peak in From there however, the use of Agile methodologies has not shown further increase. Why has Agile development plateaued? 100% 90% Others 80% 70% Waterfall 60% 50% 40% 30% Agile 20% 10% 0% Scrum Agile (Not Scrum) Waterfall Cowboy Coding Others 3

4 To answer that question we need to look at the two systems at play within 99% of enterprises: the System of Engagement and the System of Record. Let s break it down to the basics to make sure we are all on the same page. What is a system of engagement? A company s systems of engagement are their applications for consumer interaction and customer-facing innovation. They are the public user interfaces like mobile apps, webpages for online transactions, etc. On the other hand you have the systems of record. Systems of record are the backend applications that form the heart of the company. They are the large, stable applications that are critical to keeping the day to day processes of a business running - everything from accounting and payment processing to customer databases.

5 Most large enterprises are made up of a combination of both systems 80/20 with the budget typically being split along the 80/20 fault-line (80% systems of record and 20% systems of engagement). The systems of engagement get a lot of attention, but percentage-wise it is not the dominant share of an enterprise s IT budget - the real money goes to the systems of record. If an enterprise is like a house, the systems of record are the foundation, the plumbing, and the electricity: the essentials of the house. These things require maintenance, but if the house is well built, it will only require a big renovation every 8 to 10 years. Keeping with the metaphor, the systems of engagement are new additions made to the house - i.e.: building an extra room or adding a new level. These additions make the house more comfortable and fun to live in. They can also be completed as quickly or slowly as the homeowner wants. 5

6 Approaches to Agile Development 6

7 It is an accepted fact that the systems of engagement and systems of record run on different timelines, and so need to be treated differently. Systems of engagement are innovative by nature, which demands speed. Naturally, they are developed with Agile methodology. Systems of record however, don t require nearly the same speed. What then, becomes the best method for development? Gartner uses a Bi-modal IT approach to this conundrum. They theorize that you can choose either the Agile or Traditional (Waterfall) mode, then decide which to apply for each system there is no in between. + Mode 2 Systems of Innovation - Change Mode 1 Agile Systems of Differentiation Governance - traditional Systems of Record + Gartner s Bi-modal IT Approach

8 Forrester, however, approaches the issue a bit differently. In their estimation, development is not a matter of mode, it is a matter of speed to be specific, the speed of deployment. How often do you deploy? Daily? Weekly? Quarterly? Depending on which system you are working in, the speed of deployment will and should change. + Weeks, Days, Minutes, Seconds Systems of Engagement - Change Months, Weeks, Days Governance - Months, Weeks Systems of Record + Forrester s Speed of Deployment Approach

9 Taking Forrester s approach, is Agile Development suitable for developing both types of systems? Yes. In fact, I think the core virtues of Agile development make sense for all systems. What you need to make it work is the ability to apply agility at different speeds. 9

10 Upstream and Downstream Development 10

11 Epic/User Story The Upstream and Downstream of Agile Development Upstream Code/Config Downstream 5 Core essentials 3 Core essentials Short iterations Daily meetings (stand-ups) Product owner Early and frequent feedback Burn-down/burn-up - transparency Continuous Integration (CI) Continuous Testing (CT) Continuous Delivery (CD) The upstream process is the creation process. It brings you from user story to code or configuration. The downstream process is when that code is pulled together into a usable, testable, deliverable product. The hitch that can trip up this beautiful Agile process is called Cadence Mismatch. A cadence mismatch occurs when the upstream and downstream are flowing at two different speeds, creating a bottleneck in the DevOps cycle. If, for example, the upstream (creation) process is moving faster than the testing in downstream, the resulting backup will block products from being completed and delivered to market. Delivery 11

12 This is where Continuous Testing comes in. Continuous testing is the key to avoiding a cadence mismatch. It is the essential arm that bridges Dev and Ops and keeps the upstream and downstream processes of agile development in sync. Dev Ops

13 There are times however, when intentionally creating a cadence mismatch can work to your advantage: such as when applying Agile development methodology to systems of record. To do this you need to set up a staging area to decouple delivery from deployment: Epics/ User stories Code/ Config Staging area Production Release planning Upstream Downstream Deployment Start Sprint End Release Start Fully tested release candidates hit the staging area GoLive 13

14 Through creating this intentional cadence mismatch in delivery and deployment, you can still assure the agility of short development cycles (sprints) for your systems of record. The key is that you could deploy if you wanted but you don t have to. Why? The core systems of record don t need to be updated every day. Deploying once a month or quarter is still perfectly acceptable for a system of record. Using this process however, you maintain the flexibility to deploy or not deploy as you see fit. The adjusted DevOps cycle for systems of record So while the DevOps cycle for systems of engagement is the infinite cycle as seen above, the adjusted DevOps cycle for systems of record would look like this:

15 Conclusion 15

16 Agile development methods are just as suited to systems of record as they are to systems of engagement, the two primary systems that comprise an enterprises house. While these two systems do require deployment at different speeds, agility can likewise be performed at different speeds through the introduction of an intentional cadence mismatch. A cadence mismatch in the up and downstream process of Agile development is a problem - it creates a bottleneck in the DevOps cycle, which can only be resolved through continuous testing. Introducing an intentional cadence mismatch between delivery and deployment, however, matches Agile development to the pace required by the systems of record you do not have to deploy every day, but you can if you want to. What does all of this do to the plateau in the adoption of Agile development? I don t believe that the plateau will last much longer. Creating an intentional cadence mismatch enables Agility at different speeds, meaning that before we know it, Agile development will be accepted as a one-size-fits-all methodology for all of your systems. Note: The ideas in this article were influenced by the work of Diego La Guidice, Forrester. Further Reading: +) Bimodal IT: How to Be Digitally Agile Without Making a Mess; Mary Mesaglio & Simon Mingay; Gartner; ) The 2015 State Of Agile Development: Learn From Agile Expert Firms, Forrester, Diego Lo Guidice, August ) How the Future of Test Automation Affects You; Wolfgang Platz; Tricentis,

17 Stay in touch Impressum Locations Contact 17