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
In this episode, we explore what is design, and why you should be deliberate about helping teams, and organizations invest in the design of their products and services.
Every product is designed. Design is an integral part of the product development process. Your customers perceive it when they interact with your product, so the question is: how deliberate are you at creating the experience your customers have when they interact with your product and/or service?
Read more to learn what were the key takeaways from this episode, while you listen to the show.
Critical design questions your team should be asking
Maarten Dalmijn joins us on this special episode on the role of the Product Owner to talk about how Product Owners can adapt to the increasing demands placed upon them. It could be working with more teams, or supporting the development of multiple products, the PO role (when successfully executed) will eventually expand to cover more aspects and support more teams.
The struggling and un-happy Product Owner
As Product Owners take on the responsibility to work with more teams, it is easy to feel overwhelmed and overworked. That will likely lead to an un-happy PO, which will, in turn, have a big impact on the teams and their performance.
In this segment, we talk about why PO’s end up taking on too much work and discuss some of the tools we can apply to help scale the Product Owner role. We talk about Sprint Goals (an often forgotten aspect of Scrum), and other techniques that Maarten learned in his career that helped him scale up his role and impact.
In this segment, we refer to a blog post on setting Sprint Goals and the Coach Your Product Owner e-course and the modules on Sprint Goals and Scaling up the PO role. The modules are:
Coach Your PO v2.0 – Module 04 – How to scale up the Product Owner role to serve multiple teams; and
Coach Your PO v1.0 – Module 08 – How to define the perfect Sprint Goal – and why that matters!
The Coach Your PO course (v1.0 and v2.0) is available here: bit.ly/coachyourpo.
Collaboration with the Scrum Master
The Product Owner does not need to work alone when scaling their role to a few more teams or products. We discuss the importance of creating a collaborative relationship with the Scrum Master and how Scrum Masters can help Product Owners.
Maarten is a Product Manager and Scrum practitioner who believes in ‘less, but better’. By blending the world of Product Management and Scrum, Maarten helps teams beat the Feature Factory and uncover better ways of delivering value together.
He has over 10 years of experience building products and helped rebuild products as well as Agile Transformations as a leader and participant.
He says: “Product management is about getting the right things done. It is easy to come up with a list of things to add to make something better. It is much harder to decide which things to leave out to make something better.”
Marcus wrote a blog post about predicting progress in ‘well-defined’ projects. He used a simple example where uncertainty was very limited. You can read the details in the blog post. However, even when uncertainty about the work was low, the predictions he was able to do (and he collects quite a few metrics in that story), was limited.
In this episode, we explore the limits to prediction, and how that affects how we should look at prediction in our own software projects.
Embracing uncertainty and what that means in practice for software projects
Transformation is a big word. What does it mean in practice, and what can we learn from Jeff’s and Amer’s stories to help us in our own roles as Scrum Masters, Agile Coaches and Change Agents? We deep dive into a real story that started small, and slow, but achieved great changes that both teams and their organization benefited from.
The Foundation Team – Small Changes for Big Impact
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.
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. 
Maarten is a Product Manager and Scrum practitioner who believes in ‘less, but better’. By blending the world of Product Management and Scrum, Maarten helps teams beat the Feature Factory and uncover better ways of delivering value together.