Gerry came across Agile while working as a project manager in a construction company. Motivated by his drive to provide a great service to his customers, he started to study how to make his own business more adaptable and Agile.
Working with new technologies, he started to improve certain aspects of his business. However, he quickly realized that the size of the projects and demands of the customers were making what once was an “easy” to manage service, into a complicated service with many moving parts.
The use of computers helped manage that complexity, but also brought even more complexity. This was when Gerry discovered Agile and what it could bring to a non-IT business.
Setting up teams to work collaboratively is one of the challenges that organizations go through when adopting Agile. The functional team setup (all DBAs, all testers, all windows devs together, etc.) is not acceptable for teams that want to quickly develop and deliver products and services to the market. But neither is it possible to have all possible skills (sometimes 10’s of skills) in one team because organizations simply don’t have that many people with certain skills.
In this episode, we talk about the possible team topologies, and how each of those affects our ability to deliver in different organizations.
How we set up teams directly affects the quality of the software teams deliver
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.’