TL;DR: Webinar Agile Maturity and Agility Assessment
Is agile maturity a fad or a trend? How can an organization make an informed decision on what level of agility might become achievable before starting a transition?
Our second webinar addressed the question of agile maturity and detailed the survey results on what indicates an agile organization. Moreover, we introduced the ‘Agility Assessment Framework’ open source project which aims to provide agile practitioners with the tools needed to answer these questions.
🗞 Do you want to get this article in your inbox in the future? You can sign up here for our weekly ‘Food of Agile Thought newsletter’ and join 29k other subscribers.
Update 2018-08-20: The Replay of the Webinar Agile Maturity and Agility Assessment Is Available
The video of the webinar is available now:
Note: If the browser will not video automatically, click here to watch the replay of the webinar agile maturity and agility assessment directly on Youtube.
Update 2018-04-25: The Slide Deck of Webinar Agile Maturity and Agility Assessment Is Available
The slide deck of the webinar is available:
If the slide deck will not work within this browser window, please click here to browse the slide deck of the webinar agile maturity and agility assessment directly on Slideshare. There, you will also be able to download a PDF of the slide deck.
I will make both the screencast as well the transcript of the webinar available at a later stage.
Cannot see the subscription form?
Please click here
✋ Do Not Miss Out: Join the 3,250-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
📖 Webinar Agile Maturity — Related Articles
How to Measure Agility of Organizations and Teams—The Results of the Agile Maturity Survey
Agile Audit: How Is Your Agile Transition Progressing?
Transcript Webinar Agile Maturity and Agility Assessment
Welcome to the second Hands-on Agile webinar on Agile Maturity and the Agility Assessment Framework. So, before Zoom crashed, we were talking about my motivation to dig deeper into this topic.
I'm seriously tired of listening to people telling me, "Agile doesn't work here. We tried, and we failed," for whatever reason. "It's a hoax. It's a fad. Why would I do this?" I believe that this has a lot to do with the agile Industrial consulting complex because agile has become such a tremendously lucrative business. I've been tracking the number of Scrum Alliance, the certified scrum trainers, and the number of Scrum Alliance members. If you do the math, being a certified Scrum trainer should net you via certification workshops perhaps about half a million dollars a year. We have people like the good people from SAFe® who sell some kind of package agile very successfully.
So, it's a lucrative business. The first thing you learn in a consulting firm is that when you start selling something to your customer, you sell something that you already have worked out from your drawer. So, basically, you like patterns, frameworks, methodologies--even better because you can pull out the checklist, and you know exactly how much you can charge the client, and how this is all going down. I believe this is the wrong approach. We need to figure out for every organization what might work in the long run, where the company might get to. One size fits all doesn't work.
Let's start at the beginning. Why do organizations want to become agile? I don't know who of you have read Jeff Sutherland's theory of doing twice the work in half the time, which I believe is still a very problematic title for the whole thing. It results in answers from the C-level when you ask them why they want to become agile that they want to be more efficient. They want to have more bang for the buck. They want to deliver more and faster at a better level of predictability.
The issue I have with that is you want to become an agile organization because you want to learn. Ideally, you want to learn faster than your competitors, right? You want to provide autonomy, mastery, and purpose to the people that are working for you because this is not just an advantage in the world of challenges. It's also a necessity because scaling agile only works if you de-scale the organization. You need to make it flatter. You need to cut out a part of the hierarchy. You need to delegate the power to make decisions to the people who are closest to the problems to solve, right? So it's all about risk mitigation on the one side, but also on the other side about improving the return on investment. Becoming a learning organization can be a very lucrative business. Think of Amazon, or Semco, or all the other companies that come to mind.
So, but what we're still stuck with to an astonishingly level, from my perspective, is what I would like to refer to it as 21st century Taylorism. It is the application of scientific management rules from over 100 years ago, created by Mr. Taylor, and to a certain extent also by Mr. Henry Ford, which resulted in functional silos and projects and budgets and initiatives and all these things we have to deal with all the time, mainly in larger companies. And it's not just limited to large corporations, in my experience. Even if you work in a fast-growing startup, it doesn't mean that it preserves the original culture of being lean, and mean, and fast.
The faster you grow, the higher the pressure gets to hire people with experience, and this usually means that you import this corporate culture into your fast-growing startup by hiring lots of people with a background in consultancies or large corporations. It's not stopping there.
So, becoming agile, when we have a look at the typical journey that the organization is taking, there's certainly no shortage of agile practices in whatever way. We all know this nice graphic by Lynn's sketching of about 40-something agile practices. I'm familiar with some of them, including XSCALE or Large-Scale Scrum. That's what I'm practicing at the moment. And of course, I'm also experienced in Scrum, Kanban.
Agility is branching out into the business, which I believe is an excellent thing. If you are interested in learning more about business agility, I recommend the Business Agility Network. It's a great thing from Evan Leybourn. You will find links to that in the show notes. And we have mentioned before the approach of package agile - of which SAFe® is most popular. I don't know what you have already had to look at the recent 'State of Agile' survey from VersionOne. Supposedly, at least among the people that participated in that survey, almost 30% use SAFe®. I doubt that SAFe® is anything but Agile. Instead of de-scaling the organization, they put even more processes and roles into it.
More familiar to every one of us is probably the agile onion, which nicely explains to a lot of people, why doing agile instead of being agile is so simple. If you start with process and tools and put some practices on top of that, it doesn't mean you're becoming agile. That having a whiteboard on the wall and having standups doesn't mean that you're agile. This takes significantly more.
There are a lot of tests out there already mainly addressing the team level. So for example, a rather well-known is Henry Kniberg's Scrum test. It's a simple test I also like to run with new teams. If you'll do this in regular occasions, or a few weeks from time to time, and you check back, and everything is getting greener the further to the right you move, your team is actually on the right track. But, again, this is mainly at the team level.
So, among the more elaborate models is the Agile Fluency Project by James Shore, Diana Larsen, which is, again, focusing on the team, not the organization, but it nicely covers the development of the team and the various stages of that.
They also have the Agile Fluency Team diagnostic tool, which is interesting. I just participated in a facilitator workshop on that, and I tried, I ran it with my current teams, and it's fascinating. Once again, it's something that you want to do on a regular cadence, for example. However, it's not suited, it's not intended as well, to figure out, to understand the status quo of an existing organization and figure out where that organization might go. But it's significantly more interesting than other approaches.
So, when we have a look at the path of an organization to become a learning organization, an agile organization, there are typically a lot of nagging questions at any given moment. The most interesting one, is agile a destination or a journey? Agile maturity sounds like a destination, which is the reason I'm not fond of it. It somehow means that you achieve a certain level, and then you're good to go. On the contrary, I believe it is a journey, and it needs to be carefully tailored to each organization. Are we on the right route? Are we taking a detour, or are we ending up in some dead-end? Or where are we? It's tricky to understand, particularly if you have an organization with 500 or more people.
It's you can quickly check this - whether it is 50 or 100 people startup, but beyond 500 people, it's getting very, very tricky. How do we know we're making progress? What metrics shall you track? What is it? Is it velocity? Certainly not. Again, you need to find your North Star on your own. And I believe this can be a different exercise for each organization.
Finally, what will the return on investment be? I mean, we talk about investing a significant amount of money into changing an organization. And this is what it is--this is change. We're not just talking about maybe hiring some coaches, but we also have to consider that we need to make significant investments to make this work. It's starting with the office. You can't get agile, I believe, in an open space with cubicles. It simply doesn't work this way.
You also have to address the fear that a lot of people have. You'll notice the typical approach will be to say, "Okay, you have job security but no role security." No role security, however, means that you have to train people and give them time to pick up the new role and understand how this works. This is all a significant investment, and the question always is, okay, how much are we supposed to invest, and what is the return on investment? It's every organization that is trying to become an agile organization supposed to become a holacracy or something like that? Preferably I don't think so. Maybe, a happy agile island in the engineering organization is a good goal. Who would deny that?
So these are all the questions that we have to take into consideration before we can start making any predictions or statements. So what do you do if you're not quite sure whether you have all the information, whether you understand the question in its completeness? You would write a survey. So this is what I did at the end of last year, so around November. And I was asking four questions: What factors contribute to your team's growing maturity? What maturity do you see at the team level? What factors contribute to becoming an agile or a learning organization? What maturity levels do you notice at an organizational level?
Now, the trickiest thing is for open questions, which makes creating a kind of taxonomy a stressful job. So, I went through all the answers of these 86 people. And it turned out that we can cluster the indicators into three main buckets. So that's people in communication, organizational excellence, as well as technical excellence. Let me walk you through the indicators that we were able to identify. So self-organization, empower teams. People want to make decisions, and they accept accountability. Focus on the outcome instead of outputs. Respecting Scrum values, so commitment, focus, openness, respect, trust, and the safety to raise and discuss issues was a primary concern and also a significant indicator for most people.
The teams can handle their problems. People don't want to have scrum moms or scrum master that do everything. So the scrum master that is acting like a drill sergeant is not the preferred role, right? Supporting each other, holding each other accountable, pointing out that people understand agile as a team sport. It's not something that the individual can work with.
Okay. Accountability, for example, people want to choose their tools and devises. This will have another way of formulating it at a later-on and technical excellence that people want to pick their tech stack, for example. A typical answer is I cannot accept accountability for something if I'm forced to use a certain kind of technology. Let me choose my tools, and we're good to go.
People want to have short feedback loops, so user test shouldn't be something that is limited to the UX department. The engineers want to talk to users too. So the classical approach to customer development is very, very important. People want to have meaningful retrospectives, building on psychological safety that they can address the issues that are problematic to them.
Continuous team coaching: People want to spend time on becoming better at what they do. And this means if you have more than one team, which you have to invest time into things like chapters and guilds and tribes that you need to think about how to build a sort of in-house academy to share the knowledge that everyone is gaining on a daily basis. It's expected that stakeholders live up to their responsibilities and that hands-on experience is valued over credentialism. So people are not interested in seeing other people waving around their certificates. It's significantly more important to the people that someone has hands-on experience, that simply he or she has been through these specific scenarios before and knows how to deal with them.
Competence: An indicator for an agile organization is to shape people. So you're good at one thing, really good at one thing, but you're also okay at a lot of other things, again, which is demanding that you keep on learning inside the teams and inside the organization. It also requires that you actively share knowledge. So it's about continuous knowledge. It's also about that you're no longer incentivizing as an organization the withholding of knowledge.
People want to see that people who are contributing by sharing knowledge are rewarded, not the other way around. It's also obvious that people want to have a budget to attend conferences, to meet new people, meet with peers, and learn from other people. There's no necessity to reinvent the wheel over and over again. I think it's also the reason that, for example, that the international Hands-on Agile Slack community is so successful, because you can ask questions, and you get decent answers in a short period by knowledgeable people.
So mastery team building, cross-functional teams, people want to be accountable for what they deliver, and that requires that you not just only be allowed to pick your tools but also that you have all the necessary skills within your team that you can deliver end to end stable, long-living teams. The idea of moving around full-time employees between projects is a crazy one. There's a reason why professional military people are so focused on keeping the team together, because otherwise how can you achieve this level of understanding of the skills of other people? Anyway, I think you know what I mean.
Okay, support by an experienced Scrum master, yes, but not in the form of a drill sergeant. It's more about having a mentor and having a coach or someone you can talk to in certain situations and coach how we can solve the problem.
Purpose: Purpose is strongly built around inclusion. It starts with product discovery, creating product roadmaps, and release planning. I guess most of us are working in the software field. So the idea that stakeholders throw requirement documents over the fence at night, and then the engineers start to code them, and it's completely outdated. My experience, the sooner you involve the engineers, the better. I've had great success with letting the engineers run the user interviews, much more successful than any form of other communication or spreading of knowledge.
Communication and control, trust, and respect--we're all on the same team, right? We want to be honest, and we appreciate the candid feedback, so no situations where someone is rightfully saying, asking, "Why didn't you tell me that?" If you're safe to communicate this, you can address issues that are troublesome to everyone.
Conflict resolution: People agree the Intel/Amazon's 'disagree but commit' approach doesn't mean there's the absence of conflict or communication or discussion, let me put it this way. But in the end, everyone wants the team to pull as a team and no tyranny of compromise. I have to check that. It's referring to, okay; we stick with our values. We're not pussyfooting around. This is what we do, no compromise on our values. And if one of our values is that we deliver a decent code quality, we're not making any compromise on that.
Non-violent communication, this is obvious from my perspective. How can you create a surrounding where people feel safe to address critical issues and give candid feedback if the level and the way of communication is not nonviolent? Collaboration: Zero tolerance for political games. So everyone in the community of product builders is so fed up with this that I believe it's one of the most important issues any leadership of an up and coming agile organization needs to address. So no scripted collaboration.
People are also tired of these values being printed on posters that are then put on the walls. Culture and values are what's happening when you're not looking. No incentives to withhold knowledge--that's another. So this whole political game, "I'm not telling you what I know, so you will fail," is not acceptable. We're all working as a team. We want to provide value to our customers, and that's our organization. No finger-pointing, no blame game. It doesn't help. If there's a problem, solve it, but don't start the witch hunt for one who can be held or can be blamed for the whole issue.
Interestingly, people want a culture that embraces and celebrates failure. I found this interesting. I'm not sure the celebrate failure part means. Probably it's just giving away a T-shirt to the one guy who managed to break the pipeline. Another interesting point was curiosity as the norm. So, again, it's more like this child-like approach to learning, going full in, being curious, and not afraid to leave your comfort zone. Figure out what is working for your organization, and don't be a dogmatist, sticking to some kind of whatever holy book.
Transparency: People want information and data at all levels. And they want to end this habit of getting information or employing information brokers somewhere in the management. This is a pain to most people. Leadership should focus on innovation, quality, and business value, and it needs to support the agile way of working fully.
And at the same time, people would appreciate if agile could make it into the heart of the organization if everyone is aware, okay, we need to change the way we're working. It's no longer working this way. And of course, they expect the roles, principles, and processes are respected. So I think the most prominent victim we face most of the time is the product owner role in Scrum that's so easy demoted and thus made less and less effective.
It is expected, that managers become servant leaders. So, switching a position from someone who knows how to solve every problem to someone who's supporting the team that's actually solving the problem. People expect that and trust that the team will enjoy the benefit of the doubt, that they will deliver on what they want to deliver. They also expect that tools and facilities are provided that are required to become agile.
So do not ask me to write a status report and then put it in the mail. If you want to know what's going on, dear manager, we have a standard of about 11:15 every day, and you're invited to join. Okay? And we have lots of whiteboards, and we explain everything to you. Just come down to our place, where we create value.
As far as organizational design is concerned, most headed entity have functional silos, of course. People also want to see redundant middle management layers removed. And of course, commodity control is an issue. I mean, how are you supposed to become agile if you do not trust in the team that is closest to the problem to find a fix for the problem?
Also, people point at human resources, that new human resources need to align with the new requirements of self-organizing teams. For example, titles are an issue in certain organizations. If you provide someone with the title senior developer and that person is acting out like a senior developer or a tech lead within the Scrum team, there are indeed issues. And ideally, organizations are supposed to morph into a team of teams.
People want to have clear objectives. So, a shared vision among all actors, a clear strategy, clear priorities. This is, again, the application of Alice in Wonderland, right, if you don't know where you're going, and we'll get you there. This is value-focused. Yes, we're not acting in a vacuum. We're supposed to provide value to our customers and thus creating value for our organization too. And highly demand is to switch from project budgets to product teams, so a different way of actually organizing everything.
Engineering level: we have the usual suspects, a built-in quality, code reviews, tester and development, XP, pair programming. The world is for a lot of people a standard indicator of being an agile organization as well as a regular cadence of releases, and that the organization managed to find suitable metrics, so, for example, cycle time or lead time, or something like that.
So based on these indicators, I started earlier this year to run a few workshops in Berlin and asked the local agile community, "Okay, what can we do about it? Can we probably come up with an agility assessment framework that we could open source and that provides everyone with a toolset to start assessing an organization for its potential to become an agile, a learning organization?"
So the question was: "Is agile a fit for every organization?" And if not, or probably only to a certain extent would it be great to know this in advance? At the time also InfoQ updated the cultural methods graph for Q1 in 2018. And as you can see, a lot of agile practices like Scrum are meanwhile arriving at the late majority. If you move further to the left, we come across the more exciting things like cross-functional teams, or behavior-driven design, or teams have a selection, full-stack product teams, business agility, and still at the innovators level of something like at holacracy or no estimates, and other interesting things that most of us are probably keen to experience and try themselves.
So the idea behind the agility assessment framework is that you're a coach and you're parachuting into an organization because the leadership of the organization wants to become. The organization wants to become an agile organization and wants to know where to go and what to do. And it's not just willing to place a contract with one of the numerous consultants, for example, ask McKenzie to introduce something of this level.
So the question is: Can the organization make an informed decision on becoming agile in advance? This leads to the question of whether we can answer certain questions. For example, is the organization able and willing to change? Where can the organization probably go? And where does the organization need to change? The agility assessment framework needs to figure out how this works.
Here are a few of the peoples. ThoughtWorks in Berlin is currently sponsoring everything. So they provide us with a room where we can meet and work. And, my God, you won't believe this took two days of creating something. So, creating a product with a committee of highly driven individuals that are used to do this on their own is quite challenging, I can tell you. But we're getting forward.
The idea is that we have a multiple-step process that we provide the toolbox that you can use actually to get this thing going. The part I will be taking care of is a set of questionnaires that would allow you at the beginning to get answers to the critical questions that lead to an assessment of the organization, of the status quo where the organization is at the moment, where it could probably go. So, for example, why and who?
Why has the organization decided that they want to become agile? Typical answers are: We want to become more efficient. We want to live more and faster. We want to improve predictability. The better answer to the question, I believe, still is "we want to outperform our competitors by learning faster than they do." And we want to create a great culture, and we want to minimize risk and improve the return on the investment.
If the C-level is not willing to accept an outcome drop for a while, then this is undoubtedly a terrible indicator for the whole transitional process. Another critical question is: "Who's the sponsor of the decisions?" In my experience, if the basis wants to become agile, that is futile. If the leadership wants to become agile but no other part of the organization, this is just going to be some lip service for the next financial report.
What you need to have is the support from the leadership on the one side, making clear that the organization has to change. Moreover, that agile needs to become part of the DNA of the organization, as well as support from the bases, the people in the trenches who actually do the work; otherwise, it's not working.
Organizational background. Of course, you need to understand what kind of organization you're talking about, size, history. What culture is this? Is this a sales-driven organization or is it a nonprofit? The market is critical. Are we talking about legacy products here? Is this is a dying cash cow? Are we talking about a situation where the organization is more or less facing an innovator's dilemma? What is the lifecycle state of the cash cows? Is it close to sunset? And is the primary product burdened with technical debt and no longer solvable? What customer base does the company have? Is it B2B, B2C? Is it mainly selling to public organizations? Does the law regulate the business?
It's something entirely different as far as a transition is concerned if you compare B2C companies selling whatever directly to customers on the one side and a pharmaceutical company trying to develop new drugs. In my experience, a critical issue but an often underestimated aspect is budgeting. How is currently product development in this organization funded? Is it the traditional approach of setting up temporary projects or initiatives, or has the organization already set up some form of long-living product teams that are tasked to solve certain problems?
The next question addresses the kind of approval process? Are they using some stage-gate model or metered funding, as it is called today, which I believe is a euphemism? Or is the product team funded upfront for the rest of the year, and we expect that we make a return investment on that?
The next question would be who controls the budget for the transition? Is it the CEO, the CTO, the CFO? And how large is the budget? How is the collaboration of the product team's developing within the organization, for example, with the business stakeholders, with customers, with the management, with the leadership? How are they doing this in practice? How do they manage to get from a vision via strategy, and a portfolio, and a product roadmap basically to delivering a product? How is that working?
Again, is someone throwing requirements over the fence at night and expect the product team on the receiving end to deliver? I don't know. This is most critical because you will get a lot of different insights from various perspectives. What's the nature of teams in that organization? For example, what is the outsourcing level? Are there internal team members? Is everyone on a team a freelancer or a contractor? Or is the development outsourced to, for example, new-shoring or offshoring facilities?
What about team longevity? Are people being shifted around? Are people working on several projects at the same time? Is there some management entity that can pull people out of a product team at any given time and put them somewhere else? Do we have siloed teams, for example, or cross-functional teams? For example, a lot of large organizations still run a QA, a silo where there's a certain handover. Of course, you can't afford to have a QA silo that is testing something if you want to deploy at will and have a fully integrated deploy pipeline; it simply doesn't work, but teams co-locate it.
Another big question, are the team members scattered all over the landscape, and if they're not co-located, are they meeting at regular intervals? Nothing is more productive than basically meeting face to face. And if that's not possible, you can immediately say, "Okay, this is a negative indicator." How is the organization hiring new people? It starts with the diversity level, and it's not ending with the idea of do we practice something like peer recruiting of team members? Does the team have the final say who's working on the team and who's at the later stage also contributing to the commitment the team probably makes? Or are people, new team members imposed on the team by HR or some leadership? Are teams selecting themselves or someone putting them together?
And we already were talking about what it's HR pursuing old-school career development. But what about autonomy master purpose? Or is it all about titles and certificates? What's the fluctuation rate among teams or within the organizations? Just to put this in perspective, Semco has a decade-long fluctuation rate that is about 2% a year, not a month--a year. If you consider the turnover rate in a startup in Berlin, I can say it's certainly around 30% to 40% at least, maybe 50% a year. It's something completely different.
What about freelancers and employees relations? Is there any form of differentiation between the two? Or does it principally not matter how the remuneration is handled technically? What's the ratio between freelancers and employees? For example, a lot of organizations, large organizations during the times of the 1990s valued outsourcing of IT or software development to focus on core competencies. And now they understand that if the organization wants to survive, they need to start developing software desperately. And they find it very difficult to hire talented engineers because they have no culture in this.
Team management: How are teams managed? Is the organization somehow incentivizing individuals over teams which is critical? How are they handling failure? Is it more kind of thank you that you figured out this problem in our delivery pipeline? Yes, it took the application offline for three minutes, but that was helpful. Now we fix it, and we like to celebrate that by giving you a T-shirt, something like that.
Incentive schemes is another interesting issue, particularly in sales-driven organizations. Is the organization planning to change incentive schemes? Because sometimes the "What's in for me?" syndrome is opposing the interest the organization should have in other issues. Personal incentives are often colliding with the purpose of a team, creating personal agendas and local optima. So that's an issue.
The agile workspace. I believe one factor that is really undervalued for the productivity of any team, do we actually have a space available where a team can work in an agile manner? I don't know about you, but in my case, we have a high need for whiteboards. We need them because we like to visualize extensively for stakeholder communication almost everything. It's not just the sprint boards; we also visualize the roadmap and the backlog, technical debt, et cetera, pp. So if you don't have walls where you can put up whiteboards, it's tricky.
You have to find team spaces where the whole team sits together. Do you have small ad hoc collaboration spaces where you can sit down and work with a few people? And do you have some areas where people really can shut off for three hours and focus on getting something right that requires their concentration? And also is there a budget for working offsite to get out of the comfort zone of the usual office? So a lot of issues.
To the technology, promise a cloud. Can I bring my tech? Can I choose my own tools and software? People will not be happy if they are forced to work on a Microsoft tech stack, right? This is really not common today. And to kind of expect to hire top-notch engineers, if you force them to work on some kind of agile apps or something like that.
What's certainly also important is to understand to what level an organization, even if it's formally not yet agile or has never kicked off that, to what level agile practices are already used inside the organization. Probably, they do so in a guerrilla mode or in a, "I don't care what the company says; we just do it this way" mode. So ask, "What are you using?" So you start, and you ask design thinking, Scrum, Kanban, XP, whatever comes to your mind.
At the moment, I'm working on getting these questionnaires right. And one thing that's driving me to ask, and I would like to hear your suggestions concerning that, how can this be delivered to the rest of the community? It's certainly easy to have a Google Form, but Google Forms are probably not the best delivery model for questionnaires, for example, because there are companies around where they, the firewalls block Google apps because Google is evil. So how shall this be done? I don't know. Maybe there's a way to use GitHub to provide the sources for that. You can download and then upload it to Typeform. So we're still working on that.
Okay. Thanks a lot for spending an hour of your life with this, and I hope I was able to provide you with some ideas hon ow things might work out for you in your career and what the next transition may be about. And if you like to participate, please drop me an email, and we can catch up later. I will share the recording with you, and I'm also planning to have it transcribed, so there will also be the text. Okay. Thanks a lot. And hopefully, you're interested in joining me in two weeks for a product backlog anti-patterns or on Friday for the XSCALE product management pattern language. Thanks a lot.
📅 Scrum Training Classes, Workshops, and Events
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.