Der Beitrag Erfolgreiche Veränderung im Unternehmen erschien zuerst auf impact matters Organisationberatung.

DEVOPS MOTIVATION

DevOps ist nie das Ziel, sondern Mittel zum Zweck. Die erste Frage ist daher: «Warum DevOps?» und diese Frage für die konkrete Situation, in der Sie stecken, zu klären. Dadurch wird auch das nötige Dringlichkeitsgefühl erzeugt. Schon J.P. Kotter hat durch seine Studien früh erkannt, dass ohne diesen «Sense of Urgency» 50 Prozent aller Transformationen bereits am Anfang scheitern.

Für DevOps gibt es mindestens zwei gute Gründe:

• Digitalisierung: Ihr nächster härtester Konkurrent könnte ein Startup mit einer disruptiven App sein. Diese Firmen sind fähig, sehr schnell mit neuen und qualitativ hochwertigen Dienstleistungen an den Markt zu gehen und so schnell neue Ideen am Markt zu testen.
• Die IT-Abteilung in Ihrem Unternehmen ist gespalten; die Entwicklung will Flexibilität und der Betrieb strebt nach Stabilität und das Business hätte am liebsten beides. Silos und zersiedelte Prozesse überall. Wo ist hier der Value Stream «end to end»? So kann es nicht weitergehen:
  

DEVOPS ZIELE

“Schneller & besser” – so lassen sich die Ziele von DevOps grob zusammenfassen. “Schneller” bezieht sich primär auf die Time to Market, die Fähigkeit, neue Services in kurzer Zeit produktiv zu bringen und früh Feedback von Benutzern zu bekommen.  Häufigere Releasezyklen gehören ebenfalls auch in diese Kategorie. “Besser” bezieht sich auf Dinge wie Mean Time to Restore Service, Performance und Verfügbarkeit. 

Um den typischen Zielkonflikt von Stabilität versus Flexibilität zu lösen, bricht DevOps den Graben zwischen Entwicklung und Betrieb auf, indem die Sicht der Value Streams entlang von Produkten oder Services eingenommen wird. Und der Value Stream beginnt natürlich schon im Business, daher sprechen viele auch von BizDevOps.

DIE DEVOPS-UNICORNS ALS VORBILD

Firmen wie Netflix, Etsy, Spotify und Google haben DevOps in den Anfängen geprägt. DevOps entspricht ganz einfach ihrer Kultur, der Art und Weise, wie dort Dinge angegangen werden. Die Basis dafür war zunächst die agile Entwicklung um Produkte herum, d.h. in kleinen Teams, mit end-to-end Verantwortung,  inkrementell und adaptiv. Agil macht aber erst richtig Sinn mit DevOps. Der eine Aspekt dabei ist, nicht jedes Mal 2 Wochen auf eine Infrastrukturumgebung warten zu müssen (Frage: Wie lange dauert dann ihr Sprint?), daher der Druck Richtung Cloud, Infrastructure as a Code und Microservices-Architektur. Ein weitere Aspekt ist die Durchsetzung einer neuen ‘Definition of Done’, d.h. bei jedem Check-In werden alle Tests automatisiert durchgeführt, so dass man jederzeit produktiv gehen könnte (dann spricht man von Continuous Delivery).

Die Unicorns hatten es da relativ einfach, da ihr Setup von Anfang an auf DevOps ausgerichtet war, gebaut auf der grünen Wiese. Sie mögen sich jetzt fragen, wie sich das in Ihrem Umfeld realisieren lässt, das vermutlich von Legacy, langen Releasezyklen und vielfältigen Abhängigkeiten geprägt ist. Die Frage ist aber nicht primär, ob DevOps möglich ist, sondern der Punkt ist, dass DevOps notwendig ist, wenn man im Zeitalter der Digital Economy überleben will. Sonst macht es ein anderer. Beispiele gibt es genügend, wie dies im Enterprise Umfeld umgesetzt wurde. Und auch klar, dass das nicht für alle Bereiche relevant ist, sondern v.a. für digitale Services, über welche man sich als Firma nach aussen differenzieren will.

DEVOPS WERTE & PRINZIPIEN

Die Werte von DevOps lassen sich zusammenfassen unter dem Stichwort “CALMS”: Culture, Automation, Lean, Measurement und Sharing.

Ganz zentral bei der Umsetzung sind die “3 Ways”, welche ihre Ursprünge konzeptionell in der Lean Production haben und im Buch “The Phoenix Project” von Gene Kim das erste Mal formuliert wurden:

The 3 Ways

Zusammengefasst geht es darum, schneller und besser (=Ziele von DevOps) zu werden, indem…. 

• First Way: Increase Flow
  Die IT wird als Value Stream betrachtet mit folgenden darunterliegenden Prinzipien:
  • Understanding the flow of work
  • Increasing flow by understanding and removing constraints
  • Never passing a known defect downstream
  • Never allowing local optimization to cause global Degradation
• Second Way: Feedback
  Kurze und schnelle Feedbacksloops einbauen (Scrum lässt grüssen), mit folgenden Prinzipien:
  • Understand and respond to the needs of all customers – both internal and external
  • Shorten and amplify all feedback loops
  • Create and embed knowledge where needed
• Third Way: Continous Experimentation & Learning
  • Aus Fehlern lernen
  • Experimente als Quelle für Innovation

Die 3 Ways implizieren zwischen den Zeilen auch eine neue Organisations- und Führungskultur, ohne die DevOps nicht funktionieren kann: Weg von klassischen Management (Command & Control) hin zu einer selbstorganisierten Teams mit einer starken Verbesserungskultur. Weg vom Manager, hin zum Leader/Coach, welcher die Vision vorgibt und die richtigen Fragen stellt.

