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.
Continue reading BONUS: Leena N interview – Continuous Delivery for Scrum teams, Part 7
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.
Continue reading BONUS: Wouter Lagerweij interview – Continuous Delivery for Scrum teams, Part 5
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.
Continue reading BONUS: Chris O’Dell interview – Continuous Delivery for Scrum teams, Part 5
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.
Continue reading BONUS: Manuel Pais interview – Continuous Delivery for Scrum teams, Part 4
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.
Continue reading BONUS: Morten Herman interview – Continuous Delivery for Scrum teams, Part 3
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.
Continue reading BONUS: Thierry de Pauw interview – Continuous Delivery for Scrum teams, Part 2
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.’
Continue reading BONUS: Dave Farley interview – Continuous Delivery for Scrum teams, Part 1
No matter how many courses you attend, there are things that, as a Scrum Masters, you only really learn the important lessons on the field. Doing the work.
One of the reasons I don’t think certification courses are enough for Scrum Masters that certifications courses very often focus on the rules and regulations of the job, but not on the problems, the hardships and the obstacles we face, day-in, day-out when we try to do a good work as a Scrum Master.
So, what can we do when courses aren’t enough?
Scaling the use of Scrum in any organization is not easy. In this episode, we discuss Izis approach to that challenge from the Scrum Master perspective. Scrum Masters in larger organizations end up having to work with multiple teams. We explore an approach that may help Scrum Masters serve more teams, while amplifying their impact.
About Izis Filipaldi
Izis’ mission is to help people to improve their knowledge and professional value inside organizations, applying the agile way of working. She has been working as an Agile Coach for more than 7 years, helping people to deliver products, developing an environment free of judgments where they can fail fast and learn faster. Continuous improvement of: people knowledge, product delivery, and work environment, are her 3 main focus on work. And she loves what she does!
You can link with Izis Filipaldi on LinkedIn and connect with Izis Filipaldi on Twitter.
In this episode, we explore the role that checklists can have in helping teams improve their process and their performance without adding more processes.
It is a normal tendency to “add more processes” to fix a problem a team is experiencing. In this episode, we challenge that view. Checklists, we argue, are a simple, effective tool that helps you reach a similar goal, but does not require the process to grow, and become bloated.
There are several types of items we can add to a checklist. In this segment, we discuss 2 common types of checklists, and how they can help teams. We start by discussing the “process checklists”, which may include important tips on how to execute a certain process.
The key thing to remember is that checklists don’t replace processes, but are rather a set of reminders, or items that help teams execute a process once they’ve already read and understood the process.
The second type of checklists we discuss are those that summarize a series of requirements or pre-conditions that a team needs to follow-up on. This may include quality requirements or certain tasks that need to be completed before a certain work item is considered complete.
Scrum teams have a common set of checklists that they use. We discuss the commonly used Definition of Done, and also talk about the importance of having a Definition of Ready, and how that may help teams get started on the right foot when a new Sprint is about to kick-off.
Additionally, we talk about a pre-release checklist. With a pre-release checklist, teams are able to keep a memory of what they’ve learned from the past about meeting the release requirements, and can continuously improve that critical aspect of any team’s process.
In this segment, we also tackle the usual objections that people given when asked to consider the use of checklists. Checklists may be seen as “more bureaucracy”, but instead, they are there to help teams summarize a process that already exists, provides transparency about the process execution, and ultimately it should be a time saver for the team.
How about you? How have you used Checklists in your work? Share your experience in the comments below.
About Diana Getman
Diana Getman has more than 25 years of experience as a project manager leading cross-functional teams, in both startup and non-profit organizations. Diana has held the roles of Scrum Master, Product Owner, and Agile Coach and is the current President at Ascendle, a custom software development firm in Portsmouth, NH.
You can link with Diana Getman on LinkedIn, or visit Ascendle’s blog for more on checklists.
