Wow, nice article! I worked in a company like this and it was great! In the beginning, we had to coordinate too many things to get to production, but we changed that with CI/CD (configuring a pipeline) to deploy to production, and it was very nice. In that situation, we used Kanban, and it adapted very well.
once more, thanks! I didn’t know the article.. it’s amazing to read such good real life experience and it’s especially good to see that teams can be agile even in big companies such as Walmart.
Excellent as we've come to expect from you, Dave! I understand "The Guiding Principles of Maintaining Our Software in a Releasable State" well, but I would like you to delve more into the details about the first iterations, what approach (strategy, tactic, tips) to take when we start building and we don't yet have an MVP o version 0.0 (aka version oh .. oh .. 😃 )
There are trade-offs to breaking up dependencies and should be weighed when considering the move. At Amazon, I saw a team's CD broken often due to breaks in dependency tests failing. Systems were so large, developers needed to CI into main to see if things broke in the CI tests vs testing locally. Because of that, and the dependency checks in CD pipelines, CD pipelines could be blocked for days while dependent teams worked out their code issues.
I'm curious to hear more about the management changes at Walmart and how this impacted the progress made towards continuous delivery. I have not met a senior software leader (vp level or above) in the past decade that had any experience with continuous delivery, so I can see how a new leader might approach these delivery processes with skepticism. At the same time, many leaders tend to be pretty conservative and avoid wholesale changes which could negatively impact productivity. Did this new leader see efficiency problems with continuous delivery processes? Or was it just a case that these processes were unfamiliar and they were uncomfortable supporting them? My experience is that every new CxO wants to make their new company look like their last company, so you have to be really careful picking these leaders.
By design, SAFe cannot support continuous delivery. Why? The backlog is a function of PI planning, and PI planning classically happens 4 times a year. Cripples learning and discovery with telemetry. Call it legacy+, but it ain't agile. I bet Boeing wishes SpaceX was using SAFe so they could both compete on the same cadence 😆
Isn't the V model just waterfall? I don't see how it could be compatible - waterfall pretty much cannot do 'continuous' anything - it's big design up front, then build something nobody wanted, then deploy it all at once
@@StevenBorrie V Model is an evolution from waterfall, adding corresponding testing for every case, it is use a lot in car industry and aerospace (I'm not a fan but it is what it is) Audi combines the methodology with CI CD to create new models, they use other variation tho, V &V
Try some of these www.youtube.com/@ContinuousDelivery/search?query=Quality In particular this one "The Role of QA in SW Dev" ua-cam.com/video/XhFVtuNDAoM/v-deo.htmlsi=3jx5xgqUnF0DmAAt
Yes, I think it should, but I usually assume it as part of the "Production Phase" rather than calling it out explicitly, because it is at the same kind of level as "Infrastructure as Code" pretty much essential, but a technical detail.
@@ContinuousDelivery I agree that it is not part of the deployment pipeline, but it is dangerous if developers only focus on their deployment wheel which is spinning in one direction - towards the customer. As I see it, the flow of information FROM the customer is equally important. We can’t just care about our clean code, we need to care about our customers needs as well. How do they use our product? Which features do they don’t use? Which features do they want the most? Which bugs bother them the most? Which bugs are not actually affecting any customers? If we think that we ”fixed” a bug - can we verify that it actually doesn’t exist in production anymore? Continuous delivery needs to be combined with continous feedback - outside the CI.
Great case story and very well presented. How could one truely apply the CD principles in a safety-relevant industry such as railway systems where standards such as CENELEC EN 5012x prescribe waterfall processes? There are agile methods applied in these development projects, but they do not lead to CD.
It is certainly true that most regulatory regimes were created assuming a waterfall approach, but almost none of them rule out alternatives. My experience has largely been in highly regulated industries including finance, transport, telecoms and medical. I would argue that regulation is less of a barrier and more an imperative for CD. I argues that t is not really possible to be properly regulatory compliant without the rigour and traceability of CD. I have a blog post on this topic here www.davefarley.net/?p=285 that describes what I mean in more detail. This is certainly applicable to the rail industry, but it is a difficult process to re-assess the regulation in the context of CD. Fundamentally though CD is the safer approach, making controlled changes in smaller, safer steps works better than the alternatives.
@@davefarley77 Thanks for the quick response. I will study your blog post and hopefully find leads how to stepwise move to CD in our environment, i.e. our customer (a national rail company) accepts and receives a new release of the operations control software every two years.
Love this one Dave, much needed simplicity of focus in world of ineffective complex lenses that just create more waste and work. 👏
„The Phenix Project“ great book. loved it. 3:31
Wow, nice article! I worked in a company like this and it was great! In the beginning, we had to coordinate too many things to get to production, but we changed that with CI/CD (configuring a pipeline) to deploy to production, and it was very nice. In that situation, we used Kanban, and it adapted very well.
“Agility” being used like my corporate overlords use it. 😂 The word is one of our core-tenants now post-COVID.
Tenants, LOL.
each video takes you to a new level on understanding the development process, thanks :)
This is a great article for helping with buy in. If walmart can do it, surely anyone can
once more, thanks!
I didn’t know the article.. it’s amazing to read such good real life experience and it’s especially good to see that teams can be agile even in big companies such as Walmart.
Excellent as we've come to expect from you, Dave! I understand "The Guiding Principles of Maintaining Our Software in a Releasable State" well, but I would like you to delve more into the details about the first iterations, what approach (strategy, tactic, tips) to take when we start building and we don't yet have an MVP o version 0.0 (aka version oh .. oh .. 😃 )
There are trade-offs to breaking up dependencies and should be weighed when considering the move. At Amazon, I saw a team's CD broken often due to breaks in dependency tests failing. Systems were so large, developers needed to CI into main to see if things broke in the CI tests vs testing locally. Because of that, and the dependency checks in CD pipelines, CD pipelines could be blocked for days while dependent teams worked out their code issues.
I'm curious to hear more about the management changes at Walmart and how this impacted the progress made towards continuous delivery. I have not met a senior software leader (vp level or above) in the past decade that had any experience with continuous delivery, so I can see how a new leader might approach these delivery processes with skepticism. At the same time, many leaders tend to be pretty conservative and avoid wholesale changes which could negatively impact productivity. Did this new leader see efficiency problems with continuous delivery processes? Or was it just a case that these processes were unfamiliar and they were uncomfortable supporting them? My experience is that every new CxO wants to make their new company look like their last company, so you have to be really careful picking these leaders.
To me, this is the most fascinating aspect of the whole thing. I hope this becomes a great book soon.
By design, SAFe cannot support continuous delivery. Why? The backlog is a function of PI planning, and PI planning classically happens 4 times a year. Cripples learning and discovery with telemetry. Call it legacy+, but it ain't agile. I bet Boeing wishes SpaceX was using SAFe so they could both compete on the same cadence 😆
I would like to see a video about V-Modell and CI CD compatibility, I need some arguments to convince companies in Germany
Isn't the V model just waterfall? I don't see how it could be compatible - waterfall pretty much cannot do 'continuous' anything - it's big design up front, then build something nobody wanted, then deploy it all at once
@@StevenBorrie V Model is an evolution from waterfall, adding corresponding testing for every case, it is use a lot in car industry and aerospace (I'm not a fan but it is what it is) Audi combines the methodology with CI CD to create new models, they use other variation tho, V &V
perfect description of my current situation :)
It would be good to see a QA focused video 😊 let's talk about automation testing
Try some of these www.youtube.com/@ContinuousDelivery/search?query=Quality
In particular this one "The Role of QA in SW Dev" ua-cam.com/video/XhFVtuNDAoM/v-deo.htmlsi=3jx5xgqUnF0DmAAt
Shouldn’t the Continous Delivery circle also include production monitoring?
Yes, I think it should, but I usually assume it as part of the "Production Phase" rather than calling it out explicitly, because it is at the same kind of level as "Infrastructure as Code" pretty much essential, but a technical detail.
@@ContinuousDelivery I agree that it is not part of the deployment pipeline, but it is dangerous if developers only focus on their deployment wheel which is spinning in one direction - towards the customer. As I see it, the flow of information FROM the customer is equally important. We can’t just care about our clean code, we need to care about our customers needs as well. How do they use our product? Which features do they don’t use? Which features do they want the most? Which bugs bother them the most? Which bugs are not actually affecting any customers? If we think that we ”fixed” a bug - can we verify that it actually doesn’t exist in production anymore?
Continuous delivery needs to be combined with continous feedback - outside the CI.
Goody, goody!
Great case story and very well presented.
How could one truely apply the CD principles in a safety-relevant industry such as railway systems where standards such as CENELEC EN 5012x prescribe waterfall processes? There are agile methods applied in these development projects, but they do not lead to CD.
It is certainly true that most regulatory regimes were created assuming a waterfall approach, but almost none of them rule out alternatives. My experience has largely been in highly regulated industries including finance, transport, telecoms and medical. I would argue that regulation is less of a barrier and more an imperative for CD. I argues that t is not really possible to be properly regulatory compliant without the rigour and traceability of CD. I have a blog post on this topic here www.davefarley.net/?p=285
that describes what I mean in more detail. This is certainly applicable to the rail industry, but it is a difficult process to re-assess the regulation in the context of CD. Fundamentally though CD is the safer approach, making controlled changes in smaller, safer steps works better than the alternatives.
@@davefarley77 Thanks for the quick response. I will study your blog post and hopefully find leads how to stepwise move to CD in our environment, i.e. our customer (a national rail company) accepts and receives a new release of the operations control software every two years.
fourth!
19 comments.
coming up next, how the nazis achieved TRUE agility.