For some, it might seem hard enough to release once per month (12 times a year). However, this particular company is releasing every week of the year (52) and some extra releases when necessary, taking them up to 68 unique releases in a year.
They can do this (mostly) transparently to the end customers, but also release major features that their organization uses in promoting the product.
Listen in to learn how Charles Oppermann has helped his organization reach that level of frequent deliveries, even with multiple hard dependencies and a team that can go up to 60+ people involved in the development and release process.
About Charles Oppermann
Charles Oppermann is a 30-year veteran of the software industry. He prides himself on shipping high-quality software that helps humanity; from the JAWS screen reader and making the internet accessible to people with disabilities while at Microsoft, and for the past decade; protecting people from online threats at Malwarebytes.
Just like all of us, Gene and Jeff’s organization moved to fully remote work at the start of 2020. That presented multiple challenges, not the least of which the fact that teams were interacting less with each other because of the necessary overhead that remote work represents for each team.
The remote work reality became an even bigger issue when it came to addressing organization-wide issues. In the past, Gene and Jeff have helped facilitate an internal Unconference at Meltwater. However, with remote work being the norm, hosting the unconference became an extra challenge.
Gene and Jeff were not discouraged, however, and started working on a format that would fit the online/remote reality!
Hosting a remote Unconference: a hands-on how-to tutorial
During the first remote unconference, they learned many lessons which they share in this episode, from the “how-to” for MIRO boards, to the surprises related to helping the teams follow instructions. This massive online event had specific challenges they had to learn to deal with and share their lessons with us.
The most important lesson: iterate quickly, learn even faster!
Perhaps one of the most important lessons for Gene and Jeff was to “try” the format in smaller groups before going full-blown global with their ideas. For that, they decided to quickly test different tools in smaller events with teams and learned what worked and didn’t.
Gene Connolly is a Principal Software Developer at Meltwater. He has dedicated his career to improving the quality of life of legacy software systems during their golden years and making the most complex problems he can find slightly less complex.
Jeff is an Agile Coach who considers the discovery of Agile and Lean to be one of the most defining moments of his life and considers helping others to improve their working life not to simply be a job, but a social responsibility.
He is the author of actionable agile tools, which you can get on Amazon and directly from the author at bit.ly/aatbook
As an Agile Coach, he has worked with driving Agile transformations in organizations both small and large.
For Christmas week 2020, we have a special treat for you. Yves Hanoulle and I interview great Agilists and Scrum Masters that you will probably not hear from in your local Agile conference.
These are people that are really pushing the state of the practice, and we want to bring their forward-looking, and hopeful ideas to you in our Christmas Special Week for 2020.
When Yogini took on her Scrum Master journey, she noticed that there was more friction in the team. Curious, she looked into the reasons for that friction. After all, they had just left Waterfall-like ways of working behind. What was causing that friction? Was it Agile? As she looked more into it, she found that Agile had something to do with it, but the real reason for the friction between team members was that they were, for the first time, honestly discussing the problems they were facing. They were no longer apathetic, and that was visible in the level of friction between them.
Another side effect of Agile adoption, Yogini noticed, was that the team was much more productive, “they did more in a month, than I thought was possible in six!” Yogini shares.
A key lesson for Agile teams: speak freely
This story led to a key lesson for Yogini. Agile teams improve and transform their ways of working when they speak freely and aren’t afraid to tackle tough conversations.
When teams finally take on the difficult topics that are impeding their progress, they often fail to reach consensus. However, as Yogini reminds us, that’s no reason not to act. “Buy-in does not imply consensus!” She reminds us.
Retrospectives as the engine of growth and learning
Retrospectives are the aspect of Agile methodologies that Yogini wants to highlight as key for teams and individuals working in an Agile environment.
In the spirit of self-improvement, Yogini mentions and recommends the book Atomic Habits by James Clear. She reminds us that part of the Scrum Master’s responsibility is to improve herself, otherwise, improvements elsewhere are less likely to happen.
The Christmas Agile Message from Yogini Moodley
Yogini asks us, in this festive season, to take time to reflect, and practice being mindful of what we do, say, and feel. The challenge she leaves us with: “think about the habits you have at the moment, and what you’d like to leave behind, in 2020”
Merry Christmas friends!
Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today!The Tips from the Trenches – Scrum Master edition audiobook includes hours of audio interviews with SM’s that have decades of experiences: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!
About Yogini Moodley
Yogini is a certified Scrum Master and agile practitioner, with extensive experience in the financial services industry, in roles that encompass both business and technology. She is passionate about enriching the lives of people and nurturing and growing teams to deliver value to their customers, and an active member of the agile community locally and globally.
“Most purpose statements are dry and uninspiring”, that’s how this episode starts. But Stephen goes deeper and explains why that may be the case. We dive into what are the missing aspects in most purpose statements and share some examples of how he’s been able to help organizations go beyond those dry and uninspiring purpose statements.
The three types of purposes we need to take into account
Jeff is also the author of Actionable Agile tools (available on Amazon, and direct from the author at bit.ly/aatbook).
Why does Management resist Agile change?
This is the first question of the episode and one that Scott and Jeff have worked together on for years. Scott shares how his past as a developer has helped him understand the role of management in an Agile organization.
We also talk about how to understand the reaction of managers when employees come to them with gripes, or ideas for changes to implement. We tend to think that when managers don’t do what we ask, they haven’t listened to us. Is that really so?
Every 4 months, about 8 teams comprised of University students, other students, and partner-company employees start working on a new product idea at the Digital Product School (DPS).
These teams become their own mini-startups, and work to develop, and sell their products in a 3-month accelerated program. They experience hands-on what it is to work in a start-up and to go from a fuzzy idea (the problem space) to a product they can sell in a very short period of time.
This learn-by-doing program helps companies educate their employees in rapid product development methods, and helps students get hands-on experience with product development in a very short period of time.
The most common problems teams face in DPS
The teams that join and complete DPS usually have the same problems all other teams face, but because of the accelerated time-frame, and because the DPS team has seen more than 10 batches already, the problems are obvious! And we can learn a lot from those problems when it comes to the more normal product development we participate in.
The first challenge teams face is that they have a hard time locking down the problem they want to solve. As it happens, they want to solve too many problems, which is a common affliction of many teams and leads to confused and confusing products.
The DPS team expected that it would be hard to convince developers to work with users and do user research. However, it turns out developers actually embrace that work, and the biggest problem is getting the Product Managers (PMs) to make decisions. PMs tend to expect that the “process” will ensure they have a good outcome, and that leads to having a hard time making decisions.
In this segment, we talk about how to help PMs make decisions and the transformation that happens when PMs are faced with the need to make decisions.
The biggest problem in the Developer-PM collaboration
In such an accelerated program (3 months from idea to product), it is natural that the pressure is high at some point. PM’s work needs to include facilitating and motivating the teamwork. Why are we doing certain decisions? What’s the goal of a certain user test? And many more questions come up during the work.
This brings one of the biggest problems in the Developer-PM collaboration: the motivation of the team when under pressure. In this segment, we also talk about the most common anti-patterns developers and PMs fall into when under pressure. There are also some great insights for Scrum Masters about team building and coping with pressure!
Enabling good Developer-PM collaboration
One of the usual sticking points in the Developer-PM collaboration is the fact that these people speak different languages. Many Scrum Masters also experience that when they see PMs and developers fight about estimations, for example.
At DPS, special attention is put into helping PMs understand what developers do and vice-versa. From explaining and using tools that developers use, to helping developers understand Story Maps and other PM tools, the way the DPS team helps developers and PM’s collaborate is especially about helping each other and learning each other’s job and responsibilities.
Why Product Manager and not Product Owner?
At DPS, the team decided early on to call the role of the product person the Product Manager, and not the Product Owner. Why did they do that?
In this segment, we explore a question that most companies adopting Scrum will need to struggle with: what to call the product roles.
The DPS team shares how the idea of “product” is owned by the whole team, and that the product manager role is much more than looking at the backlog or defining priorities, it’s about being responsible for user experience, business, and technology!
This emphasizes the idea of the DPS program: product development is a team sport!
Resources for rapid product development
At the end of the episode, we talk about what resources DPS suggests teams to study, and we list the following books:
DPS is an accelerated product development program in Munich that helps students from University and employees in partner companies experience hands-on what it is to work in a startup. In 3 months they go from idea to a product, and some ideas are brought back to the companies for further development.
About the DPS team
Michi / Michael Stockerl is director of DPS and has worked as a software engineer with several teams in different setups. Before that, he gathered experience in smaller Startups in Munich and Germany’s biggest Q&A platform.
Steffen is a trained journalist, who slipped into product management through Content Management and e-commerce. He worked with Amazon and Haymarket media, did several hundred user interviews and tests, witnessed dozens of teams at DPS, a Digital Product School of the Technical University of Munich in Germany.
Bela is a Software Engineer at DPS. She helps teams with various software and hardware engineering tasks. She was previously also a participant at DPS.
In this episode, we interview David Horowitz who’s the CEO of Retrium, a company that builds tools to help you facilitate remote retrospectives. The links to Retrium’s Retrospectives Academy below are affiliate links, if you prefer to follow a link that takes you to Retrium’s site, but does not give anything back to the podcast, you can. Just follow this link: Retrium.com. On the other hand, if you want to help us grow this podcast, you can follow the links below or this link to Retrium’s Retrospective’s Academy.
As David started his Scrum Master journey, he was faced with a big challenge. He struggled with remote retrospectives. No wonder, he ended up creating and being the CEO for a remote retrospectives company. He experienced the pain first-hand!
As he got started experimenting, he found the Lean Coffee format to be effective (see our Lean Coffee episodes). However, he found that even when the format worked well, there was something else missing.
The collaboration that can be had when the team is in the same room simply isn’t the same when we are all remote, and sometimes even without video!
Jeff is the author of Actionable Agile tools (available on Amazon, and direct from the author at bit.ly/aatbook).
Collaboration is one of the key aspects of focus for Scrum Masters. We are, and should always be on the lookout for way to improve collaboration in our teams, and across teams and departments. In this episode, we dive into a specific Actionable Agile Tool that aims to boost collaboration: The Internal Unconference. Gene and Jeff share their own experience organizing Internal Unconferences, and why this even may be exactly what you need to improve collaboration in your organization.
Discovering how to improve collaboration across departments
From that survey, the early results are conclusive, one of the biggest challenges you are facing right now is to help your teams coordinate their work, and collaborate effectively after transitioning to #Remote work.
So, to help you adapt to this new #Remote work reality, we collected the following strategies and tools for helping #Remote teams coordinate and collaborate effectively.
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 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.”