Being Agile without Continuous Anything - does that make sense?

Being Agile without Continuous Anything -does that make sense?

Provocative ideas and small steps for YOUR next improvement

Presentation for ScrumTisch Aachen2016-09-05Rev. A1

Markus [email protected]

Markus Jansen Being Agile without Continuous Anything? 2 / 17

Overview

● Personal Background

● Continuous Anything – Myths

● Continuous Anything – Facts

● Continuous Delivery and DevOps – Why

● The Continuous Delivery Maturity Model

● Next Steps to address YOUR War Stories

● References

● Conclusion

● Discussion


Personal Background

● Education and Characteristics– Electrical Engineer (Computer Engineering)

– SW Configuration Manager, Build Specialist, Software Architect

– Predilection for robust systems with minimal maintenance

– Interest in [build] automation, complex tasks, user interfaces, ...

● Timeline– 1977 First own HW

– 1983 Z80 HW and Assembler, CP/M BIOS, Pascal

– 1987 C/C++ integrator/teacher, Unix admin

– 1994 Designing build and release systems … still on that track


Continuous Anything – Myths

● General myths– “We never have emergency corrections”

– “Our customers are happy enough with our release cycle”

– “Yet another way to reuse electrons for heating”

– “We do not need multiple releases a day”

● Implementation myths [also known as roads to failure]– “We just need a 'DevOps team' to 'implement' DevOps”

– “Continuous Delivery should be driven by Release Staff”

● Remember that bad news spread better than good ones.


Continuous Anything – Facts (1)

● Continous Anything / DevOps Term Split-up:– Continuous Integration

● Be able to frequently integrate development code towards the mainline

– Continuous Delivery● Always be able to deliver a product

– Continuous Release● Always be able to use your product portfolio's steering wheel (that is,

control deployment and its target groups)

– Continuous Deployment● Always be able to deploy to production (or a similar envrionment)

● This split-up is not optimal for the purpose of this presentation.



● The “be able to” clauses in the area definitions above are an essential key to embrace Continuous Anything ideas:– You do not have to integrate / build / test / release / deploy

your products as often as possible, but you are able to do it without extra hassle both in regular and extraordinary (emergency) release situtations.

– Understood this way, Continuous Anything can help Agile development to live its virtues in a more hassle-free way.

– There might be still some areas where Continuous Anything ideas appear as not applicable, but chances are high that this “comfort” situation will fade away soon due to the general industry speedup.



● Continuous Anything is not a “to be or not to be” digital switch, it is more like implementing maturity in some areas.

● It can be compared to CMM, although less formalized.

● Keep in mind that there is no golden bullet, and everything can be implemented in a wrong way.– Example: Establishing a continuous build with radiators on

the wrong (main) branch will confront developers with too many red (failed) builds, and very likely put them either in “always jump to fix fast” or “complete ignorance” mode (the latter after a while).

● Note: For the remainder of this presentation, we will choose Continous Delivery as the generic term.


● Some war stories / situations:– Not everything is automated. While software build, test, and release work

in an automated way, the release documentation and the overall handling still happen manually. => As a consequence, a five minute software emergency correction is not officially delivered due to resource constraints, and deployment may happen as a per-site hack, or not at all.

– Larger parts of a software product get re-written. Unfortunately, the demo package is not part of the overall test chain.=> The “forgotten” demo is written last minute. UX is hopefully good.

– The production environment and/or user data largely differ(s) from the development and test ones.=> Room for big surprises, and banana software reputation.

● All of the war stories above result from technical debts of agile teams.

Continuous Delivery and DevOps – Why


Continuous Delivery Maturity Model (1)

● The Continuous Delivery (CoDe) Maturity Model has been developed by Praqma A/S in 2013.

● At present, their Web shows the second release (2015), this time implemented as code: Non-static, will change over time, sources are usually kept in GitHub.

● The Continous Delivery domain is split into the following areas:– Build

– Test

– Version Control

– DevOps

– Architecture & Design

– Organization & Culture



● For each area, a maturity level can be specified:– Novice

– Beginner

– Intermediate

– Advanced

– Expert



Source: http://code-maturity.praqma.com/, part 1 of 2, snapshot from 2016-09-01, Copyright (c) 2013-2016 Praqma A/S

http://code-maturity.praqma.com/



Source: http://code-maturity.praqma.com/, part 2 of 2, snapshot from 2016-09-01, Copyright (c) 2013-2016 Praqma A/S

http://code-maturity.praqma.com/



● Some words about Praqma– Praqma is a consultancy company originating from Denmark,

with offices also in Sweden and Norway.

– In addition to helping customers to improve in Continuous Delivery and DevOps, they run conferences, are attached to various universities, and invest in fostering a CoDe culture.

– I had the pleasure to work together with some of their incredibly knowledgeable staff during my 22+ years at Ericsson.

● Praqma uses their CoDe Maturity Model for discussions with clients, colleagues, user groups, and other audiences.

● Maybe the model or some of their resources can help you to find next steps towards Continuous Delivery maturity.


Next Steps to address YOUR War Stories

● Feel free to have a look at the Continuous Delivery Maturity Model on the Web– Everything is clickable, with good explanations.

– It helps answering questions like “Where do we start?”, “What to do next?” and “What’s the benefit of this particular step?”

● Remember your last or actual war stories– Do you recognize low hanging fruits (possible next steps)?

– Remember the “Organization & Culture” area – removing technical debts does not come for free.


References

● Jez Humble's Continuous Delivery web site: https://continuousdelivery.com/

● Praqma, The Continuous Delivery and DevOps Company: http://www.praqma.com/

● Ian Buchanan (Atlassian): Why agile isn't agile without continuous delivery, https://www.atlassian.com/continuous-delivery/why-agile-development-needs-continuous-delivery

● Kief Morris (Thoughtworks): Continuous Delivery vs. Traditional Agile, https://dzone.com/articles/continuous-delivery-vs

● Jan Bosch (Chalmers): Speed and Innovation through Architecture,https://www.kth.se/polopoly_fs/1.354276!/Menu/general/column-content/attachment/Presentation,%20Jan%20Bosch.pdf

● DeliveryOfThings conference: http://deliveryofthingsworld.com/en/

https://continuousdelivery.com/

http://www.praqma.com/

https://twitter.com/devpartisan

https://www.atlassian.com/continuous-delivery/why-agile-development-needs-continuous-delivery

https://www.atlassian.com/continuous-delivery/why-agile-development-needs-continuous-delivery

https://dzone.com/users/473342/kief.html

https://dzone.com/articles/continuous-delivery-vs

http://softwarecenter.gu.se/contact-us/jan-bosch

https://www.kth.se/polopoly_fs/1.354276!/Menu/general/column-content/attachment/Presentation,%20Jan%20Bosch.pdf

https://www.kth.se/polopoly_fs/1.354276!/Menu/general/column-content/attachment/Presentation,%20Jan%20Bosch.pdf

http://deliveryofthingsworld.com/en/


●Conclusion

● Question: Being Agile without Continuous Anything -does that make sense?

● Short answer: No, most probably not.

● Long answer: Perhaps it's time to discuss, improve,get some consultancy if necessary, sleep better before the next release, …


Discussion

Source: http://code-maturity.praqma.com/agile-process/, snapshot from 2016-09-01, Copyright (c) 2013-2016 Praqma A/S