Get Started for FREE
Sign up with Facebook Sign up with X
I don't have a Facebook or a X account
 Your new post is loading...
Your new post is loading...
Scoop.it!
This blog looks at using the DevOps third way to build in continual improvement, continual learning, and increased resilience to your change practices. 
No comment yet.
Sign up to comment
Scoop.it!
DevOps is not going to work…. Unless! How The Phoenix Project Simulation Can Help Jan Schilt, Owner Founder, GamingWorks BV This presentation will explore how the business simulation game “The Phoenix Project” based on the book of the same name can greatly improve the success of your DevOps investment.
Mickael Ruau's insight:
As case studies reveal there are enormous benefits to be realized by adopting DevOps, however industry trends reveal that many will fail as a result of ‘Cultural and behavioral’ issues and failing to adequately address organizational change. We have seen with ITIL how many organizations failed to gain the promised benefits because they could not translate the theory into practice and the belief that a tool would solve all their issues. Let us not make the same mistakes with DevOps.
In this presentation we will show you how a business simulation can increase the velocity of your adoption, create buy-in, improve communication and collaboration skills between Dev and Ops, and capture concrete, shared, improvement actions aimed at creating success.
Scoop.it!
The Phoenix Project has been an introduction to Devops for many and is one of the books we all recommend for newcomers. We will quickly cover the main takeaways of the book in a quick five-minute setting.
Mickael Ruau's insight:
Scoop.it!
It became very apparent the model wasn’t working; we were doing it wrong. We were not the first team to recognize the problem. There were services before us, like Bing, that saw this. And we started observing the best practices of some of the companies born in the cloud
In other words, we pushed testing left, we pushed testing right and got rid of most of the testing in the middle. This is a departure from the past where most of the testing that was happening in the middle – integration style testing in the lab. The rest of the document describes #1 in a little bit more detail.
Mickael Ruau's insight:
The Org Change for Quality OwnershipWe did ‘combined engineering’ – a term used at Microsoft to indicate merging of responsibilities for dev and test in a single engineering role. It is not just an organization change where you bring the Dev and Test teams together. It is an actual discipline merge, with single Engineer role that has qualifications and responsibilities of the SDE and SDET disciplines of the past. Everyone has a new role, everyone needs to learn new skills. This is a very important point. When we talk about combined engineering, a common question we get is how we trained the former testers. We had to train both ways. A former developer had to learn how to be a good tester and a former tester had to pick up good design skills. Managers had to learn how to manage end to end feature delivery. In this model, there is no handoff to another person or team for testing. Each engineer owns E2E quality of the feature they build – from unit testing, to integration testing, to performance testing, to deployment, to monitoring live site and so on. Partnership with other engineers is still valued, even more so. There is now greater emphasis on peer reviews, design reviews, code reviews, test reviews etc. But the accountability for delivering a high quality feature is not diluted across multiple disciplines. This was a big cultural shift across the company. This change happened first in one org, but then over a few years, every team across Microsoft moved to this model. There are some variations to this model but at this point there are no separate dev and test teams at Microsoft. They are just engineering teams with the combined engineer roles.
Scoop.it!
In this slide deck I try to explore the meaning of the often misinterpreted sentence "You build it, you run it". Starting with its origin in a 2006 interview with Werner Vogels and a short description of the misinterpretation of that phrase that can be seen quite often these days in companies that try to pick up concepts like DevOps without really getting the idea behind it, I then start a bit longer journey.
Mickael Ruau's insight:
The traditional process organization - while usually being set up nicely for cost efficiency - is very poor in terms of cycle times. In order to shorten cycle times those organization will eventually become cross-functional, autonomous teams with end-to-end responsibility. And while those teams have all skills and the full authority for all their activities, they also need to take over the full responsibility for their actions - their is no one left to blame ;) And this naturally leads to "(You decide it,) you build it, you run it" which in the end is a required organizational prerequisite for going fast in a DevOps way.
Scoop.it!
In the talk, after a short motivation, I try to take stock of the current state of IT from different points of view. After looking at, where we came from and where we are, I add the most important trends I currently see that affect us in IT.
But knowing where we came from, where we are and where we are going to usually is not enough. The key point is using this information - in this talk for evaluating your current position as a software engineer and figuring out your desired future position.
Scoop.it!
Learn how a large global enterprise journeyed toward a successful DevOps digital transformation, including process, planning, and pilot programs.
Mickael Ruau's insight:
Hewlett Packard Enterprise (HPE) figured out the secret to moving toward DevOps: start with a few sparks (passionate developers) and some dry tinder (well-chosen projects). Like any large enterprise, HPE faced its own challenges, such as silos, organizational roles, skeptics, project choice, and uncertainty about how to measure its success. But the large global enterprise is already reaping benefits from its ongoing DevOps journey. In Through the DevOps Looking Glass: Learnings from HPE’s Own Transformation Initiative, Stratecast and Frost & Sullivan take you through the HP organization and its adoption of DevOps.
Scoop.it!
Le Blue Green deployment devient un pattern de déploiement très répandu dans le monde du devops. Qu'est-ce le Blue Green deployment ?
Mickael Ruau's insight:
Premiers problèmes rencontrés avec le Blue Green deploymentSi au premier abord ce fonctionnement parait très simple, il y a rapidement des problèmes que vous rencontrerez si vous ne les anticipez pas en avance. Les sessions utilisateursLe problème le plus classique est la gestion des sessions. Comment faire migrer un utilisateur du Green au Blue sans que la personne soit déconnectée ? Il existe deux méthodes classiques comme celle de mettre la session dans un cookie et l’autre d’appeler un « dépôt » indépendant de type Memcache, Redis… Dans ce cas les utilisateurs passeront du Blue au Green sans même s’en rendre compte. Les bases de données pour le Blue Green deploymentAutre soucis classique, comment faire pour que les transactions commencées en Blue dans une base de données SQL puissent s’appliquer en Green si elles se commencent et se terminent après le déploiement ?
Scoop.it!
The key to moving faster lies in building and scaling a high-performing technology organization. "Accelerate" shows you why.
Mickael Ruau's insight:
Forsgren, Humble, and Kim spent four years “sciencing the crap out of DevOps,” as Forsgren puts it, analyzing data from the State of DevOps reports (presented by DORA and Puppet Inc.) to create a capabilities model for software-delivery performance using rigorous statistical methods.
Scoop.it!
Slides for a DevOps transformation simulation workshop from Scrum Gathering Prague 2015. An Agile game that engages all 5 senses and helps participants embrace…
Scoop.it!
![Accelerate: Building and Scaling High-Performing Technology Organizations [Review] - DZone Agile | Devops for Growth | Scoop.it](https://img.scoop.it/9KCZo5vXsQiZgvvgWT-lSTl72eJkfbmt4t8yenImKBVvK0kTmF0xjctABnaLJIm9)
Take a look at this review of Accelerate, a book from the authors of the State of DevOps report that provides some data-driven analysis of Agile practices.
Mickael Ruau's insight:
The data shows that there are patterns at all levels that successful Agile organizations share. In other words: becoming Agile can be data-driven, (a hypothesis that I shared in "How to Measure Agility of Organizations and Teams — The Results of the Agile Maturity Survey" earlier).
Scoop.it!
Three years, 20,000 DevOps professionals, and some science. Here are the findings as well as tips to help make your own DevOps transformation awesome.
Mickael Ruau's insight:
We love being able to say that IT performance is captured and can be measured by three things: lead time for changes (measured as the time from code commit to code deploy), deployment frequency, and mean time to restore service (MTTR) following an outage or incident.
|
Scoop.it!
To reinvent ourselves, to grow, to become better do we need to destroy our former selves? Some people need to burn all the way down to rise from the ashes like a phoenix. How does losing things you value help you recenter and focus on the things that truly matter? In this talk, learn how mindfulness helps to overcome tragedy and bind together your mental, emotional, physical, and spiritual wellbeing.
Mickael Ruau's insight:
Jesse Stewart is the founder of AM300 Solutions and author of The Phoenix Project (2019).
Scoop.it!
From
www
Comment organiser la transformation d'un service ou d'une entreprise, gérer la croissance et l'échelle des ressources humaines ? Yaniv Fdida, VP Delivery and Operations partage une méthode qu'il a déployée chez OVH pour atteindre l'efficacité organisationnelle.
Scoop.it!
From
xebia
Although many topologies have been documented, I believe that they are all variants of these three topologies: 1. All teams are product teams. Each team does everything that is needed to run their software including the use of any infrastructure components, usually cloud-based PaaS. 2. Internal platform team(s) and Product team(s). Product-teams make use of the infrastructure/platform-services provided by internal platform-team(s). Services provided by the platform-team(s) can range from infrastructure and “run” services such as monitoring to Continuous Integration tools and dashboarding tools. 3. Internal Platform team(s), Product team(s) and Site Reliability Engineering team(s) (SRE). This topology is based on Google’s best practices around running software. Product teams can gain the SRE teams’ support in running their software if they need it and if their software adheres to standards defined by SRE teams. SRE teams can also share on-call responsibility with product teams. The platform-team(s) provide infrastructure/platform-services. The DevOps topology that will have the best fit within your organisation is dependent on your current organisational hierarchy, scale, regulatory requirements and people’s skills. It is also important to recognise that any chosen topology has its pitfalls, which need to be dealt with.
Scoop.it!
'You build it, you run it' will force a company to eliminate every silo and create cross-functional teams. Robert Reeves explains how it's done.
Scoop.it!
MotivationOften development teams are totally unaware on how their software behaves in production and what the effect is on the end users. All problems are experienced by the operations department and any complaints are handled by first and second line support. The pain of low quality software is not felt by the developers. ApplicationCreate autonomous systems and build multidisciplinary teams around them that are responsible for the system in production.
Mickael Ruau's insight:
The principle "you build it, you run it". was used by Werner Vogels to explain the organisation of the development teams at Amazon. The Xebia Essentials CardsThis page is part of the Xebia Essentials, a pack of flash cards about Software Development Done Right. You can get your own deck of Essentials cards in the Xebia store.
Scoop.it!
Delivering value to the business through software requires processes and coordination that often span multiple teams across complex systems, and involves developing and delivering software with both quality and resiliency. As practitioners and professionals, we know that software development and delivery is an increasingly difficult art and practice, and that managing and improving any process or system requires insights into that system. Therefore, measurement is paramount to creating an effective software value stream. Yet accurate measurement is no easy feat.
Mickael Ruau's insight:
Survey Data Challenges• Precision. While you can query practitioners about broad strokes, you should not rely on them for detailed or specific information. When you ask about deployment frequency, your survey options increase in log scale: people can generally tell you if they are deploying software on demand, weekly, monthly, quarterly, or yearly. Those frequencies are easy to confirm with system-based metrics (when available—though that is a nontrivial metric to get from systems, because it requires getting data from several systems along the deployment pipeline). • Continuity of data. Asking people to fill out surveys at frequent intervals is exhausting, and survey fatigue is a real concern. It is better to limit the frequency of big data collection through surveys—say, every six months or so. • Volume. The amount of data you collect is related to how often you collect it. Experience tells us that surveys should be kept to 20-25 minutes (or shorter) to maximize participation and completion rates. There are notable exceptions: Amazon's famous developer survey was rolled out on an annual basis and took about an hour to complete, but the engineers were very interested and invested in the results, so they took the time to complete it. • Measures in strained environments. If management has made it very clear that it isn't safe to be honest, or that the results will be used to punish teams, then any survey responses will be suspect. To quote the late W. Edwards Deming: “Whenever there is fear, you will get wrong figures.” But, to be fair, system-based metrics are equally suspect in unsafe and fearful environments, and possibly more so. Why? Because it only takes a single person with root access to slip a rogue metric into the system and a tired person on peer review or a CAB (change approval board) to miss it (as those of us who have seen the cult classic movie Office Space can attest). In contrast, it takes several or dozens or hundreds of people to skew survey results en masse.
Scoop.it!
Test while building to maximize test effectiveness and minimize cost - Azure DevOps | Microsoft Docs
Unit testing is a commonly used practice for early detection of defects in software. One of its applications is regression testing, which ensures that software changes do not break any of the previously working functionality.
Scoop.it!
 Peering - WikipediaSince public peering allows networks interested in peering to interconnect with many other networks through a single port, it is often considered to offer "less capacity" than private peering, but to a larger number of networks.
Mickael Ruau's insight:
External linksWikinews has related news: Internet backbone hosts feud, disconnecting users
Scoop.it!
Alan, Ken Johnston, and Bj Rollison recently published How We Test Software at Microsoft (448 pages, ISBN: 9780735624252) in Microsoft Press's Best Practices series for developers. The authors have also created a website devoted to the book: HWTSAM (Information and discussion on the MS Press release "How We Test Software at Microsoft”), where you can read reviews, review the book’s table of contents, and see pictures of the book (in the wild indeed!). And Alan’s guest-post contains a lengthy excerpt from the book. Enjoy!
|