DevOps Leadership aka Lean

DEVOPS PRAKTIKEN

Nach all der interessanten Theorie nun zu den DevOps Praktiken, welche die ‘3 Ways’ konkret umsetzen. Vieles davon kommt aus der Lean und Agile Welt, aber auch aus dem IT Service Management. Schlussendlich nützt alles, was einen schneller und besser macht:

• Continuous Integration & Continuous Delivery Praktiken
  Ziel: Software jederzeit in einem ‘Releaseable’ State halten. Schaffung einer “Continous Pipeline”, Testautomatisierung, Cotinous Testing, Tool Chain, Cloud als Enabler, and so on
• Value Stream Mapping
  Eine bewährte Lean Praktik, mit der auch IT Value Streams & Bottlenecks identifiziert und letztere eliminiert werden
• Kanban
  Die Arbeit in Teams nach Lean Prinzipien managen. Oft ein erster Schritt
• Rugged DevOps
  Security Praktiken früh in der Continuous Pipeline einbauen
• DevSecOps
  “Jeder ist verantwortlich für Security”
• ChatOps
  Störungsbehebungszeit drastisch reduzieren durch die Verwendung von Collaboration Tools über alle Support Levels hinweg
• Toyota Improvement KATA
  Eine struktuierte Methode, umd eine Lern- und Verbesserungskultur zu schaffen
• ITIL Praktiken wie Problem Management und Event Management
  Unterstützen v.a. den “Second Way”, d.h. Feedback aus Operations zur Verbesserung der Stabilität

GETTING STARTED

Wie gehe ich das nun an? Dafür gibt es kein Rezeptbuch. Jedes Unternehmen ist anders. Ein guter Startpunkt ist immer, sich über das eigene “Why DevOps?” im Klaren zu werden. Ohne ein Dringlichkeitsgefühl, z.B. das dein nächster härtester Konkurrent ein Startup mit einer App wird, ist jede Transformation zum scheitern verurteilt. Entscheidend ist auch klare Ziele zu formulieren und messbar zu machen (z.B. Time to Market). Sonst wird man nie feststellen können, wo man steht und ob man besser wird. Und: DevOps ist kein Endzustand, sondern eine Reise die nie aufhört. Das kann mit kleinen Dingen beginnen, wie Value Streams zu identifizieren und Schritt für Schritt Bottlenecks zu eliminieren. Und zu guter bildet die richtige kulturelle Basis den Kern, denn “Culture eats strategy for breakfast“. Wenn die agile und lean Kultur nicht ins Herzblut der Mitarbeiter eindringt, scheitert eine DevOps Transformation.

Der Beitrag DevOps Essentials erschien zuerst auf impact matters Organisationberatung.

Is Agile the common sense we lost when building perfect plan/build/run silo organizations in the past? In contrast, Agile Cargo Cult – blindly following Agile frameworks – is common too. But without any sense. Agile is so easy and difficult at the same time.

Agile and New Work have gone many BS directions in the past. Because the marketing label „Agile“ sells on the market, it can be anything. To the joy of many Agile Dislikers, because this BS gives Agile a bad name.

People often forget that Agile is nothing new at all: Agile, as the ability to be adaptive, to continuously reflect & learn and to take responsibility as a team for a product or service, the customer in the centre. The point is simply that Agile has become much more relevant for success in a VUCA world (Volatility, Uncertainity, Complexity, Ambiguity) and more important, in a world where employees find motivation in purpose and autonomy. Agile principles and frameworks (which have decades of history, too) can help us adults to avoid total chaos, by providing some minimal structures and guidance around that. They can help balancing stability and flexibility on a very high level. But they are nothing worth without the right growth mindset in place and continuously reflecting & adapting your own structure to make Agile work for you.

Time to bring back some common sense to Agile!

 

Common sense is not so common

Sometimes we have to learn things the hard way. So do I. Five years ago, when giving a product owner training to a mid-sized bank, I asked the following naive introduction question to the participants:

„Whom of you belongs to BUSINESS, whom of you to IT“?

Of course this was a catch-22 question, but then something unexpected happened. „This is not our way of working. Business and IT are usually both in the same team, we are one team, taking jointly accountability for a product with close collaboration and short feedback loops„. Needless to say they where very successful with that model and had a pretty clear governance behind it, but not bound to functional silos.

They really got it. This is how it should be. Agile common sense. This is what I was thinking to myself afterwards. One problem of my naive question was of course, that I presumed a common sense (the one of a traditional bank), which did not apply in that case. My first learning; Be cautious with common sense. Or as the brilliant French philosopher Voltaire said „Common sense is not so common“. Second: They effectively adapted one aspect of Agile, as a means to make an impact as a company: Close collaboration and feedback, one team culture, end-to-end along a product and the value stream behind it. Motivated people with purpose, because they are directly bound to what creates value (product/service) instead of being the functional purposeless cog wheel somewhere in the company.

 

Many facets of Agile common sense – all about customer and employee value

So what is Agile common sense? Above example shows just one aspect. But there are many other examples:

