Age-of-Product.com’s parent company — Berlin Product People GmbH — offers Scrum training classes authorized by Scrum.org, Liberating Structures workshops, and hybrid training of Professional Scrum and Liberating Structures. The training classes are offered both in English and German.
Check out the upcoming timetable of training classes, workshops, meetups, and other events below and join your peers.
Join us for another exciting LS Scrum workshop on September 7th, 2019, in Berlin. Following up on our first workshop, We will continue exploring LS microstructures, weave them into strings and apply those to Scrum’s soft underbelly — the product side, or figuring out what is worth building. Please note that participants should already understand Scrum as well as product management in general. Furthermore, first experiences with Liberating Structures, e.g. from a Meetup, would be desirable. The workshop language is English.
The LS Scrum training class will take place at the Alte Kantine Wedding on Saturday, September 7th, 2019, from 9:00 am to 5:30 pm.
Why running a Liberating Structures immersive workshop? Since the beginning of 2019, the Hands-on Agile meetup in Berlin has been exploring how to apply Liberating Structures to Scrum. Beyond the basics, we have addressed the Sprint Retrospective, the Sprint Planning, the Product Backlog as well as the Daily Scrum.
While the initial meetups went smoothly, the last two meetups felt rushed given that we usually have about two hours. Also, the changing composition of the meetup attendees has become more challenging; less than 10 percent of the approximately 150 participants so far have attended meetups.
So, I thought it might be a worthwhile experiment to aggregate the previous meetups into a one-day immersive workshop on Liberating Structures for Scrum, built around climate change and MegaBrain.io, a struggling startup with little runway left and in desperate need of two successful Sprints. We ran that workshop last week, and this is what we learned.
Update: Join us for the follow-up workshop on September 7th, 2019, in Berlin.
I recently started aggregating my notes, links, and references related to agile leadership to understand better what it — in the context of an agile transition — may look like. In the end, becoming agile is not the goal of a transition; surviving as an organization is. Hence I appreciate whatever appeals to business leaders and their motivation to delve into agile ideas, frameworks, or practices.
Let’s examine some favorite ideas and concepts around agile leadership. (Please bear with me that the following text is rather bullet-point heavy to concentrate its information.)
Scrum has proven time and again to be the most popular framework for software development. Given that software is eating the world, a seasoned Scrum Master is nowadays in high demand. And that demand causes the market-entry of new professionals from other project management branches, probably believing that reading one or two Scrum books will be sufficient. Which makes any Scrum Master interview a challenging task.
If you are looking to fill a position for a Scrum Master (or agile coach) in your organization, you may find the following 38+9 interview questions useful to identify the right candidate. They are derived from my thirteen years of practical experience with XP as well as Scrum, serving both as product owner and Scrum Master as well as interviewing dozens of Scrum Master candidates on behalf of my clients.
So far, this Scrum Master interview guide has been downloaded more than 15,000 times.
Scrum Master Problem Dealing: We all know it; changing the way we work is extremely difficult. It requires us to find novel solutions to wicked challenges, to deal with cultural baggage (‘the way we do things here’) and to bring along the people needed to make a change successful. And yet, this difficult challenge is a core responsibility of Scrum Masters: How can your organization work effectively with Scrum if it is not considering the entire system?
But how do Scrum Masters and Agile Coaches go about this? What strategies do they use to change the system? Who are their most important allies? And what else can we learn from them?
We teamed up with The Liberators to identify what works in the field. We gathered both quantitative as well as qualitative data from a survey completed by over 200 participants.
The Scrum Guide Reordered is based on about 90 percent of the text of the 2017 Scrum Guide, extending its original structure by adding additional categories. For example, you will find all quotes that can be attributed to the role of the Scrum Master in one place. While the Scrum Guide is mainly focused on the three roles, five events, and three artifacts, I aggregated quotes on specific topics as well, for example, on self-organization, finance or technical debt.
The Scrum Guide–Reordered allows you to get a first understanding of Scrum-related questions quickly. For example, it is good at relating a specific topis — say “stakeholder” — with Scrum first principles such as Scrum Values, or empiricism.
Back in 2017, we started the Scrum Master Salary Report 2017—the first industry report that covered in depth the educational background, working experience, industries, and organizational details of the companies Scrum Masters or agile coaches work for. For its 2019 edition—the Scrum Master Trends Report 2019—, we partnered with Scrum.org—the leading Scrum training and certification institution founded by Scrum co-founder Ken Schwaber—to improve the underlying data set.
Learn more about the state of the industry and download for free the Scrum Master Trends Report 2019.
Agile failure seems to be increasingly more prominent nowadays despite all the efforts undertaken by numerous organization embarking on their journeys to become agile.
The funny thing is: Who would disagree that the four core principles of the Agile Manifesto —
— are derived from applying common sense to a challenging problem? Moreover, the application of those principles might be suited to fix numerous organizational dysfunctions and reduce an error-prone and complex social setting to maybe just a complicated one?
If technical debt is the plague of our industry, why isn’t the Scrum Guide addressing the question of who is responsibly dealing with it? To make things worse, if the Product Owner’s responsibility is to maximize the value customers derive from the Development Team’s work, and the Development Team’s responsibility is to deliver a product Increment (at least) at the end of the sprint adhering to the definition of “Done,” aren’t those two responsibilities possibly causing a conflict of interest?
This post analyzes the situation by going back to first principles, as laid out in the Scrum Guide to answer a simple question: Who is responsible for keeping technical debt at bay in a Scrum Team?
Scrum is a practical framework to build products, provided you identify in advance what to build. But even after a successful product discovery phase, you may struggle to make the right thing in the right way if your product backlog is not up to the job. Garbage in, garbage out – as the saying goes. The following article points at 28 of the most common product backlog anti-patterns – including the product backlog refinement process – that limit your Scrum team’s success.
This second publication in the Hands-on Agile Fieldnotes series provides 42+5 questions and answers for the Scrum Product Owner interview.
Co-authored with Andreea Tomoiaga, 42+5 Scrum Product Owner Interview Questions to Avoid Hiring Agile Imposters represents the most important learnings of our more than 20 years combined hands-on experience with Kanban, Scrum, XP, and several product discovery frameworks. We have worked as Scrum Product Owners, Scrum Masters, agile coaches, and developers in agile teams and organizations of all sizes and levels of maturity.
We have each participated in interviewing dozens of Scrum Product Owner candidates on behalf of our clients or employers. The questions and answers herein are what we have learned.
Suitable agile metrics reflect either a team’s progress in becoming agile or your organization’s progress in becoming a learning organization.
At the team level, qualitative agile metrics typically work better than quantitative metrics. At the organizational level, this is reversed: quantitative agile metrics provide better insights than qualitative ones.
Food for Agile Thought’s issue #201—shared with 22,612 peers—delves into software nature, we correct some popular misconceptions about Scrum, and we revisit the idea that innovation always includes failure, and that teams should experience it safely.
We also address the conceptual difference of product management for machine learning compared to ‘normal’ product management; we embrace the importance of disrupting ourselves, and we appreciate the Product Backlog ordering quadrant.
Lastly, we learn how to help teams that do not want to be coached.
Did you miss last week’s Food for Agile Thought’s issue #200?
Food for Agile Thought’s issue #200—shared with 22,519 peers—delves into fixed agile, we learn about how large organizations assess a Scrum Master’s qualification, and why ‘agile transformation’ is not ideal as a story to tell.
We also ask whether all of your organization’s members can answer the “what is your product” question consistently, we gain a better understanding how uncertainty will influence product discovery and delivery, respectively, and brush up our understanding of effective Product Backlog refinement techniques.
Lastly, we like to thank Basecamp for providing another free webbook on software project management Basecamp-style. (#NoAgile, #NoScrum, #NoWaterfall, #NoPostits, #NoSprints, #NoStandups — just saying.)
Did you miss last week’s Food for Agile Thought’s issue #199?
Food for Agile Thought’s issue #199—shared with 22,476 peers—analyzes the Boeing 737 MAX debacle from a software quality perspective; we delve into fixing Scrum by starting with proper working agreements, and we listen to a software architect who believes that his role is compatible with the Manifesto.
We also reflect on the “go wide, narrow, go wide, narrow” rhythm of Design Thinking, we build apps without coding, and we ask: should prioritization and the product roadmap be a job of the product team?
Lastly, we finish with a more technical, yet fascinating topic: mob programming patterns!
Did you miss last week’s Food for Agile Thought’s issue #198?
