Creating Agility at
Different Speeds
Wolfgang Platz, Founder and CPO
© 2016 Tricentis All rights reserved.
The Plateau of Agile Development
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 2009. From there however, the use of Agile methodologies has not shown further increase.
Why has
Agile development plateaued?
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 2006 2009 2012 2015
Scrum Agile (Not Scrum) Waterfall Cowboy Coding Others*
Agile
Waterfall
Others
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.
To answer that question we need to look at
the two systems at play within 99% of
enterprises: the
System of Engagement
and
5
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.
80/20
…with the budget typically being split along the
80/20 fault-line (80% systems of record and
20% systems of engagement).
Most large enterprises are
made up of a combination of
Approaches to Agile Development
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.
Systems
of
Innovation
Systems
of
Differentiation
Systems
of
Record
Ch
ang
e
Go
ve
rnan
ce
+
-+
Mode 1
traditional
Mode 2
Agile
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.
Ch
ang
e
+
-Weeks
,Days
,Minutes,
Seconds
Systems
of
Engagement
Systems
of
Record
Go
ve
rnan
ce
-+
Months,
Weeks
,Days
Months,
Weeks
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.
Upstream and Downstream
Development
11
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.
Upst
re
am
Epic/User Story
Code/Config
Do
wn
st
re
am
Delivery
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)
Core
essentials
Core
essentials
5
3
The Upstream and
Downstream of
Agile Development
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.
13
Release
planning
Release Start
Staging
area
Fully tested release
candidates hit the
staging area
Production
Deployment
GoLive
Upstream
Downstream
Code/
Config
Epics/
User stories
Start
Sprint
End
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:
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.
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:
The adjusted DevOps cycle for
systems of record
Conclusion
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; 2014 +) The 2015 State Of Agile Development: Learn From Agile Expert Firms, Forrester, Diego Lo Guidice, August 2015 +) How the Future of Test Automation Affects You; Wolfgang Platz; Tricentis, 2015
17 www.Tricentis.com Impressum Locations Contact