• It’s common sense to show something early to a customer if he doesn’t know what he wants. Early feedback and doing the right things early or otherwise loose millions of $$$
• Having plans is good, but sometimes you have to change these plans. Makes sense, right?
• What is the right way of working for us? It’s common sense to regularely retrospect the past, drawing learnings from it and apply changes to the future. Theoretical concepts will not survive first reality check, but can be a first step.
• Sometimes we don’t know what is beforehand the „right way“. But we have a hypothesis and need to and validate it, through experiments. There is no other way to find out.
• Leaders can’t know, too. But they can give a vision what we want to achieve and work with hypothesis.
• Motivation is a multiplier for performance an it makes sense that you organize people & teams around what motivates them: Autonomy and purpose, as endless studies from the last years show. Therefore autonomous product teams instead of functional silos, which have maybe perfect processes, but no individual purpose, many handovers and no flow.
• Agile does not stop at Development, it’s common sense that we should look at how value is created end-to-end. From inception to Operations, with feedback loops incorporated everywhere. This is also where DevOps comes in. For some reason, many people still think Agile is limited to software development.
• Besides all the autonomy, it’s common sense that we have to align, where autonomy is suboptimal. E.g. bring together all the Product Owners on a regular base, to develop good practices, that work in your company.

 

Implications for a successful Agile Transformation

Transformations are hard, take time and real culture change comes last. Looking at Agile, in a common sense way, can help you to be successful with that.

 

Start with the Why – in a tangible way. Include the „What’s in it for me?“

Starting with the Why is an advice you might already have heard of. It’s easy to do it the wrong way. Although many companies start indeed with the „Why are we doing this?“, I read often sentences such as „Agile will help us to succeed in a changing world“. This is just too generic and not tangible enough. It’s not common sense enough. Think about the examples in the bullet points above, adapted to your environment and with examples of the past where you missed that, with negative impact. This will make it tangible and senseful for everyone. What exactly is the customer impact and value you want to make with Agile? Agile is a means to an end.

What makes sense for the company as a whole doesn’t necessarely make sense for the individual employee. So „What’s in it for me?“ is a question most companies miss to answer. Will it make my daily work better? There are many fears around around that. Think about purpose and autonomy, which I mentioned already and are btw the #1 motivators, why employees come to work – according to many studies during the the last years.

 

You can only change culture through action. Common sense action.

At the end, nice words will not change culture and the way we work . It’s „doing things“, experiencing, seeing the benefits and learning from them, which change culture over time. People don’t resist change, they resist being changed. And people don’t resist their own ideas. This is the key for successful transformations and I found in particular the following instruments useful:

• Promote desired behaviour through servant-leadership and asking the right questions, instead command-control. People will come up up with the rights answers by themselves.
• Hold people accountable. Autonomy and purpose in form of self-organized end-to-end product teams is a privilege, but also an obligation. People have to show Skin in the game – no „this is not my responsibility“ anymore.
• Establish a sense of continuous learning. Most people think here about regular formalized retrospectives, but it can be any opportunities to reflect the past and make improvements real. On all levels – individual, team, program, leadership.
• Immersive experience in a „safe-to-fail“ environment: For example through an Agile or DevOps Simulations. People experience by themselves to retrospect, apply agile ways of working and see the results directly.
• Going with small steps in the transformation and incorporate learnings. Yes, you can make the transformation itself agile, too. Good practice comes from experience. Experience comes from bad practice.

Understand how to use agile Framworks the right way

As part of my job I give all kind of trainings, even with certification. I could now tell you they will solve your problems, but I won’t. Agile transformation is mainly a cultural thing. One thing I learned over time is that agile frameworks are mainly here to build some structure around our wish to be agile. Otherwise there will be total chaos and inefficiency. Scrum has here some good examples; Although the backlog is open for change at any time, the sprints should be rather protected. This helps to balance flexibility and stability. Same for the need of a clear product vision, which gives some long-term boundaries. Imagine this would not be the case – things would just change every day. Some call this Agile, I would call it chaos.

Look at agile Frameworks as a starting point – methodically. Adopting & adapting them is key, continuously. For example, Scrum and Kanban are different starting points methodically, but you can end up at the same point after a while.

When things get more complex – focus on reducing complexity, not managing complexity

Successful transformation is supported by the top and grows from the bottom. It’s a journey and you will face many challenges and obstacles on it’s way: All kind of dependencies, monoliths, an so on. One fallacy is that we often try to manage complexity instead of reducing it. Putting all kind of processes, handovers and heavy governance „on top of Agile“. You will end up where you have been before, loose all Agility and the impact you wanted to achieve originally. The famous „Water – Agile – Fall“ is just one example. Instead, build the whole system in a way that this becomes obsolete: Decoupled architecture (business and it architecture), infrastructure as code, the rule of small teams and scaling agile principles program and portfolio level. A topic on it’s own!

Finally, I hope this article gave you some new insights and helped you to regain some common sense. Looking forward for feedback!

Do things that make sense. And hey, Agile is just one means to and end. It’s impact that matters 🙂

Der Beitrag Bringing common sense back to Agile erschien zuerst auf impact matters Organisationberatung.

State of Agile 2019 and the problem we are facing

In the recently published 13th State of Agile Report, 73% of the respondents stated that they currently have DevOps initiatives in their organization or are planning a DevOps initiative within the next 12 months. It also states „organizational culture“, „resistance to change“ and „inadequate management support“ as main challenges for agile success. Hmm…, every year the same challenges. All no surprise to me. Why? Although 97%  of the 5000 respondents all over the globe claim they use agile development methods (some of them may even made a real cultural change including leadership) this is what I see in reality:

• How can we even talk about agile when we still have widely Water – Scrum – Fall situations: In front of the customer an IT demand management, passing over requirements the „agile team“,  handing over to integration and various test phases?
• Silos – Cultural, functional, incentives: Developers wants change, Operations wants stability. What does the Business want? Functional teams with different goals and bosses with different incentives. Does anyone understand the end-to-end flow?
• Provisioning: How long does your 3 week Sprint take when you wait 4 weeks for the firewall change? How can we be agile if we still have monolithic systems and dependencies, which hinder agility?
• „Them and Us“ blaming cultures instead of common goals towards customer value

