From her early start with Extreme Programming to learning how to integrate testing with Continous Delivery, we explore Leena’s story and describe some of the most important lessons she collected about adopting CD/CI.
Read on to learn what were Leena’s main lessons, as well as the main challenges teams face when adopting CD/CI.
Wouter started his Continuous Delivery journey as an Extreme Programmer in his first years of engineering experience. He shares the story of how, as a team, they sat together with the operations department to learn how they developed their software. Thanks to that, they radically changed their build system to export the kind of packages that operations needed. A brilliant story that also illustrates the adage: “Your first customer is the next step in the process!”
Read more to learn why testing is such a key skill and technical area when adopting Continuous Delivery.
Chris started her Continuous Delivery in a small agency, nurturing a build server that nobody cared for. That gave her an insight that is not very common: taking care of the build server was a very practical way to help and care for the team’s success. It was a practical tool that the team needed, but no one was looking after. It was a concrete way to help people.
Read more to find out how trust plays a key role in Continuous Delivery adoption, and to read Chris’ recipe to get your team started with CD.
How do we get started with Continuous Delivery? Manuel suggests that we run a Value Stream Mapping session with all the teams involved in the release process to learn about the “current state” of the release process.
We also review the most common challenges and blocks for teams that are starting to adopt Continuous Delivery.
Read on to learn about the different motivations businesses have to adopt Continuous Delivery, and Manuel’s 3 steps from bi-weekly release to Continuous Delivery.
Morten’s adoption story starts with a team at eBay Denmark. The team had started working in a more continuous mode, but there was a lot of “release friction” as Morten calls it. You are probably familiar with that friction: it takes a long time to release; the site needed to be “closed” for every release; the team would need to come in at night during the weekend, etc.
That’s the reality for many teams. No surprise they prefer to release less often. In this segment, we explore that story, and also the steps the team took to go from “high friction” to “no friction”.
Read more to find out how Dev and Ops are different and why that matters when adopting Continous Delivery.
When Thierry got started, the team had troubles with version control, so he helped the team “commit to trunk”, and after that, it was much easier to adopt continuous integration. The build server quickly evolved into a continuous build pipeline. From there it was a small step to continuous delivery.
Although not all stories are this easy for teams adopting CD, this story provides a striking example of how things that are “hard” for some teams, just become the “natural way” of working for others. What’s preventing your team from working this way?
Read more to find what was Thierry’s most painful lesson about Continous Delivery adoption as well as all the resources he recommends for those wanting to dive deeper into the topic.
We talk about testing strategy; business benefits of Continuous Delivery; main challenges when adopting Continuous Delivery and resources to help you and your team get started.
Dave got started with Continuous Delivery in a project that sounds pretty much like any large project that is struggling. There were 200 people working on the project, the tests were written after the code, which inevitably led to a nightmare of brittle tests, high coupling between test code and implementation code.
Dave got interested in Extreme Programming and things started changing.
Read on to get access to all the resources Dave lists in the podcast.’
When organizations start with Agile, they typically focus on the work that needs to be done at the team level. In many organizations we have “water-scrum-fall”, a little bit of Scrum squeezed inside two big buns of a plain waterfall.
The reason for that is that organizations don’t change as a whole. Typically Agile adoption starts in Engineering/R&D and slowly spreads throughout the organization. At some point, it bumps against the slow moving, but very powerful finance department. Where are all the financial decisions are made, including how to fund projects, and where Procurement has a key role. How do we change Procurement (buying software development) to fit Agile organizations?
That’s the topic we explore with Mirko Kleiner, a pioneer in the Lean-Agile Procurement movement.
How Lean-Agile Procurement got started
Read on for the detailed show notes and all the links.
When Agile broken into the scene, it was mostly about the techniques to develop releases of the product quickly. However, that was a time when products were released only a few times a year at best. Today products evolve continuously and that changes how product Owners and Product Managers need to interact with the teams. In this episode, we explore some of the key lessons Jeff has learned working with product organizations all over the world. In short: Product Managers also need to adapt to Agile, it’s not just the teams!
Continuous product development is different from what we used to know as product development
Read on for the detailed show notes and all the links.