DevOps  (just in a nutshell to make the link to the rest)

First of all: DevOps is a movement and not a framework, with the goal to become faster and better. Originally influenced by Unicorns such as Spotify, Netflix and Netsy, it brings together various ideas from Agile, Lean and IT Service Management. It comes to life through emerging practices that are delivering real value in real enterprises.

The DevOps Why? Pretty simple and convincing:

• Your next competitor could be Google or another unicorn. These unicorns are able to act extremely quick, make experiments and bring new robust products on the market
• Siloed organizations: Developers wants change, Ops wants stability. Silos, „no skin in the game“ and handovers everywhere – it can’t go on like this

The core principles of DevOps build around the 3 Ways:

1. Understand and increase flow – from inception to value delivery
2. Shorten and amplify feedback loops
3. Continuous learning and experimentation

These principles are supported by various practices. The following image summarizes this up pretty well:

DevOps in a Nutshell

The term „DevOps“can be pretty misleading, it should actually be something like „BizDevSecQAOpsRun“, as it was always the intention to cover the end-to-end value stream. So consider it just as a label – it’s a typical American reduction 😉

Both scenarios – waterfall an agile – can benefit from DevOps. DevOps as an enabler for Agility (which the blog is referring to) enables earlier feedback (faster), releasable software within a cycle (better) and end-to end accountability within small team units.

So let’s focus now on some practices, which I want to share in the following and which I saw successfully used at various companies.

Value Streams and Value Stream Mapping: Starting where you are

Unless you are a startup and can therefore pursue a „greenfield“ approach, it is very wise to start where you are. So let’s get all involved on a table, visualize and optimize work along the flow and put customer value into the center! The first thing to realize is that we should organize and collaborate of „what creates value“. Products and Services create value! This can be for example an application, internal (used by the business) or external (an e-banking app). But also supporting product/services like infrastructure or a monitoring services which are effectively used by the first mentioned ones. Behind each product/service there is a current value stream, e.g. from inception to release (this is actually when value is created).

With the goal to improve, A Value Stream Mapping workshop follows typically these steps:

1. Visualize and agree on a current Value Stream: How does work currently flow through the organization – across the silos? Not how it is documented and how we intend to work, but how we really work (Gemba!)
2. Identify main bottlenecks: Where do we wait? Where is the waste? Where do we have unnecessary handovers? Where do we detect issues very late?
3. Prioritize and agree which bottlenecks to address first
4. Find improvement measures for it, having the end-to-end picture in mind: Things like automation, test improvements, shorter feedback loops.

A real-live Value Stream Mapping example

I had the opportunity to lead such Value Stream Mapping Workshop several times. From my point of view VSM is a good starting point to identify where current issues with products and service value streams and make quick improvements that matters. And the team is usually commited to them, because it’s not a manager or consultant who tells them what to do, but it’s themselves.

So what about DevOps mindset and cultural shift?

Over the last 2 years there has been a strong emphasize on mindset / culture shift towards agility and lot’s of publications around that. Right, „culture eats strategy for breakfast“ (Peter Drucker) and yes, you can do perfectly do Scrum, but not be agile at all. But how do we change culture? It’s not through nice words (values, manifesto etc), but through actual behaviour. At a certain point new behaviour becomes culture – just „the way we do things“. This is why „doing“ new practices is so important and over time it just becomes culture. Written values & principles is culture made explicit and can support from the other side. Culture change is hard indeed and takes time, and I actually like this illustration to show what it means on employee as well on leadership level:

From traditional to DevOps mindset – people organize and collaborate around products and value streams

Having „Skin in the Game“ is key for the DevOps mindset – feeling accountable as a team for a product or service end-to-end. And btw – if I talk about team I don’t mean org chart boxes, but rather people who build around the same goal (product->customer success) and closely collaborate around that.

It’s a System of Systems – decoupled, autonomous and optimally aligned

People build around products/services and the value streams behind it. DevOps brings Agile to the next level by looking at the end-to-end value streams behind them. One of the big challenges I see in many companies is on how to design the whole system, that teams can act autonomously and at the same time aligned with each other. On top, it makes sense to differentiate between outside services and enabling services – such as monitoring, infrastructure as code & shared testing practices – as own value streams, decoupled from the rest. This also requires that instead of trying to manage complexity (through cumbersome processes and handovers), you rather reduce complexity by getting rid of dependencies, which usually needs a lot of work on architecture side (decoupling).

Outside In: Autonomous teams, aligned with each other. With some examples.

In one of my next blogs, I will go deeper into the question of Scaling, Organization Design, decoupled architectures and how to bring autonomy & alignment into the right balance.

Shift Left

New mindset & culture, real improvements – how can we actually change? Besides putting value streams in the center, building people around that and making them accountable: Shift left is one of the main practices. Shift left is about building quality very early into the product or service. By shifting left, fewer things break in production. An example out of the software world: Whenever code is checked in during development, security scripts automatically run, to ensure compliance with certain security guidelines. Shift left pursues instant feedback & correction instead of very late detection (which is typical for waterfall setups).

What does this concretely mean – coming out of an agile setup, but still with many silos around that?  Question: As an Agile team, when do you consider something as done? When it’s tested, to what extend? What about things that have been always considered as „somebody else’s“ responsibility?

Shifting left in an Agile environment

So practically there are two things to consider from an agile perspective:

• Shift left by gradually improving the definition of done
• Make Ops part of the team AND  reflect non-functional requirements part of the product owner and the product backlog

Continuous Integration / Delivery (CI /CD) & the DevOps Pipeline

Ok, I am now getting a little bit more technical, but besides people & process aspects , DevOps will not work without technology! Remember about Value Stream Mapping? And let’s go now beyond the „As is“ Value stream, which is usually full of manual steps and silos. If you could start from the scratch – what about that:

• Software is always in a releasable state. When I check in code into a shred respository, the various environments are automatically provisioned through the cloud and my features run down the DevOps pipeline. Automatically tested, from unit until functional- and non-functional tests.

Of course this is rather a vision than something you can achieve tomorrow. But it is something you can move towards in small steps.

If you are familiar with Lean Management and the Toyota Producation System (TPS) you will realize that old lean principles just have been applied to software development:

DevOps Pipieline: Negative feedback – stop the line! Source: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble

While Continuous Integration is quite a common practice, Continuous Delivery brings the Value Stream to a new level and a completely new way of working, because software is always in a releasable state. The DevOps pipeline acts as a vehicle and enables agility:

• Fast delivery of requirements, tested and enabling real feedback from the customer
• Enabling fast experiments on the markets: Does the customer really wants this? Are we right with our hypothesis? The Google way of success

There are a lot of implications out of that and effective CI/CD will not work without Infrastructure as Code (IaC), a new way of testing and automation, which I want to to touch next.

Infrastructure as Code (IaC) and decoupled architecture

With IaC, infrastructure is programmatically provisioned through the DevOps pipeline. Literally a line of code. For example a test environment with a certain configuration, within seconds. The cloud, internal or public, plays a significant role in that, for example an Amazon AWS with a Redhat Openshift instance on top. Interesting from a business perspective: These platform come with a high robustness in itself, something Ops was dealing with in the past in a cumbersome way. One conclusion for me: In „DevOps“, the role of „Ops“ is not to bring stuff into production, but to make it easy for the products teams that they can do it by themselves. By provisioning powerful and reliable infrastructure inclding the platforms on it. And it brings also a new reasoning for the cloud; In the past, many of the large enterprise cloud initiatives were done to save cost – provisioning of cheap and scalable storage on demand. A second reason was the replacement of commodity services such as eMail and CRM (Software as a Services).  In the context of DevOps, the business case of the cloud is being an enabler for effective CI / CD.

A new emerging practice in this context is Site Reliability Engineering (SRE). Very much influenced by Google, the goal of SRE is to to create an ultra-scalable and highly reliable infrastructure and operations, on which the products and services build on. From an architect view it includes redundant and partitioned environments, decomposed into small services with decoupled deployments and monitoring/debugging hooks at all levels. This is what’s happening when a software engineer is tasked with what is used to be called operations ;-). I had the opportunity to attend the DevOpsDays Zurich last week, where Mary Poppendieck gave some great insights on the current state of SRE.

Automation Practices

The earlier mentioned DevOps pipeline, which steers the value stream through the various stages, is initiating various tests, monitoring, but also deployment. This only works if you improve and automate these rather specialized steps. For example, each check-in might include a performance test. Of course you don’t want to do this manually, but automate it. For example by using a Loadrunner script, which is called by the DevOps pipeline. DevOps has brought up a whole universe of tools – the whole trick is the make a toolchain out of it, with no breaks. One manual break -> no real CI/CD. Here just an example how this could work with Jenkins and a small selection of tools:

Example toolchain with DevOps Pipeline (automated stages) and specialized automations on each stage (lower part of image). Source. cPrime & Cloudbees

How can we effectively move forward in our automation efforts? My experience and my tip: Automation is something that you have to approach gradually by asking the following questions:

• Looking at the current value stream – where do we have manual steps, where do we have breaks?
• Business case: Where does it hurts the most? Where do we have the most benefits? What would be the cost/efforst behind an individual automation?
• Out of the prioritized list, you start with the top one, reassess and move forward

Again, we can close the loop and make the link the value stream – end to end and the customer value in the center!

New Ways of Testing

CI/CD enables you to get feedback fast and early. In DevOps, testing is happening continuously by executing automated tests as part of the deployment pipeline to obtain immediate feedback on the business risks associated with a software release candidate. I partially covered this already with Shift Left and the practices just mentioned.

On a mindset and organizational level, it also means, that testing is not the responsibility of somebody else. It’s the responsibility of the product team – skin in the game! – and they work on together to improve on that. Some additional practices might help you here from my experience:

• Test Driven Development (TDD): Requirements are defined in form of a test case, automated and integrated into the DevOps pipeline – before you start to build! This is especially important for regression tests.
• Having production-like environments.
• The product team is accountable, but I have seen success stories where common testing practices (e.g. performance) is offered as a shared service to to the product teams. Bring autonomy and alignment into the right balance!

How to approach it? See last chapter! (automation)

DevSecOps

DevSecOps as a practice has gained it’s own momentum and embraces Security as Code, shift left security testing Strategy and testing automation. Practices already explained in general in this blog, but now specifically applied to the security domain. The purpose and intent of DevSecOps is to build on the mindset that „everyone is responsible for security“ with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required domain. There are many practices around that, which I don’t want to go deeper (This blog is already way to long), but I found https://www.devsecops.org/ a great source of ideas.

Antifragility & Chaos Engineering

One of the biggest concerns of Unicorns like Netflix is that the whole system goes down because of a major incident. This is also a major concern for traditional companies, especially for applications directly used by their client.  The challenge with many major incidents is, that they do not occur because of constellations you were thinking of, but rather because of the ones you didn’t. They are hard to predict. In here comes the concept of antifragility and I love the picture of the weed in the garden, which becomes stronger if you cut it. Or the Borg from Star Trek („resistance is futile!), which become stronger if they are attacked, because they learn from the enemy. These are examples of antifragily systems. They are different from robust systems, which are built for a certain purpose and also resist certain attacks (think of a medieval castle), because they learn from unpredictable situations.

Sounds like science fiction? Netflix is actually a good example of a real-live implementation. By randomly shutting down live containers, injecting other failures and closely monitoring the system, they can anticipate major incidents and take measures to prevent them. Another example I personally used was engaging trusted hackers and let them try to get into your system – a way to learn from that and preventing happing it in reality.

Rediscovering IT Service Management practices – by taking a new perspective and a new approach

IT Service Management, mainly represented by the framework ITIL, has been bashed a lot in the las years. And yes – there has been a lot of damage done – not because of the framework itself, but because of the implementations. ITIL processes have been implemented 1:1, leading to bureacracy, instead of adopting and adapting it in a lean way to the company’s goals. Organizations have been siloed and the value stream broken by making departments named by the titles of the ITIL books: Service Strategy, Service Design, Service Transition and Operation. Exactly what we don’t want today.

IT Service Management has brought up a lot of proven practices (I don’t call them processes by purpose), which smoothly integrate into DevOps and Agile and from which agile Product Team can learn a lot:

• Problem Management Practice: Preventing Incidents by identifying common root causes (=Problem), addressing and actually preventing them
• Event Management Practice: Very useful for continuous monitoring within the DevOps pipeline
• Thinking in Services, not Products: A Service is more than a product and Agile Product Owner can learn a lot from IT Service Management to incoporate especially non.functional requirements into their backlog
• And others like Incident Management, Service Catalogue Management and Request Fulfilment

Other practices: ChatOps and AIOps

Interesting as well. But for the sake to make this blog not too long I will stop with the practices here!

So what to do with all that? The Transformation Part

Now closing the loop, taking advantage of DevOps practices can be a next step in Agile, by looking at the value streams end-to-end, enabling fast and early feedback and overcoming silos in a company.

So where to start with that? DevOps is a journey and often embedded in an existing Agile Transformation and it’s goals. From that perspective there is not such a thing as a DevOps transformation, isn’t it? At the end, it’s all business transformation.

As in all transformations, it is always good to start where you are and moving towards a clear vision. One the one hand it is an excellent starting point to look at the value streams as outlined earlier. On the other hand a clear strategy outline is needed with the direction you want to go.
DevOps is a journey, which is different for every company, so make the journey itself Agile as well. Working with hypothesys (What do we believe is the right next thing for our organization) and validating this as early as possible to take the right next decisions. Nothing worse if you go a fixed transformation path and find out very late that this was the wrong direction.

All practices mentioned in this blog will help you to fill the transformation with life.

A model I use very often for transformation is the following one – Starting with a Vison and followed by a never ending circle of Assessment, Strategy, Pilot/Rollout and Reassessment:

Although DevOps is a continuous journey, I believe that you have to get some parts right at the beginning, which sometimes require „hard“ decisions:

• Skin in the Game: The Base for DevOps are the value streams and people buliding and collaborating around that. Make them accountable for it. The mindset „not my responsibility“ will just lead to no skin in the game and nothing will happen
• Measurement: Build up measurements such as Time to Market, Employee & Customer Satisfaction and stability to know if you are improving and measure it from the beginning

That’s (almost) it! Hope this helped – looking forward for feedback and intersting discussions!

Stay tuned!

Der Beitrag Agile: Dead End? Taking the next step by applying DevOps Practices effectively erschien zuerst auf impact matters Organisationberatung.

When do you consider something as done? How can you improve?

In functionally siloed organizations we see often no skin in the game – „not my responsibility“.

Build people around products and services, give them accountability and let them work on their definition of done.

Watch my Ignite Talk at DevOps Days Zurich, May 15th 2019. Clipped from live Stream:

Der Beitrag What is your done? erschien zuerst auf impact matters Organisationberatung.

• Silos zwischen Business, IT Entwicklung und Betrieb: Die einen wollen Flexibilität, die anderen Stabilität. Das Business will Beides. Brüche, Handovers und zersiedelte Prozesse überall. „Not my responsibility“. Wo ist der Value Stream – end to end? So kann es nicht weiter gehen.
• Dein nächster härtester Konkurrent könnte ein Unicorn mit einer disruptiven App sein: Unicorns sind fähig, sehr schnell mit neuen und qualitativ hochwertigen Dienstleistungen an den Markt zu gehen und schnell neue Ideen am Markt zu testen. In dieser „Digital Ecomomy“ ist es eben nicht der grosse Fisch, den den kleinen Fisch frisst, sondern der schnelle Fisch frisst den langsamen. Und: Keine Branche ist davon verschont. Und natürlich ist das nicht für alle Deine Produkte relevant (Bi-modale IT lässt grüssen).

Nachdem Du Dir über Dein „Warum?“ im Klaren bist und Dir für die Bereiche, wo dieses relevant ist, entsprechende Ziele gesetzt hast (und diese auch messen kannst), kannst Du zum Beispiel Folgendes tun:

• Deine Value Streams entlang von Produkten identifizieren – von der Vision, den Anforderungen bis hin in den Betrieb
• Cross-functional Teams schaffen und diese auf die Value Streams ausrichten und eine Kultur mit gemeinsamen Zielen schaffen (statt Dev: Flexibilität vs Ops: Stabilität)
• Die Grundlagen für Continuous Delivery schaffen, d.h.Entwicklungs- und Testplattformen sollen schnell zur Verfügung stehen, die Cloud (PaaS) ist die Grundlage dafür. Bis hin zu „Infrastructure as a Code“ und modularisierter Architektur
• Kontinuierlich Automatisierungspotential identifizieren und nutzen, z.B. Tests automatisieren, Deployments automatisieren
• Schnelle Feedbackloops einbauen, um Fehler früh zu identifizieren
• Eine Continuous Delivery Pipeline schaffen
• Mit einer entsprechenden „Tool Chain“ entlang der Delivery-Pipeline schaffen, ohne Brüche (sonst kein Continuous Delivery)
• Eine agile Kultur schaffen, neu auch mit Leuten aus dem Betrieb (welche lange dagegen angekämpft haben). Als erster Schritt kann das auch einfach mal ein Kanban Board sein, und dann lernen es die Leute mögen (Denn: Culture eats Strategy for Breakfast)
• Kontinuierlich Value Stream Mappings durchführen. Wo sind unser Bottlenecks? Wo können wir uns verbessern?
• Und last but not least: Realisieren, dass Du nicht zum vornherein wissen kannst, was funktioniert, sondern du auch ab und zu „fail safe“ Experimente eingehen musst um zu verstehen, was bei Dir funktioniert und was nicht.

Dies ein paar Beispiele, diese Liste liesse sich um viele weitere „DevOps Practices“ erweitern. Dabei soll es auch klar sein, dass DevOps nicht ein einmaliges Projekt ist, sondern eine Reise, die nie aufhört. Alles, was hilft, schneller (z.B. Time to Market) und besser (z.B. Service-Verfügbarkeit & Customer Experience) zu werden, und einen Lernprozess von innen zu etablieren (agile Kultur), nützt. Und Experimentieren ist dabei ein wichtiger Bestandteil, solange dahinter klare Ziele und eine Vision steckt. Funktioniert Kanban bei Dir? Don’t know. Try it and you find out. Klein anfangen und daraus wachsen.

Der Beitrag You can not „Do“ DevOps, but you can…. erschien zuerst auf impact matters Organisationberatung.

1) Die Essenz von DevOps verstehen

Firmen wie Netflix, Etsy und Spotify – die sogenannten «Unicorns» – haben DevOps in den Anfängen geprägt. DevOps entsprach ganz einfach der Kultur, der Art und Weise wie dort Dinge angepackt wurden. Die Basis dafür bildete zunächst die agile Entwicklung um Produkte herum, d.h. in kleinen selbstorganisierten Teams, mit end-to-end Verantwortung (you build it, your run it), inkrementell und adaptiv. Agile Entwicklung macht aber erst richtig Sinn mit DevOps. Der eine Aspekt war dabei, nicht jedes Mal 2 Wochen auf eine Testumgebung warten zu müssen (Frage: Wie lange dauert dann ihr Sprint?), daher der Druck Richtung Cloud, Infrastructure as a Code und Microservices. Ein weiterer Aspekt war die Durchsetzung einer neuen ‚Definition of Done‘, d.h. bei jedem Check-In werden alle Tests automatisiert durchgeführt und dadurch schnelle Feedbackzyklen erreicht, so dass Software jederzeit in einem «releaseable State» ist – dann spricht man von Continuous Delivery. Das Resultat: Kürzere Time to Market und gleichzeitig hohe Stabilität.

Einen entscheidenden Schritt machte die DevOps Bewegung, als grössere, traditionell geprägte Firmen (die sogenannten «Horses») angefangen haben, sich für das erfolgsversprechende Modell der Unicorns zu interessieren und auf ihre Situation zu adaptieren. Und das ist dann die Geschichte, welche wir alle kennen: Die funktionale Trennung von Entwicklung und Betrieb, Bestrebung diese mit gemeinsamen Zielen, einem gemeinsamen «Flow» aufzubrechen, mit kontinuierlichen Feedback-Loops und konsequenter Automatisierung.

2) Das eigene «Warum DevOps?» erkennen, daraus eine Vision und Ziele für die relevanten Bereiche ableiten und die Zielerreichung messbar machen

DevOps ist nie das Ziel, sondern Mittel zum Zweck. Die erste Frage ist daher: «Warum DevOps?» und diese Frage für die konkrete Situation, in der Sie stecken, zu klären. Dadurch wird auch das nötige Dringlichkeitsgefühl erzeugt. Schon J.P. Kotter hat durch seine Studien früh erkannt, dass ohne diesen «Sense of Urgency» 50 Prozent aller Transformationen bereits am Anfang scheitern.

Für DevOps gibt es mindestens zwei gute Gründe:

• Digitalisierung: Ihr nächster härtester Konkurrent könnte ein Startup mit einer disruptiven App sein. Diese Firmen sind fähig, sehr schnell mit neuen und qualitativ hochwertigen Dienstleistungen an den Markt zu gehen und so schnell neue Ideen am Markt zu testen. Die Zeit wird es zeigen, aber vermutlich wird keine Branche davon verschont bleiben.
• Die IT-Abteilung in Ihrem Unternehmen ist gespalten; die Entwicklung will Flexibilität und der Betrieb strebt nach Stabilität und das Business hätte am liebsten beides. Spaltung und zersiedelte Prozesse überall. Wo ist hier der Value Stream «end to end»? So kann es nicht weitergehen.

Aus diesem «Warum», das in jedem Unternehmen eine andere Ausprägung kennt, gilt es nun eine Vision und konkrete Ziele zu entwickeln. Im Fokus steht die Verbesserung des Time to Market und der Stabilität. Die formulierten Ziele sollten messbar gemacht werden. Nur so können Sie wissen, wo sie stehen und ob Sie sich während der Umsetzung verbessern. Dabei sollte auch nicht die ganze IT in den gleichen Topf geworfen werden. DevOps kann vor allem für die IT Services relevant sein, über die sich das Unternehmen gegenüber dem den Mitbewerbern differenziert. Dort ist DevOps matchentscheidend für den Erfolg des Unternehmens, Geschwindigkeit und gleichzeitige Stabilität sind Markt-Differenziatoren. Aus genau diesem Gedanken heraus haben einige Unternehmen begonnen sich Richtung «bi-modale IT» zu entwickeln, d.h. die Aufsplittung in eine «schnelle» und «langsame» IT. Dieser Schritt ist oft notwendig, aber auch umstritten, da sich so schnell eine «Zwei-Klassen-IT» entwickeln kann und so wieder neue Silos entstehen.

3) Teams entlang von Value Streams organisieren

DevOps versucht den Graben zwischen Entwicklung und Betrieb vor allem dadurch aufzubrechen, indem die Sicht der Wertschöpfungskette, des sogenannten «Flows», eingenommen wird. Beginnend mit der der Vision, über die Anforderungen bis hin zum Deployment. Die Basis bildet dabei der agile Flow (z.B. Scrum). DevOps hat diesen um Continuous Delivery erweitert, d.h. durch entsprechende Testautomatisierung und Feedback-Loops kann Software immer in einem «releaseable State» gehalten werden.

Dies erfordert neue Zusammenarbeits-Modelle, für die agile Community jedoch nicht ganz so neu. Eine enge Zusammenarbeit entlang des «Flows» heisst, dass Teams, die vorher funktional getrennt waren und z.B. über «Hand-Offs» kommuniziert haben, näher zusammenrücken müssen. Ein immer häufiger anzutreffender Ansatz ist die Bildung von Squads. Das sind kleine selbst-organisierte Teams, welche die volle Verantwortung für ein Produkt übernehmen. Mehrere Squads werden dann in sogenannte «Tribes» zusammengefasst. Diese neue Form der Zusammenarbeit kann auch auf virtuellem Weg erfolgen, d.h. die Leute verbleiben funktional in Ihrer Linie.

4) Kultur

Kultur ist einer der Grundwerte von DevOps und eine auf Lean und Agile ausgerichtete Kultur ist eine der wichtigsten Voraussetzungen für den Erfolg von DevOps; denn «Culture eats Strategy for Breakfast». Dabei geht es nicht nur darum – wie vorgängig beschrieben – die Teams entlang von Produkten und Value Streams auszurichten, sondern auch eine neue Organisations- und Führungskultur durchzusetzen. Weg vom klassischen Management (Command & Control) hin zu selbstorganisierten Teams mit einer starken Verbesserungskultur und iterativem Vorgehen. Weg vom Manager, hin zum Servant Leader/Coach, welcher die Vision vorgibt und die richtigen Fragen stellt:

5) Die Reise Richtung Continuous Delivery, Automatisierung und Infrastructure as a Code beschreiten

Die einleitend beschriebenen «Unicorns» hatten insofern einfache Voraussetzungen, weil sie auf der grünen Wiese eine idealtypische DevOps Infrastruktur und Continuous Delivery Prozesse etablieren konnten. Konkret heisst dies:

• Infrastructure as a Code: Eine Weiterentwicklung des Cloud Gedankens. Entwicklungs-, Test- und Produktionsumgebung können in beliebigen Konfigurationen sehr schnell zur Verfügung gestellt werden; sprichwörtlich abgerufen durch eine Codezeile
• Automatisierung: Test-, Deployment- und andere Prozesse weisen einen hohen Automatisierungsgrad auf
• Continuous Pipeline und Continuous Delivery: Immer wenn der Entwickler einen Code eincheckt, werden alle notwendigen Tests automatisiert durchgeführt und die Bereitstellung erfolgt via Infrastrucutre as a Code. Der Entwickler bekommt dadurch sehr schnell Feedback – Fail often, fail early. Software ist auf diese Weise immer in einem releasable State.

Nun ist es allerdings so, dass die meisten Unternehmen in einer ganz anderen Situation stecken: Legacy überall, vielfältige Schnittstellen und ein tiefer Automatisierungsgrad. Oft kommt von dieser Seite das Argument, dass so ein Setup in einem Enterprise Umfeld gar nicht möglich ist. Aber eben: DevOps ist kein einmaliges Projekt, sondern eine Reise die nie aufhört. Das kann mit kleinen Massnahmen beginnen, welche in die oben beschriebene Richtung zeigen: Beispielsweise erste Prozesse zu automatisieren, um die Durchlaufzeiten zu beschleunigen. Oder erste Infrastrukturkomponenten in die zu Cloud migrieren, um die Bereitstellungszeiten zu verkürzen. Entscheidend ist, damit anzufangen und diese Reise kann gut und gerne einige Jahre dauern. Diese Reise nicht anzutreten wäre falsch, denn sonst tut es ein anderer. Und: In der heutigen Digitalen Economy ist es nicht der grosse Fisch der den kleinen frisst, sondern der schnelle Fisch frisst den langsamen.

Der Beitrag Fünf kritische Erfolgsfaktoren für eine DevOps Transformation erschien zuerst auf impact matters Organisationberatung.