Easy Agile Podcast Ep.34 Henrik Kniberg on Team Productivity, Code Quality, and the Future of Software Engineering
TL;DR
Henrik Kniberg, the agile coach behind Spotify's model, discusses how AI is fundamentally transforming software development. Key takeaways: AI tools like Cursor and Claude are enabling 10x productivity gains; teams should give developers access to paid AI tools and encourage experimentation; coding will largely disappear as a manual task within 3–4 years; teams will shrink to 2 people plus AI; sprints will become obsolete in favour of continuous delivery; product owners can now write code via AI, creating pull requests instead of user stories; the key is treating AI like a brilliant intern – when it fails, the problem is usually your prompt or code structure, not the AI. Bottom line: Learn to use AI now, or risk being left behind in a rapidly changing landscape.
Introduction
Artificial intelligence is fundamentally reshaping how software teams work, collaborate, and deliver value. But with this transformation comes questions: How do we maintain team morale when people fear being replaced? What happens to code quality when AI writes most of the code? Do traditional agile practices like sprints still make sense?
In this episode, I sit down with Henrik Kniberg to tackle these questions head-on. Henrik is uniquely positioned to guide us through this transition – he's the agile coach and entrepreneur who pioneered the famous Spotify model and helped transform how Lego approached agile development. Now, as co-founder of Abundly AI, he's at the forefront of helping teams integrate AI into their product development workflows.
This conversation goes deep into the practical realities of AI-powered development: from maintaining code review processes when productivity increases 10x, to ethical considerations around AI usage, to what cross-functional teams will look like in just a few years. Henrik doesn't just theorise – he shares real examples from his own team, where their CEO (a non-coder) regularly submits pull requests, and where features that once took a sprint can now be built during a 7-minute subway ride.
Whether you're a developer wondering if AI will replace you, a product owner looking to leverage these tools, or a leader trying to navigate this transformation, this episode offers concrete, actionable insights for thriving in the AI era.
About Our Guest
Henrik Kniberg is an agile coach, author, and entrepreneur whose work has shaped how thousands of organisations approach software development. He's best known for creating the Spotify model – the squad-based organisational structure that revolutionised how large tech companies scale agile practices. His work at Spotify and later at Lego helped demonstrate how agile methodologies could work at enterprise scale whilst maintaining team autonomy and innovation.
Henrik's educational videos have become legendary in the agile community. His "Agile Product Ownership in a Nutshell" video, created over a decade ago, remains one of the most-watched and shared resources for understanding product ownership, with millions of views. His ability to distil complex concepts into simple, visual explanations has made him one of the most accessible voices in agile education.
More recently, Henrik has turned his attention to the intersection of AI and product development. As co-founder of Abundly AI, he's moved from teaching about agile transformation to leading AI transformation – helping companies and teams understand how to effectively integrate generative AI tools into their development workflows. His approach combines his deep understanding of team dynamics and agile principles with hands-on experience using cutting-edge AI tools like Claude, Cursor, and GitHub Copilot.
Henrik codes daily using AI and has been doing so for over two and a half years, giving him practical, lived experience with these tools that goes beyond theoretical understanding. He creates educational content about AI, trains teams on effective AI usage, and consults with organisations navigating their own AI transformations. His perspective is particularly valuable because he views AI through the lens of organisational change management – recognising that successful AI adoption isn't just about the technology, it's about people, culture, and process.
Based in Stockholm, Sweden, Henrik continues to push the boundaries of what's possible when human creativity and AI capabilities combine, whilst maintaining a pragmatic, human-centred approach to technological change.
Transcript
Note: This transcript has been lightly edited for clarity and readability.
Maintaining Team Morale and Motivation in the AI Era
Tenille Hoppo: Hi there, team, and welcome to this new episode of the Easy Agile Podcast. My name is Tenille Hoppo, and I'm feeling really quite lucky to have an opportunity to chat today with our guest, Henrik Kniberg.
Henrik is an agile coach, author, and entrepreneur known for pioneering agile practices at companies like Spotify and Lego, and more recently for his thought leadership in applying AI to product development. Henrik co-founded Abundly AI, and when he isn't making excellent videos to help us all understand AI, he is focused on the practical application of generative AI in product development and training teams to use these technologies effectively.
Drawing on his extensive experience in agile methodologies and team coaching, Henrik seems the perfect person to learn from when thinking about the intersection of AI, product development, and effective team dynamics. So a very warm welcome to you, Henrik.
Henrik Kniberg: Thank you very much. It's good to be here.
Tenille: I think most people would agree that motivated people do better work. So I'd like to start today by touching on the very human element of this discussion and helping people maintain momentum and motivation when they may be feeling some concern or uncertainty about the upheaval that AI might represent for them in their role.
What would you suggest that leaders do to encourage the use of AI in ways that increase team morale and creativity rather than risking people feeling quite concerned or even potentially replaced?
Henrik: There are kind of two sides to the coin. There's one side that says, "Oh, AI is gonna take my job, and I'm gonna get fired." And the other side says, "Oh, AI is going to give me superpowers and give us all superpowers, and thereby give us better job security than we had before."
I think it's important to press on the second point from a leader's perspective. Pitch it as this is a tool, and we are entering a world where this tool is a crucial tool to understand how to use – in a similar way that everyone uses the Internet. We consider it obvious that you need to know how to use the Internet. If you don't know how to use the Internet, it's going to be hard.
"I encourage people to experiment, give them access to the tools to do so, and encourage sharing. And don't start firing people because they get productive."
I also find that people tend to get a little bit less scared once they learn to use it. It becomes less scary. It's like if you're worried there's a monster under your bed, maybe look under your bed and turn on the lights. Maybe there wasn't a monster there, or maybe it was there but it was kind of cute and just wanted a hug.
Creating a Culture of Safe Experimentation
Tenille: I've read that you encourage experimentation with AI through learning – I agree it's the best way to learn. What would you encourage leaders and team leaders to do to create a strong culture where teams feel safe to experiment?
Henrik: There are some things. One is pretty basic: just give people access to good AI tools. And that's quite hard in some large organisations because there are all kinds of resistance – compliance issues, data security issues. Are we allowed to use ChatGPT or Claude? Where is our data going? There are all these scary things that make companies either hesitate or outright try to stop people.
Start at that hygiene level. Address those impediments and solve them. When the Internet came, it was really scary to connect your computer to the Internet. But now we all do it, and you kind of have to, or you don't get any work done. We're at this similar moment now.
"Ironically, when companies are too strict about restricting people, then what people tend to do is just use shadow AI – they use it on their own in private or in secret, and then you have no control at all."
Start there. Once people have access to really good AI tools, then it's just a matter of encouraging and creating forums. Encourage people to experiment, create knowledge-sharing forums, share your own experiments. Try to role-model this yourself. Say, "I tried using AI for these different things, and here's what I learned." Also provide paths for support, like training courses.
The Right Mindset for Working with AI
Tenille: What would you encourage in team members as far as their mindset or skills go? Certainly a nature of curiosity and a willingness to learn and experiment. Is there anything beyond that that you think would be really key?
Henrik: It is a bit of a weird technology that's never really existed before. We're used to humans and code. Humans are intelligent and kind of unpredictable. We hallucinate sometimes, but we can do amazing things. Code is dumb – it executes exactly what you told it to do, and it does so every time exactly the same way. But it can't reason, it can't think.
Now we have AI and AI agents which are somewhere in the middle. They're not quite as predictable as code, but they're a lot more predictable than humans typically. They're a lot smarter than code, but maybe not quite as smart as humans – except for some tasks when they're a million times smarter than humans. So it's weird.
You need a kind of humble attitude where you come at it with a mindset of curiosity. Part of it is also to realise that a lot of the limitation is in you as a user. If you try to use AI for coding and it wrote something that didn't work, it's probably not the model itself. It's probably your skills or lack of skills because you have to learn how to use these tools. You need to have this attitude of "Oh, it failed. What can I do differently next time?" until you really learn how to use it.
"There can be some aspect of pride with developers. Like, 'I've been coding for 30 years. Of course this machine can't code better than me.' But if you think of it like 'I want this thing to be good, I want to bring out the best in this tool' – not because it's going to replace me, but because it's going to save me a tonne of time by doing all the boring parts of the coding so I can do the more interesting parts – that kind of mindset really helps."
Maintaining Code Quality and Shared Understanding
Tenille: Our team at Easy Agile is taking our steps and trying to figure out how AI is gonna work best for us. I put the question out to some of our teams, and there were various questions around people taking their first steps in using AI as a co-pilot and producing code. There are question marks around consistency of code, maintaining code quality and clean architecture, and even things like maintaining that shared understanding of the code base. What advice do you have for people in that situation?
Henrik: My first piece of advice when it comes to coding – and this is something I do every day with AI, I've been doing for about two and a half years now – is that the models now, especially Claude, have gotten to the level where it's basically never the AI's fault anymore. If it does anything wrong, it's on you.
You need to think about: okay, am I using the wrong tool maybe? Or am I not using the tool correctly?
For example, the current market leader in terms of productivity tools with AI is Cursor. There are other tools that are getting close like GitHub Copilot, but Cursor is way ahead of anything else I've seen. With Cursor, it basically digs through your code base and looks for what it needs.
But if it fails to find what it needs, you need to think about why. It probably failed for the same reason a human might have failed. Maybe your code structure was very unstructured. Maybe you need to explain to the AI what the high-level structure of your code is.
"Think of it kind of like a really smart intern who just joined your team. They're brilliant at coding, but now they got confused about something, and it's probably your code – something in it that made it confused. And now you need to clarify that."
There are ways to do that. In Cursor, for example, you can create something called cursor rules, which are like standing documents that describe certain aspects of your system. In my team, we're always tweaking those rules. Whenever we find that the AI model did something wrong, we're always analysing why. Usually it's our prompt – I just phrased it badly – or I just need to add a cursor rule, or I need to break the problem down a little bit.
It's exactly the same thing as if you go to a team and give them this massive user story that includes all these assumptions – they'll probably get some things wrong. But if you take that big problem and sit down together and analyse it and split it into smaller steps where each step is verifiable and testable, now your team can do really good work. It's exactly the same thing with AI.
Addressing the Code Review Bottleneck
Tenille: One of our senior developers found that he was outputting code at a much greater volume and faster speed, but the handbrake he found was actually their code review processes. They were keeping the same processes they had previously, and that was a bit of a handbrake for them. What kind of advice would you have there?
Henrik: This reminds me of the general issue with any kind of productivity improvement. If you have a value stream, a process where you do different parts – you do some development, some testing, you have some design – whenever you take one part of the process and make it super optimised, the bottleneck moves to somewhere else.
If testing is no longer the bottleneck, maybe coding is. And when coding is instant, then maybe customer feedback – or lack of customer feedback – is the bottleneck. The bottleneck just keeps moving. In that particular case, the bottleneck became code review. So I would just start optimising that. That's not an AI problem. It's a process problem.
Look at it: what exactly are we trying to do when we review? Maybe we could think about changing the way we review things. For example, does all code need to be reviewed? Would it be enough that the human who wrote it and the AI, together with the human, agree that this is fine? Or maybe depending on the criticality of that change, in some cases you might just let it pass or use AI to help in the reviewing process also.
"I think there's value in code review in terms of knowledge sharing in a large organisation. But maybe the review doesn't necessarily need to be a blocking process either. It could be something you go back and look at – don't let it stop you from shipping, but maybe go back once per week and say, 'Let's look at some highlights of some changes we've made.'"
We produce 10 times more code than in the past, so reviewing every line is not feasible. But maybe we can at least identify which code is most interesting to look at.
Ethical Considerations: Balancing Innovation with Responsibility
Tenille: Agile emphasises people over process and delivering value to customers. Now with AI in the mix, there's potential for raising some ethical considerations. I'm interested in your thoughts on how teams should approach these ethical considerations that come along with AI – things like balancing rapid experimentation against concerns around bias, potential data privacy concerns.
Henrik: I would treat each ethical question on its own merits. Let me give you an example. When you use AI – let's say facial recognition technology that can process and recognise faces a lot better than any human – I kind of put that in the bucket of: any tool that is really useful can also be used for bad things. A hammer, fire, electricity.
That doesn't have so much to do with the tool itself. It has much more to do with the rules and regulations and processes around the tool. I can't really separate AI in that sense. Treat it like any other system. Whenever you install a camera somewhere, with or without AI, that camera is going to see stuff. What are you allowed to do with that information? That's an important question. But I don't think it's different for AI really, in that sense, other than that AI is extremely powerful. So you need to really take that seriously, especially when it comes to things like autonomous weapons and the risk of fraud and fake news.
"An important part of it is just to make it part of the agenda. Let's say you're a recruitment company and you're now going to add some AI help in screening. At least raise the question: we could do this. Do we want to do this? What is the responsible way to do it?"
It's not that hard to come up with reasonable guidelines. Obviously, we shouldn't let the AI decide who we're going to hire or not. That's a bad idea. But maybe it can look at the pile of candidates that we plan to reject and identify some that we should take a second look at. There's nothing to lose from that because that AI did some extra research and found that this person who had a pretty weak CV actually has done amazing things before.
We're actually working with a company now where we're helping them build some AI agents. Our AI agents help them classify CVs – not by "should we hire them or not," but more like which region in Sweden is this, which type of job are we talking about here. Just classifying to make it more likely that this job application reaches the right person. That's work that humans did before with pretty bad accuracy.
The conclusion was that AI, despite having biases like we humans do, seemed to have less biases than the human. Mainly things like it's never going to be in a bad mood because it hasn't had its coffee today. It'll process everybody on the same merits.
I think of it like a peer-to-peer thing. Imagine going to a doctor – ideally, I want to have both a human doctor and an AI doctor side by side, just because they both have biases, but now they can complement each other. It's like having a second opinion. If the AI says we should do this and the doctor says, "No, wait a second," or vice versa, having those two different opinions is super useful.
Parallels Between Agile and AI Transformations
Tenille: You're recognised as one of the leading voices in agile software development. I can see, and I'm interested if you do see, some parallels between the agile transformations that you led at Spotify and Lego with the AI transformations that many businesses are looking at now.
Henrik: I agree. I find that when we help companies transition towards becoming AI native, a lot of the thinking is similar to agile. But I think we can generalise that agile transformations are not really very special either – it's organisational change.
There are some patterns involved regardless of whether you're transitioning towards an agile way of working or towards AI. Some general patterns such as: you've got to get buy-in, it's useful to do the change in an incremental way, balance bottom-up with top-down. There are all these techniques that are useful regardless. But as an agilist, if you have some skills and competence in leading and supporting a change process, then that's going to be really useful also when helping companies understand how to use AI.
Tenille: Are you seeing more top-down or bottom-up when it comes to AI transformations?
Henrik: So far it's quite new still. The jury's not in yet. But so far it looks very familiar to me. I'm seeing both. I'm seeing situations where it's pure top-down where managers are like "we got to go full-out AI," and they push it out with mixed results. And sometimes just completely bottom-up, also with mixed results.
Sometimes something can start completely organically and then totally take hold, or it starts organically and then gets squashed because there was no buy-in higher up. I saw all of that with agile as well. My guess is in most cases the most successful will be when you have a bit of both – support and guidance from the top, but maybe driven from the bottom.
"I think the bottom-up is maybe more important than ever because this technology is so weird and so fast-moving. As a leader, you don't really have a chance if you try to control it – you're going to slow things down to an unacceptable level. People will be learning things that you can't keep up with yourself. So it's better to just enable people to experiment a lot, but then of course provide guidance."
AI for Product Owners: From Ideation to Pull Requests
Tenille: You're very well known for your guidance and for your ability to explain quite complex concepts very simply and clearly. I was looking at your video on YouTube today, the Agile Product Ownership in a Nutshell video, which was uploaded about 12 years ago now. Thinking about product owners, there's a big opportunity now with AI for generating ideas, analysing data, and even suggesting new features. What's your advice for product owners and product managers in using AI most effectively?
Henrik: Use it for everything. Overuse it so you can find the limits. The second thing is: make sure you have access to a good AI model. Don't use the free ones. The difference is really large – like 10x, 100x difference – just in paying like $20 per month or something. At the moment, I can particularly strongly recommend Claude. It's in its own category of awesomeness right now. But that of course changes as they leapfrog each other. But mainly: pay up, use a paid model, and then experiment.
For product owners, typical things are what you already mentioned – ideation, creating good backlog items, splitting a story – but also writing code. I would say as a PO, there is this traditional view, for example in Scrum, that POs should not be coding. There's a reason for that: because coding takes time, and then as PO you get stuck in details and you lose the big picture.
Well, that's not true anymore. There are very many things that used to be time-consuming coding that is basically a five-minute job with a good prompt.
"Instead of wasting the team's time by trying to phrase that as a story, just phrase it as a pull request instead and go to the team and demonstrate your running feature."
That happened actually today. Just now, our CEO, who's not a coder, came to me with a pull request. In fact, quite often he just pushes directly to a branch because it's small changes. He wants to add some new visualisation for a graph or something in our platform – typically admin stuff that users won't see, so it's quite harmless if he gets it wrong.
He's vibe coding, just making little changes to the admin, which means he never goes to my team and says, "Hey, can you guys generate this report or this graph for how users use our product?" No, he just puts it in himself if it's simple.
Today we wanted to make a change with how we handle payments for enterprise customers. Getting that wrong is a little more serious, and the change wasn't that hard, but he just didn't feel completely comfortable pushing it himself. So he just made a PR instead, and then we spent 15 minutes reviewing it. I said it was fine, so we pushed it.
It's so refreshing that now anybody can code. You just need to learn the basic prompting and these tools. And then that saves time for the developers to do the more heavyweight coding.
Tenille: It's an interesting world where we can have things set up where anyone could just jump in and with the right guardrails create something. It makes Friday demos quite probably a lot more interesting than maybe they used to be in the past.
Henrik: I would like to challenge any development team to let their stakeholders push code, and then find out whatever's stopping you from doing that and fix that. Then you get to a very interesting space.
Closing the Gap Between Makers and Users
Tenille: A key insight from your work with agile teams in the past has been to really focus on minimising that gap between maker and user. Do you think that AI helps to close that gap, or do you think it potentially risks widening it if teams are focusing too much on AI predictions and stop talking to their customers effectively?
Henrik: I think that of course depends a lot on the team. But from what I've seen so far, it massively reduces the gap. Because if I don't have to spend a week getting a feature to work, I can spend an hour instead. Then I have so much more time to talk to my users and my customers.
If the time to make a clickable prototype or something is a few seconds, then I can do it live in real time with my customers, and we can co-create. There are all these opportunities.
I find that – myself, my teams, and the people I work with – we work a lot more closely with our users and customers because of this fast turnaround time.
"Just yesterday I was teaching a course, and I was going home sitting on the subway. It was a 15-minute subway ride. I finally got a seat, so I had only 7 minutes left. There's this feature that I wanted to build that involved both front-end and back-end and a database schema change. Well, 5 minutes later it was done and I got off the subway and just pushed it. That's crazy."
Of course, our system is set up optimised to enable it to be that fast. And of course not everything will work that well. But every time it does, I've been coding for 30 years, and I feel like I wake up in some weird fantasy every day, wondering, "Can I really be this productive?" I never would have thought that was possible.
Looking Ahead: The Future of Agile Teams
Tenille: I'd like you to put your futurist hat on for a moment. How do you see the future of agile teamwork in, say, 10 to 15 years time? If we would have this conversation again in 2035, given the exponential growth of AI and improvements over the last two to three years, what do you think would be the biggest change for software development teams in how they operate?
Henrik: I can't even imagine 10 years. Even 5 years is just beyond imagination. That's like asking someone in the 1920s to imagine smartphones and the Internet. I think that's the level of change we're looking at.
I would shorten the time a little bit and say maybe 3 or 4 years. My guess there – and I'm already seeing this transfer happen – is that coding will just go away. It just won't be stuff that we humans do because we're too slow and we hallucinate way too much.
But I think engineering and the developer role will still be there, just that we don't type lines of code – in the same way that we no longer make punch cards or we no longer write machine code and poke values into registers using assembly language. That used to be a big part of it, but no longer.
"In the future, as developers, a lot of the work will still be the same. You're still designing stuff, you're thinking about architecture, you're interacting with customers, and you're doing all the other stuff. But typing lines of code is something that we're gonna be telling our kids about, and they're not gonna believe that we used to do that."
The other thing is smaller teams, which I'm already seeing now. I think the idea of a cross-functional team of 5 to 7 people – traditionally that was considered quite necessary in order to have all the different skills needed to deliver a feature in a product. But that's not the case anymore. If you skip ahead 2 or 3 years when this knowledge has spread, I think most teams will be 2 people and an AI, because then you have all the domain knowledge you need, probably.
As a consequence of that, we'll just have more teams. More and smaller teams. Of course, then you need to collaborate between the teams, so cross-team synchronisation is still going to be an issue.
Also, I'm already seeing this now, but this concept of sprints – the whole point is to give a team some peace of mind to build something complex, because typically you would need a week or two to build something complex. But now, when it takes a day and some good prompting to do the same thing that would have taken a whole sprint, then the sprint is a day instead. If the sprint is a day, is there any difference between a sprint planning meeting and a daily standup? Not really.
I think sprints will just kind of shrink into oblivion. What's going to be left instead is something a little bit similar – some kind of synchronisation point or follow-up point. Instead of a sprint where every 2 weeks we sit down and try to make a plan, I think it'll be very much continuous delivery on a day-to-day basis. But then maybe every week or two we take a step back and just reflect a little bit and say, "Okay, what have we been delivering the past couple of weeks? What have we been learning? What's our high-level focus for the next couple of weeks?" A very, very lightweight equivalent of a sprint.
I feel pretty confident about that guess because personally, we are already there with my team, and I think it'll become a bit of a norm.
Final Thoughts: Preparing for the Future
Henrik: No one knows what's gonna happen in the future, and those who say they do are kidding themselves. But there's one fairly safe bet though: no matter what happens in the future with AI, if you understand how to use it, you'll be in a better position to deal with whatever that is. That's why I encourage people to get comfortable with it, get used to using it.
Tenille: I have a teenage daughter who I'm actually trying to encourage to learn how to use AI, because I feel like when I was her age, the Internet was the thing that was sort of coming mainstream. It completely changed the way we live. Everything is online now. And I feel like AI is that piece for her.
Henrik: Isn't it weird that the generation of small children growing up now are going to consider this to be normal and obvious? They'll be the AI natives. They'll be like, "Of course I have my AI agent buddy. There's nothing weird about that at all."
Tenille: I'll still keep being nice to my coffee machine.
Henrik: Yeah, that's good. Just in case, you know.
---
Thank you to Henrik Kniberg for joining us on this episode of the Easy Agile Podcast. To learn more about Henrik's work, visit Abundly AI or check out his educational videos on AI and agile practices.
Subscribe to the Easy Agile Podcast on your favourite platform, and join us for more conversations about agile, product development, and the future of work.
Verwandte Episoden
- Podcast
Einfacher Agile-Podcast Folge 7 Sarah Hajipour, Agile-Coach

„Ich habe mein Gespräch mit Sarah absolut geliebt. Sie hat einige tolle Ratschläge gegeben, die ich kaum erwarten kann, sie in die Praxis umzusetzen!“
Wir haben über die agile Denkweise gesprochen, die nicht nur IT- und Entwicklungsteams betrifft, darüber, wie Teams wie Marketing und Finanzen beginnen, die Methodik zu übernehmen, und über die Vorteile, die sich daraus ergeben.
Anlässlich des Internationalen Frauentags diskutierten wir über die Zukunft von Frauen im agilen Bereich und über Maßnahmen, die wir ergreifen sollten, um uns gegenseitig auf dem Weg zu einem inklusiven und förderlichen Umfeld zu unterstützen.
Abonniere unbedingt, genieße die Folge 🎧
Transkript
Caitlin Mackie:
Hallo zusammen und willkommen zurück zum Easy Agile Podcast für 2021. In jeder Folge sprechen wir mit einigen der interessantesten Menschen aus den Bereichen Technologie, Agilität und führende Unternehmen auf der ganzen Welt, um neue Perspektiven auszutauschen und aus dem Wissensschatz zu lernen, den jeder Gast zu teilen hat. Ich bin Caitlin und ich bin die Graduate Marketing Coordinator bei Easy Agile und Ihr Moderator für diese Episode. Wir freuen uns sehr, zurück zu sein und in dieser Saison einige tolle Gäste zu haben. Zum Auftakt freue ich mich sehr darauf, mit Sarah Hajipour zu sprechen.
Caitlin Mackie:
Sarah hat so viel reiche und vielfältige Erfahrung im agilen Bereich. Sie ist Agile-Coach, Leiterin der Unternehmenstransformation, Projekt- und Programmmanagerin und seit Kurzem Podcast-Moderatorin und Autorin. Sie ist die Alleskönnerin und seit über 10 Jahren im Bereich Business Agility tätig. In dieser Folge sprechen Sarah und ich über die Bedeutung der Zielsetzung und insbesondere der Zielsetzung in unvorhersehbaren Zeiten. Wir unterhalten uns über ihre neuesten Projekte, den Agility-Podcast mit Sarah Hajipour und ihr Buch über agile Fallstudien.
Caitlin Mackie:
Und natürlich gab Sarah angesichts des bevorstehenden Weltfrauentags einige tolle Ratschläge und ihre Gedanken zum weiteren Vorgehen für Frauen im agilen Bereich. Sie hob hervor, wie wichtig es ist, die Hand zu heben und um Hilfe zu bitten, wenn man sie braucht, und dass man sich Eigenschaften zu eigen macht, an die in Führungskräften traditionell nicht immer gedacht wird. Es war eine so nachdenkliche und aufschlussreiche Diskussion. Ich habe viel Wert aus unserem Gespräch gezogen und einige großartige Ratschläge erhalten, und ich freue mich sehr darauf, sie in die Praxis umzusetzen. Ich weiß, dass es denen, die zuhören, genauso gehen wird. Lass uns reinspringen.
Caitlin Mackie:
Sarah, vielen Dank, dass du zu uns gekommen bist und heute etwas Zeit mit mir verbracht hast.
Sarah Hajipour:
Sicher. Danke, dass du mich eingeladen hast.
Caitlin Mackie:
Da ich unser erster Gast in diesem Jahr war, wollte ich Sie nach Ihren Neujahrsvorsätzen fragen. Bist du auf dem richtigen Weg? Glaubst du an sie oder hast du einen anderen Zielsetzungsprozess?
Sarah Hajipour:
Das ist eine großartige Frage, weil wir das mit ein paar Freunden besprochen haben und festgestellt haben, dass der Neujahrsvorsatz immer so etwas wie ein riesiges Ziel sein wird, von dem wir nicht wissen, ob wir es erreichen werden oder nicht. Und als agiler Coach glaube ich an agile Geschäftsagilität und glaube an die Tatsache, dass wir uns kleinere Ziele setzen und sie alle drei Monate, alle sechs Monate überprüfen und schauen, wo wir stehen. Anstatt große Ziele zu verfolgen, von denen wir nicht wissen, was passieren wird, weil es auch in unserem Privatleben immer viele Unsicherheiten gibt, was die Ziele angeht, die wir uns gesetzt haben. Also ja, so sehe ich das. Vierteljährlich, vierteljährlich, persönliche Ziele. Sagen wir das.
Caitlin Mackie:
Ja. Ja. Ja, ich liebe das. Ja, ich denke, wenn uns das letzte Jahr etwas gelehrt hat, sind wir uns wohl alle einig, wie unberechenbar Dinge werden können. Also diese ursprünglichen Ziele.
Sarah Hajipour:
Das ist wahr.
Caitlin Mackie:
Ja. Die ursprünglichen Ziele müssen möglicherweise ein paar Umwege in Anspruch nehmen. Was wäre also Ihr Rat, um in unsicheren Zeiten Karriereziele zu setzen?
Sarah Hajipour:
Das ist eine gute Frage. Für Karriereziele glaube ich, dass es wirklich wichtig ist, dass Sie etwas tun, an dem Sie zumindest interessiert sind. Wenn Sie Ihre Leidenschaft immer noch nicht gefunden haben, ist das in Ordnung, besonders für Menschen wie Berufseinsteiger. Es ist in Ordnung, wenn Sie Ihre Leidenschaft noch nicht gefunden haben, aber Sie können trotzdem einen grundlegenden Karriereweg einschlagen, der mit Dingen beginnt, die Sie gerne tun, die Ihnen Spaß machen und die Sie nebenbei lernen.
Sarah Hajipour:
Ich habe vor ein paar Tagen eine der Modeikonen auf YouTube gehört und der Interviewer fragte sie: „Was war dein Karriereweg? Wie bist du an den Ort gekommen, an dem du jetzt bist?“ Und ich fand toll, was sie allen erzählt hat, den Studenten, und das war: Geh und finde eine Karriere, finde einen Job und lerne. Sie müssen zuerst eine Menge Fähigkeiten erlernen, bevor Sie entscheiden, worin Sie wirklich gut sind. Du entscheidest, du verstehst, was deine Schwächen und deine Stärken sind, oder? Weil nicht alle von uns ständig diese tollen Ideen haben und das ist in Ordnung.
Sarah Hajipour:
Ich bin nicht sehr dafür, dass jeder ein Visionär sein muss und jeder muss große, glänzende Ziele und Ideen haben. Ich denke, es ist völlig in Ordnung, einfach die Art von Job oder den Karriereweg zu finden, mit dem man sich wohl fühlt, und dann manchmal seine Komfortzone zu verlassen und es dann im Laufe der Zeit zu entdecken. Das Leben ist zum Erkunden da, nicht darum, sich ständig an die Ecke zu drängen und sich einfach mit allen anderen zu vergleichen.
Caitlin Mackie:
Ja. Ja, ich liebe das. Das ist ein toller Rat. Sie haben also kürzlich Podcast-Host und Autor zu Ihrem Lebenslauf hinzugefügt. Waren das schon immer deine Karriereziele?
Sarah Hajipour:
Nein, absolut nicht. Nun, ich bin ein bisschen introvertiert. Also quasi vor der Kamera zu sitzen und zu reden und die Leute mich hören zu lassen war immer wie: „Oh mein Gott, ich weiß, ich muss darüber reden, sogar mit meinen Teams und so“, aber ich werde es nur tun, wenn es nötig ist. Was mich zum Podcasting gebracht hat, war, dass ich dachte, es gibt viele Fragen, auf die ich Antworten finde, wenn ich Gespräche und Treffen führe und in verschiedenen Gruppen, Berufsgruppen, denen ich angehöre. Und ich wollte, dass andere Leute diese auch hören. Ich habe mit Leuten gesprochen, die großartige Einblicke haben und schon viel länger in der Karriere sind als ich. Also lerne ich gleichzeitig. Und ich wollte dieses Lernen mit allen anderen teilen. Das ist der Grund, warum ich den Podcast mache.
Caitlin Mackie:
Ja, das ist großartig. Ja, das liebe ich. Ja, ich denke, du hast das vorhin angesprochen, aber ich denke, wenn du im agilen Bereich bist, kann es manchmal eine nette Erinnerung für dich sein, dich ein bisschen zu konzentrieren, aber dann zu reflektieren und zu verstehen, wo du effektiver sein und dich entsprechend anpassen kannst. Ich weiß, dass Sie das bei Ihren Karrierezielen erwähnt haben. Denken Sie, dass diese agilen Prinzipien über den üblichen Anwendungsfall hinaus angewendet werden können?
Sarah Hajipour:
Das tue ich. Ich glaube, dass es sehr intuitiv ist, wie Agile eine sehr intuitive Arbeits- und Denkweise ist. Deshalb wird es jetzt auf andere Branchen ausgedehnt. Sie blieben nicht bei DevOps, IT und Entwicklung. Inzwischen übernehmen viele verschiedene Branchen dies, weil es sich um eine Änderung der Denkweise handelt. Und das nicht nur mit Scrum. Es wird nicht nur Kanban verwendet. Es geht darum zu verstehen, wie man in der Lage ist, über die schnelleren Veränderungen in der Welt nachzudenken und sich an sie anzupassen. Und das gilt auch für unser Privatleben.
Sarah Hajipour:
Ich meine, ich hatte mir Ziele gesetzt, als ich 18 Jahre alt war, ich werde das mit 30 sein, aber sind sie passiert? Nein. In mancher Hinsicht habe ich viel, viel mehr erreicht. Und in einigen Aspekten habe ich einfach mein Ziel geändert. Ich denke, die Veränderungen, die auf der Welt stattfinden, gehen schneller vonstatten und verlangen von uns, dass wir uns ebenfalls ändern. Ja.
Caitlin Mackie:
Ja. Fantastisch. Also, um für deinen Podcast noch ein bisschen zurückzukommen, nur damit unser Publikum zuhört, auf welchen Plattformen können sie auf deinen Podcast zugreifen?
Sarah Hajipour:
Ich bin auf allen wichtigen Plattformen. Ich bin in Apple-Podcasts. Ich bin bei Spotify, ich bin bei Amazon. Die meisten bekannten Podcast-Plattformen.
Caitlin Mackie:
Fantastisch. Und dann noch einmal, für unser Publikum heißt Ihr Podcast Agility-Podcast mit Sarah Hajipour.
Sarah Hajipour:
Das ist richtig. Ja.
Caitlin Mackie:
Fantastisch. Das ist großartig. Was war deiner Meinung nach die wertvollste Lektion, die du bisher aus deinem Podcast gelernt hast? Ist es etwas, das ein Gast geteilt hat, oder etwas, das du unterwegs gelernt hast?
Sarah Hajipour:
Was ich gelernt habe, ich habe viel von den Leuten gelernt, die ich interviewe, weil ich sicherstelle, dass ich mit Leuten spreche, die mehr wissen als ich und mehr in diesem Bereich waren als ich und in verschiedenen Branchen. Das Wichtigste, was ich sagen würde, ist, dass es bei agiler Geschäftsagilität eher um die Denkweise als um die Tools und Prozesse geht. Und die Tatsache, dass sich die Welt insgesamt in Richtung einer menschenorientierteren Arbeitsweise bewegt. Im Grunde genommen sage ich, dass Agile intuitiver ist, als nur ABCD zu folgen. Ja. Das ist der Kern, die Hauptsache, die ich von meinen Interviewpartnern gelernt habe.
Caitlin Mackie:
Ja, unglaublich. Du hast im Moment auch angefangen, ein Buch zu schreiben. Kannst du uns etwas mehr darüber erzählen? Wie hat das Projekt angefangen?
Sarah Hajipour:
Ich liebe dieses Projekt wirklich. In diesem Buch habe ich eigentlich angefangen, das Buch zu schreiben, als das Buch zuerst kam und dann der Podcast. Ich nehme an vielen Meetups teil. Für junge Berufstätige und sogar für Profis, die in dem, was sie tun, sehr gut ausgebildet sind, sind Meetups ein großartiger Ort, um sich zu treffen, Ihr Netzwerk zu erweitern und von Ihren Kollegen zu lernen. Also habe ich an all diesen Veranstaltungen teilgenommen und von Menschen gelernt. Und dann entschied ich, dass ich wirklich Einzelgespräche mit ihnen führen möchte. Und schließlich stellte ich fest, dass viele der agilen Coaches, viele Führungsebenen und viele Berater viel zu teilen haben, aber ich habe keine Plattform gesehen, die das irgendwie vereinheitlicht.
Sarah Hajipour:
Ich sagte: „Okay, welche Erkenntnisse können wir teilen?“ Viele der Fehler sind auf die Meetup-Gruppen zurückzuführen. Die Leute fühlen sich sicher, wenn sie sie teilen, und sie fühlen sich verwundbar. Und ich war in mehreren Meetups, also habe ich sehr ähnliche Geschichten von Leuten gehört, die Fehler, die von einem Coach woanders wiederholt wurden. Also dachte ich, es wäre eine großartige Idee, diese in agilen Fällen zu behandeln. Es wird also Agile Case Studies sein und sie mit allen teilen. Vor allem bei jungen Coaches oder beim Einstieg in das Unternehmen gibt es viele Unbekannte. Ich möchte nicht, dass sie Angst haben. Ich möchte nicht, dass sie denken: „Okay, das ist eine riesige Aufgabe.“ Es wird immer eine Menge Unbekannter geben.
Sarah Hajipour:
Ja, das sehe ich einfach. Ich möchte die Sichtbarkeit vermitteln, dass alle anderen das Gleiche erleben, auch wenn sie 25 Jahre Erfahrung haben, was unglaublich ist, oder?
Caitlin Mackie:
Ja.
Sarah Hajipour:
Und das ist der Grund, warum ich angefangen habe, das Buch zu schreiben. Deshalb interviewe ich agile Coaches und agile Berater, die seit mindestens fünf bis zehn Jahren im Unternehmen sind und agile Transformationsprojekte geleitet haben. Und von da an sagte einer meiner Interviewer einmal: „Du solltest einen Podcast machen. Darüber spreche ich auch gerne.“ Ich sage: „Das ist großartig“ und das war wie in der Woche danach, als wäre ich herumgelaufen und habe nach Tools gesucht, um meinen Podcast zu starten.
Caitlin Mackie:
Oh, unglaublich. Hört sich so gut an. Wie lief der Prozess ab? Wie sind Sie von der Ideenfindung zu dem gekommen, wo Sie jetzt stehen, und schließlich, als Sie sie veröffentlichen?
Sarah Hajipour:
Für den Podcast?
Caitlin Mackie:
Für das Buch.
Sarah Hajipour:
Für das Buch, also gehe ich zu diesen Treffen und höre mir an, was die Trainer und Führungskräfte teilen. Diejenigen, die für mich aufregend sind, sind irgendwie neu für mich, ich werde sie fragen, ich verbinde mich mit ihnen auf LinkedIn und die Leute sind so offen dafür, ihre Erfahrungen mit Ihnen zu teilen. Ich habe noch nie eine Person gesagt, sie solle mir sagen: „Nein, ich möchte nicht darüber sprechen oder so.“ Die Leute wollen teilen. Also gehe ich zu und sage: „Hey, ich habe eine Buchübersicht oder einen Leitfaden. Es ist ein zweiseitiger Text.“ Ich schicke es ihnen und fragte sie, ob sie daran interessiert sind, mit mir darüber zu sprechen, und sie geben mir Bescheid und dann wähle ich einen Zeitpunkt aus.
Sarah Hajipour:
Und die erste Sitzung dauert ungefähr eine halbe Stunde. Es ist eine Art Brainstorming-Sitzung. Was sind die wichtigsten Fälle, von denen sie glauben, dass sie sie teilen möchten? Dann wählen wir einen aus und in der darauffolgenden Sitzung gehen sie den Fall tatsächlich mit mir durch. Ich nehme es auf, entwerfe es und teile es dann auf Google Drive hin und her, bis wir mit dem Ergebnis zufrieden sind.
Caitlin Mackie:
Ja. Fantastisch. Hast du im Moment einen Zeitplan? Wann können wir damit rechnen, ihn lesen zu können?
Sarah Hajipour:
Ich freue mich auf etwa Ende 2021, denn es sind 100 Fälle und ich denke, dass ich die haben werde.
Caitlin Mackie:
Ja. Fantastisch. Es ist so aufregend. Es gibt auch viel, worauf man sich freuen kann.
Sarah Hajipour:
Ich danke dir.
Caitlin Mackie:
Nun, ich wollte auch darauf hinweisen, dass der Internationale Frauentag bevorsteht und Sie seit ein paar Jahren im agilen Bereich tätig sind. Ich nehme an, Sie haben wahrscheinlich einen kleinen Wandel in diesem Bereich erlebt. Gab es irgendwelche entscheidenden Momente, die irgendwie zu dem geführt haben, wo Sie heute sind?
Sarah Hajipour:
Nun, ich denke, dass sich viele Frauen von der agilen Praxis, den verschiedenen agilen Rollen, angezogen fühlen. Und ich habe viel mehr Frauen als Scrum Master, als Product Owner und als agile Manager oder agile Projektmanager gesehen. In diesem Bereich florieren viele verschiedene Rollen. Und ich habe gesehen, dass viele Frauen dazu beigetragen haben. Eines meiner Ziele in meinem Buch und in meinem Podcast ist es, diese Frauen zu finden und mit ihnen zu sprechen, unabhängig davon, wo auf der Welt sie sich befinden. Ja, ich habe einfach das Gefühl, dass Frauen in diesem Bereich in der agilen Denkweise wirklich wachsen können, weil Frauen eher das Element der Zusammenarbeit sind.
Sarah Hajipour:
Ich kann nicht sagen, dass wir weniger wettbewerbsfähig sind. Ich habe dazu keine Nachforschungen angestellt, aber ich habe es mit Leuten besprochen. Denken Sie, dass Frauen eher kooperativ als wettbewerbsorientiert sind? Weil Wettbewerb großartig ist, aber Sie brauchen viel Zusammenarbeit im agilen Bereich und viel Fürsorge. Man muss dieses fürsorgliche Gefühl haben, die fürsorgliche Denkweise, genau das macht ein Scrum Master. Eines der wichtigsten Merkmale eines Scrum Masters muss sein, dass er diese fürsorgliche Perspektive haben muss, um sie dem Team zu vermitteln.
Caitlin Mackie:
Es ist lustig, dass Sie es erwähnt haben, weil ich selbst einige Dinge darüber gelesen habe, dass Frauen normalerweise eher diesen offenen Führungsstil besitzen und dass offene Führung den agilen Bereich wirklich gut zu ergänzen scheint.
Sarah Hajipour:
Das ist genau, ja.
Caitlin Mackie:
Ja. Ja. Das ist großartig und ich denke, wir können viel daraus lernen, offene Führung und direkte Führung. Also kommen Männer und Frauen nach vorne und finden diesen Mittelweg und ja, ich finde, Agilität ist ein großartiger Ort, um das zu tun?
Sarah Hajipour:
Ja, ich stimme vollkommen zu. Ja.
Caitlin Mackie:
Ja, ja. Also, was hat deine Leidenschaft angetrieben? Ich schätze, was hat Sie dazu bewogen, eine Karriere in diesem Bereich zu verfolgen?
Sarah Hajipour:
Ich liebe die Zusammenarbeit und ich liebe die Verwundbarkeit, weil Menschen quasi in den Teams, in denen sie arbeiten, verletzlich sein dürfen. Und es ist eine Kultur, die eher menschlich als extrem streng ist. Wir dürfen keine Fehler machen. Wir dürfen uns nicht irren. Führungskräfte sollten auf Anhieb alles wissen. Aber in Wirklichkeit ist das nicht der Fall. Führungskräfte müssen sich wohl fühlen, wenn sie viele Dinge nicht wissen, die noch nicht einmal bekannt sind. Aber oft sage ich immer, dass wir uns in der unbekannten unbekannten Zone befinden. Und in dieser Zone sollten selbst Führungskräfte nicht alles wissen.
Sarah Hajipour:
Vieles beginnt also damit, dass ich von meinen Interviewpartnern auch gelernt habe, dass alles mit der Führung beginnt. Bei agilen Transformationen müssen die Führungskräfte also zuerst eine Atmosphäre der Zusammenarbeit, des Vertrauens und der psychologischen Sicherheit untereinander schaffen. Und nur dann können sie den Teams helfen, auch in solchen Atmosphären erfolgreich zu sein.
Sarah Hajipour:
Frauen im agilen Bereich und Frauen in Führungspositionen. Das sage ich gerne und ich sehe viele Männer und Frauen, die beide ihre Perspektive ändern, von einem Prozess, bei dem die Werkzeuge im Mittelpunkt stehen, hin zu den Menschen, weil das für alle besser funktioniert. Und ich sehe wirklich Veränderungen in allen Branchen. Ich sehe es im Einzelhandel. Ich sehe es im Bauwesen, natürlich in der IT, im Finanzsystem. Und es gibt Männer und Frauen, die quasi Hand in Hand versuchen, diese Art zu denken und zu arbeiten.
Sarah Hajipour:
Und Frauen fühlen sich wohler, wenn sie wachsen und quasi ihre Hand heben und sagen: „Hey, ich kann jede Seite machen. Ich kann diese Rolle übernehmen“, weil sie das verstehen, weil sie die psychologische Sicherheit bieten, die Frauen seit Ewigkeiten haben. Es ist ein Arbeitsplatz, an dem hauptsächlich Männer waren, und wir steigen allmählich als Frauen in die Belegschaft oder in die Geschäftswelt ein. Diese psychologische Sicherheit hat es Frauen also ermöglicht, ihre Hand zu heben und sich in verschiedenen Rollen und Führungspositionen weiterzuentwickeln.
Caitlin Mackie:
Ja, ja. Dem könnte ich nur zustimmen. Gab es Ressourcen oder Netzwerke, solche Dinge, die dir auf deiner Reise geholfen haben?
Sarah Hajipour:
Von allen anderen lernen, wie ein Netzwerk aufzubauen, mein Netzwerk zu erweitern, indem ich reinkomme und sage: „Hey, ich weiß nicht. Ich will es wissen.“ Es gibt all diese erstaunlichen Dinge, die passieren. Ich verstehe gerne, wie das funktioniert, und ich erinnere mich, dass es einer dieser Gründer war. Wer ist der Gründer von Apple? Oh mein Gott. Sag es mir nicht.
Caitlin Mackie:
Steve Jobs.
Sarah Hajipour:
Ich liebe dieses Zitat von Steve Jobs, das besagt: „Es gab noch nie eine Zeit, in der ich um Hilfe gebeten habe und die Leute mir nicht geholfen haben.“ Also hebe einfach deine Hand und sage: „Ich brauche Hilfe.“ Und was ist das für eine Hilfe, die ich brauche? Ich muss darüber Bescheid wissen. Was heißt das? Was bedeutet Scrum für dich? Wie funktioniert es in Ihrer Branche? Wie funktioniert es? Und ich denke wirklich, dass das bis jetzt der Schlüssel für mich war, mit Menschen in Kontakt zu treten und einfach verletzlich zu sein und mich von ihnen unterrichten zu lassen.
Caitlin Mackie:
Ja. Ich denke, meine nächste Frage wäre, wie wir diese vielfältige und selbstbewusste Gemeinschaft von Frauen und unsere Aufgabe, den Anteil von Frauen in agilen Unternehmen zu erhöhen, stärken können? Und ja, was ist Ihrer Meinung nach entscheidend, um ein unterstützendes und förderliches Umfeld zu schaffen?
Sarah Hajipour:
Was ich gesehen und erkannt habe, ist, dass Frauen sich wirklich gegenseitig mehr unterstützen müssen und werden. In einer Studie von HBR, Harvard Business Review, aus dem Jahr 2016 hieß es: „Wenn nur eine Frau im Pool der Befragten ist, besteht für diese Frau keine Chance, den Job zu bekommen, auch wenn sie die Beste ist.“ Das erfordert also nicht, welche Frauen wirklich gut daran arbeiten. Nicht die Bienenkönigin zu sein, sondern auch andere Frauen zu engagieren und einzubeziehen. Denn je mehr Frauen in unterschiedlichen Rollen sind, desto empfänglicher werden wir in diesen Gemeinschaften sein. Meiner Meinung nach ist es wichtig, dass wir das verstehen und uns gegenseitig unterstützen, uns gegenseitig helfen und die Gemeinschaften darum herum aufbauen.
Sarah Hajipour:
Es gibt eine Community Women in Agile in verschiedenen Städten und Teilen der Welt, der auch ich angehöre und die großartige Arbeit leistet. Es sind tatsächlich nicht nur Frauen in diesen Gruppen. Ich sehe, dass auch Männer teilnehmen, aber es sind überwiegend Frauen, die versuchen, sich gegenseitig Einblicke in alle Aspekte der agilen Praktiken, der agilen Arbeitsweisen und so zu geben. Ja.
Caitlin Mackie:
Ja. Also ich denke, wie geht es weiter? Ich schätze, wie lautet Ihre Prognose für Frauen im agilen Bereich? Was müssen wir tun, um diese Dynamik fortzusetzen?
Sarah Hajipour:
Ich denke, Frauen werden in allem, worauf sie sich konzentrieren, großartig abschneiden, unabhängig davon. Unter dem Strich sind wir Menschen und wir alle haben das Potenzial, in dem zu wachsen, worauf wir unseren Geist und unser Herz richten, unabhängig von unserem Geschlecht. Ich würde mich freuen, wenn Frauen in der Lage wären, diese ganzheitliche Perspektive einzunehmen, dass sie unabhängig von ihrem Geschlecht alles tun können und sie sind, wir sind es.
Sarah Hajipour:
Wir haben von anderen Frauen gelesen, die in Geschäftsbereichen erfolgreich waren und von denen Sie der Meinung waren, dass Frauen wahrscheinlich nicht wie Astronautinnen abschneiden können. Es gibt Physikerinnen. Weibliche Vorbilder im Ingenieurwesen und all diese, die weniger verbreitet waren. Die Welt verändert sich zum Besseren und das ist großartig.
Caitlin Mackie:
Ja, ja. Ja, das liebe ich absolut.
Sarah Hajipour:
Es ist eine großartige Zeit, um am Leben zu sein.
Caitlin Mackie:
Ja. Ja, das ist aufregend. Ja, genau.
Sarah Hajipour:
Ja.
Caitlin Mackie:
Ja. Ich denke definitiv, dass wir in so vielen Branchen allmählich einen enormen Anstieg und die Sichtbarkeit weiblicher Vorbilder beobachten. Es ist also toll, das zu haben. Aber Sarah, das war so ein großartiges Gespräch. Ich wollte mit einer letzten Frage an Sie schließen. Wenn Sie Frauen, die gerade ihre Karriere in ihrer Branche beginnen, einen Ratschlag geben könnten, welcher wäre das?
Sarah Hajipour:
Ich würde sagen, der beste Rat, den ich geben kann, ist, dass wir die Macht haben. Und erstens müssen wir über das Geschlecht hinausschauen und irgendwie glauben, dass wir alles tun können, was wir wollen. Und zweitens: Scheuen Sie sich nicht, sich zu öffnen und Ihre Community aufzubauen, wie zum Beispiel eine Community aufzubauen, einer Gemeinschaft von agilen Praktikern oder agilen Coaches beizutreten, sogar Menschen, insbesondere Menschen, die mehr wissen als Sie.
Sarah Hajipour:
Und scheuen Sie sich nicht, um Hilfe zu bitten. Hab keine Angst zu sagen: „Hey, das ist neu für mich und ich liebe es, von euch zu lernen.“ Hab keine Angst davor, dich der Welt zu stellen, und du wirst viel lernen, was du nicht einmal erwarten würdest. So wie Sie das Ergebnis erhalten werden, werden Sie Dinge hören, die über das hinausgehen, was Sie erwartet haben. Es gibt eine Menge menschliches Potenzial, das freigesetzt werden kann, wenn Sie sich einfach nach draußen stellen und andere zu Ihrem Wachstum beitragen lassen.
Caitlin Mackie:
Das ist unglaublich. Das ist ein toller Rat, Sarah. Ich habe jede Minute unseres Gesprächs geliebt. Vielen Dank, dass Sie heute zu mir gekommen sind. Ich weiß das wirklich zu schätzen.
Sarah Hajipour:
Es war mir ein Vergnügen. Vielen Dank, dass du mich eingeladen hast.
- Podcast
Easy Agile Podcast Ep.8 Gerald Cadden Strategischer Berater und SAFe-Programmberater bei Scaled Agile Inc.

Gerald erzählte, dass Unternehmen bei der Implementierung agiler Methoden oft immer wieder vor den gleichen Herausforderungen stehen, aber die eigentliche und wichtigste Herausforderung ist die Überwindung einer festen Denkweise.
„Gerald hilft großen Unternehmen dabei, besser zusammenzuarbeiten und gleichzeitig dafür zu sorgen, dass sich die Teams auf die Menschen und den Kunden konzentrieren. Ich werde mir diese Episode noch einmal ansehen.“
Gerald hebt auch den Unterschied zwischen Beratern und Coaches hervor und wie wichtig es ist, gute Mentoren zu haben + mehr
Ich habe diese Folge geliebt und ich weiß, dass du es auch tun wirst!Abonniere unbedingt, genieße die Folge 🎧
Transkript
Sean Blake:
Hallo und willkommen zu dieser Episode des Easy Agile Podcasts. Sean Blake ist heute hier bei dir. Und wir haben einen großartigen Gast für Sie, es ist Gerald Cadden, strategischer Berater und Trainer für SAFe-Programmberater bei Scaled Agile, Inc. Gerald ist ein erfahrenes Unternehmen, IT-Experte, strategischer Berater und Trainer für Scaled Agile Program Consultant (SPCT) bei Scaled Agile. Danke, Gerald. Willkommen zum Easy Agile Podcast. Es ist wirklich toll, Sie heute als Gast zu haben, und vielen Dank, dass Sie ein wenig Zeit mit uns verbracht und Ihr Fachwissen im Easy Agile Podcast mit unserem Publikum geteilt haben.
Sean Blake:
Also ich bin wirklich interessiert und ich interessiere mich für diese Geschichte, die... Für all die Gäste, die wir beim Podcast haben, aber kannst du mir ein bisschen über deine heutige Karriere erzählen? Ich finde, dass die Leute ihren Weg zu diesen agilen Rollen oder in die Agile-Branche durch so viele verschiedene Arten von Jobs in der Vergangenheit gefunden haben. Manche Leute waren früher Klempner oder Handwerker, oder sie arbeiteten im Finanzwesen oder im Bankwesen. Wie haben Sie Ihren Weg gefunden, bei einem Unternehmen wie Scaled Agile zu arbeiten?
Gerald Cadden:
Guten Morgen, Sean. Danke, dass ich hier sein durfte, Leute. Ich freue mich sehr, heute hier bei euch zu sein. Karrieresachen sind immer eine interessante Frage. Ich bin 53 Jahre alt und wenn ich zurückblicke, frage ich mich, wie ich dahin komme, wo ich bin? Und oft kann man sich nur eine Reihe glücklicher Ereignisse ansehen. Und ich habe in Schuhgeschäften gearbeitet und dann habe ich beschlossen, etwas in meinem Leben zu tun. Ich habe ein IT-Diplom gemacht, dann einen Abschluss gemacht und angefangen, in der IT-Seite zu arbeiten. Ich habe quasi als Entwickler angefangen, weil dort das Geld war und du da hin wolltest. Ich bin nicht lange als Entwickler geblieben. In Ordnung. Alles klar. Ich war ein schrecklicher Entwickler, also war ich nicht gut darin. Es war frustrierend.
Gerald Cadden:
Ich habe vor dem Verkauf angefangen und das hat mich dazu gebracht, Geschäftsanalysen zu machen. Die BA-Arbeit hat mir sehr gut gefallen, weil ich mit Leuten arbeiten und Veränderungen sehen konnte. Ich konnte mit den Entwicklern arbeiten, konnte aber trotzdem direkt mit dem Kunden zusammenarbeiten, was für mich viel interessanter war. Also verbrachte ich viel Zeit in BA mit der Entwicklungsarbeit und der Neugestaltung von Geschäftsprozessen, meinem Übergang zu einem rationalen, einheitlichen Prozess. Als es das noch gab, habe ich unzählige Stunden damit verbracht, Anwendungsfälle für Ihre E-Mail-Diagramme zu schreiben und die Leute davon zu überzeugen, wie die Änderungen an diesen vorgenommen werden können. Und dann kam Agile und ich musste einen kompletten Gehirnwechsel vornehmen. All diese Dinge, die ich als BA gelernt hatte und von denen ich abhängig war, verschwanden plötzlich, weil Agile das nicht als direkte Arbeitsweise verlangte. Das musste im Hintergrund ablaufen, wenn man es wollte, und es war eher eine Zusammenarbeit.
Gerald Cadden:
Ungefähr 2004, 2005 fing ich an, viel mehr mit Agile zu arbeiten, bis ich in den USA lebte. Dort sammelte ich meine agilen Erfahrungen und blieb dort für eine lange Zeit. Ich habe großartige Erfahrungen gesammelt und bin dann etwa 2011 zur Arbeit mit SAFe übergegangen. Der Auslöser dafür war, dass ich für das große Finanzunternehmen in New York mit einem Team dort gearbeitet habe. Und wir waren dabei, eine umfangreiche Methode für sie neu zu entwickeln, um Agile in großem Maßstab zu implementieren. Als wir 2011 auf einer Agile-Konferenz an einem Seminar teilnahmen, sah Dean Leffingwell eine Präsentation über SAFe und schaute einfach auf und sagte: „Nun, wir können aufhören, an unserer Methodik zu arbeiten. Es ist erledigt.“
Gerald Cadden:
Also kaum nach diesem Treffen rannte ich nach draußen und ging mit Dean Leffingwell los, weil ich wollte, dass er sich meine Diagramme und alles ansieht und mir eine Bestätigung gibt, dass ich das Richtige tue. Dean hat ein sehr offenes Gesicht und er zog sein offenes Gesicht und sah mich an und sagte einfach: „Weißt du was? Einfach SAFe benutzen?“ Und ich sage: „Ja, das werden wir.“ Und so begann ich meine SAFe-Reise zu dieser Zeit und wir haben dieses Finanzunternehmen gegründet und seitdem bin ich auf dieser Reise.
Sean Blake:
Bringen Sie uns also zurück vor 10 Jahren ins Jahr 2011. Und Sie arbeiten bei diesem Finanzunternehmen, Sie haben von diesem Konzept von SAFe gehört, und zwar zum ersten Mal, als Sie damit begonnen haben, es umzusetzen. Wie haben die Mitarbeiter dieses Unternehmens darauf reagiert, dass Sie diese neue Denkweise in diesen neuen Rahmen eingeführt haben? Es hörte sich an, dass Sie die Diagramme zu den Frameworks und den Konzepten, die sich in Ihrem Kopf herausbildeten, bereits hatten. Fanden Sie das für einen einfachen Prozess? Ich glaube, ich kenne die Antwort bereits, aber wie komplex war es, SAFe zum ersten Mal in einer Organisation dieser Größenordnung einzuführen?
Gerald Cadden:
Ja, das ist ein sehr großes Finanzunternehmen, ein sehr altes Finanzunternehmen, also eine sehr traditionelle Arbeitsweise. Interessant sind also die gleichen Herausforderungen, vor denen SAFe heute steht, schon vor der Gründung von SAFe. Es gab also immer noch dieselben Herausforderungen wie bei früheren Managementansätzen, die versuchten, zu schnelleren Arbeitsweisen überzugehen. Während wir also wie wild in Visio Diagramme zeichneten und versuchten, Modelle zu erstellen, die die Menschen verstehen, war es schwierig, ein Kontinuum an Wissen und Bildung zu schaffen, das die Menschen dazu brachte, von ihrer Denkweise zu der Denkweise überzugehen, die wir uns für sie wünschten. Und für mich und das Team, mit dem ich gearbeitet habe, war es eine Reise, die sich ständig weiterentwickelt hat. Ich arbeite mit einem wirklich großartigen Mann zusammen und sein Name ist Algona, ein sehr, sehr kluger Mann.
Gerald Cadden:
Und so kratzen wir uns beide ständig am Kopf, wie wir das Management dazu bringen können, seine Meinung zu ändern. Und wir haben uns auf Bildung konzentriert, aber es war immer noch eine große Herausforderung. Ich habe das Projekt abgeschlossen, so wie sie mit SAFe angefangen haben. Ich wechselte in das Unternehmen in eine andere Managementposition, sodass wir die Arbeit dort fortgesetzt haben. Michael Stump, er hat früher für Scaled Agile gearbeitet. Ich glaube, er arbeitet jetzt in einem anderen Unternehmen, aber er hat einen Großteil dieser Arbeit fortgesetzt und wirklich gute Arbeit geleistet und sie haben SAFe implementiert. Sie haben Änderungen vorgenommen, aber sie standen vor den gleichen Herausforderungen. Die Denkweise des Managements überwand die Abkehr von den Silos hin zu einer stärker netzwerkstrukturierten Organisation. Nur die Tools, nur die einfachen Dinge waren immer noch eine Herausforderung, und es gibt auch heute noch eine Herausforderung. Die Art der Organisation entwickelt sich also auch in der modernen agilen Welt immer noch weiter.
Sean Blake:
Sie haben dort erwähnt, dass ein Teil der Herausforderung in den Bereichen Denkweise und Bildung liegt. Haben Sie irgendwelche Abkürzungen gefunden, um die Denkweise eines Teams zu ändern? Die Art und Weise, wie sie an ihre Arbeit herangehen, wie sie die Zusammenarbeit mit anderen Teams in dieser Organisation angehen? Ich gehe davon aus, dass der Erfolgsfaktor viel damit zu tun hat, ob das Team seine Denkweise in Bezug auf die Art und Weise, wie es zuvor gearbeitet hat, geändert hat und sich nun dieser neuen Arbeitsweise verschrieben hat? Und können Sie mit uns ein wenig darüber sprechen, wie Sie die Denkweise eines Teams ändern können?
Gerald Cadden:
Vielleicht ändere ich hier die Richtung Ihrer Frage, denn was ich herausgefunden habe, ist, dass Sie normalerweise nicht zu hart arbeiten müssen, um die Denkweise eines Teams zu ändern. Die meisten Teams sind wirklich begierig darauf, neue Dinge auszuprobieren und innovativ zu sein. In Teams begegnet man nur einigen Leuten, deren Karriereweg sie vielleicht an einen bestimmten Punkt gebracht hat, an dem sie mit der Welt zufrieden sind und sich nicht ändern wollen. Die Denkweise, die Sie wirklich ändern müssen, bezieht sich auf diesen Führungsbereich, und das gilt auch heute noch. Die Teams werden sich also schnell anpassen, wenn das Management das Umfeld schaffen kann, das es ihnen ermöglicht, und wenn sie dazu befähigt werden können. Aber es ist wirklich... Wenn Sie das Team befähigen wollen, müssen Sie die Führungskräfte um sie herum dazu bringen, ihre Denkweise zu ändern, die Strukturen zu ändern, die die Teams daran hindern, die bestmögliche Arbeit zu leisten.
Gerald Cadden:
Und das war für mich die große Entdeckung, während du mitgemacht hast, und das gilt auch heute noch. Während sich Agile weiterentwickelt hat, ist mir aufgefallen, dass Führungskräfte nicht immer ganz oben auf der Liste der Herausforderungen stehen, aber für mich stand sie immer ganz oben auf der Liste. Viele Menschen wollen sich Führung ansehen und Dinge über sie sagen, die wenig schmeichelhaft sind, aber man muss bedenken, dass es sich um Menschen handelt. Und der beste Weg, um Führung zu erlangen, besteht darin, wirklich mit einem Gespräch zu beginnen und ihnen zu helfen, es zu verstehen. Sie kennen die Herausforderungen, aber wir müssen ihnen helfen, zu verstehen, was die Probleme verursacht, die zu diesen Herausforderungen führen.Gerald Cadden:
Wenn du mit ihnen zusammenarbeitest und sie erziehst, kannst du ihren Geist ein bisschen mehr öffnen. Bedeutet das, dass sie sich tatsächlich ändern werden? Nicht unbedingt. Politische Beweggründe, Ideologien und andere Dinge hinderten die Führung daran, sich zu bewegen. Aber Gespräche und Bildung sind meiner Meinung nach der richtige Weg, um Führung wirklich anzugehen. Und sie als Person kennenzulernen, sich für ihre Herausforderungen zu interessieren, sich für sie als Individuum zu interessieren. Es ist also wichtig, diese soziale Bindung herzustellen. Als Berater war das immer schwierig, denn als Berater wird man immer als externe Kraft gesehen und es ist schwierig, eine gewisse soziale Beziehung zu dieser Führung aufzubauen und dieses Vertrauen aufzubauen.
Sean Blake:
Ja, das ist so wahr. Ja, ist es nicht. Ich erinnere mich an eine Agile-Transformation, an der ich zuvor teilgenommen habe, wie der Agile-Coach wirklich genauso viel Zeit mit dem Führungsteam verbrachte wie mit uns, dem Agile-Team. Und es scheint seltsam, dass der Coach so viel Zeit damit verbracht hat, das Führungsteam wirklich darin zu coachen, wie es über diese neue Arbeitsweise denken sollte, aber wenn man es in den richtigen Kontext stellt, ist es so wichtig, dass sie dieses Umfeld schaffen, in dem sich ihre Mitarbeiter und ihre Teams sicher fühlen, wenn sie etwas Neues ausprobieren. Ja, das ist wirklich wichtig.
Gerald Cadden:
Ich denke, wenn Sie sich ansehen, wie sich Agile entwickelt, wenn Sie sich die Erstellung des Agile-Manifests und seiner Prinzipien und dann der folgenden Frameworks wie ScrumXP usw. ansehen, hat es sich aus der Teamperspektive entwickelt. Also gingen alle davon aus, dass wir diese Dinge entwickeln müssten, damit die Teams ihnen folgen, aber als die Leute mit Teams arbeiteten, stellten sie fest, dass es überhaupt nicht die Teams waren, die Teams passen sich an, sondern das Management und die Strukturen der Organisationen passen sich nicht an. Und genau da ist es hingegangen.
Gerald Cadden:
Ich kann mich nicht an die Anzahl der unzähligen Scrum-Implementierungen erinnern, an denen Sie gearbeitet haben, und Sie haben gerade die Obergrenze der organisatorischen Herausforderungen erreicht. Und es war immer sehr frustrierend für die Teams. Ich denke, es gibt auch eine andere Seite dazu: Zu viele in der agilen Welt betrachten die Teams einfach als den Mittelpunkt der Welt und man kann es auch nicht von dieser Art aus angehen. Die Teams sind sehr wichtig, um den Kunden einen Mehrwert zu bieten, aber es ist das Unternehmen als Ganzes, das Wert liefert. Und ich denke, man muss sich wirklich zurücklehnen und einfach sagen: „Die Teams sind Teil davon, wie ändern wir die Organisation einschließlich der Teams?“
Sean Blake:
In Ordnung. Das ist wirklich interessant. Gerald, du hast ein bisschen über Teams und Denkweisen gesprochen. Wenn du in eine Organisation gehst, einen großen Autohersteller oder eine große Fluggesellschaft oder ein Finanzdienstleistungsunternehmen und sie dich um Hilfe bitten oder um deine Ausbildung bitten, wie beurteilst du dann, wo die Organisation steht? Wie hoch ist ihr Reifegrad aus agiler Sicht? Kommen Unternehmen zu Ihnen, die im Kopf haben, dass sie bereit sind, SAFe zu machen, und dann tauchen Sie am ersten Tag auf und es stellt sich heraus, dass niemand eine wirkliche Vorstellung davon hat, wie diese Art von Engagement aussieht?
Gerald Cadden:
Ja, das ist eine gute Frage. Denn ich denke, wenn ich auf die Geschichte zurückblicke, 2011, 2012, als SAFe wirklich in Gang kam, als Sie vorankamen, ich meine, es gab keine Vorstellung, wo ich anfangen sollte. Die Berater fanden es einfach selbst heraus und wie bei den meisten Beratungen oder den meisten Methoden beschäftigten sie sich in einem IT-Bereich und auf Teamebene. Und die Leute würden versuchen, von der Teamebene an zu wachsen. Und irgendwann müssen wir wissen, dass ich viel damit zu kämpfen hatte, weil ich nur versucht habe herauszufinden, wo das ist. Mein Beraterhut war also immer auf, um mich hinzusetzen, mit den Leuten über ihre Herausforderungen zu sprechen und einen Weg zu finden, herauszufinden, wie die Herausforderungen gelöst werden können, ob es nun Scrum oder SAFe sein würde oder was auch immer richtig sein würde.
Gerald Cadden:
Das sind nur Werkzeuge in der Toolbox. Aber als ich Agile skalierte, mit dem ich gearbeitet habe... Entschuldigung, als ich mit SAFe gearbeitet habe, hat Scaled Agile die Implementierungs-Roadmap herausgebracht. Es hat so viel mehr Klarheit gebracht, als ich später bei SAFe gearbeitet habe, und ich wünschte, es wäre früher gekommen, weil es mir wirklich geholfen hat, die anfängliche Sache zu klären, die wir als Überwindung des Kipppunkts bezeichnen. Wie man mit der Organisation zusammenarbeitet, mit der man spricht, mit den richtigen Leuten zusammenarbeitet, ihre Herausforderungen versteht, ihnen hilft zu verstehen, was diese Probleme verursacht, was die traditionellere Arbeitsweise der traditionellen Management-Mentalität ist, ihnen hilft, SAFe zu verbinden, um diese Herausforderungen zu bewältigen und ihnen zu zeigen, wie sie beginnen können. Wenn Sie sich die Roadmap ansehen, handelt es sich um eine zusammenhängende, schrittweise Angelegenheit, aber in Wirklichkeit stellen Sie fest, dass zwischen diesen Schritten Lücken bestehen, und in diesen Lücken führen Sie als Übergangsteam viele Gespräche mit dem Management.
Gerald Cadden:
Wenn du sie durch eine Schulung bringst, werden sie nicht aus dem Kurs kommen und sagen: „Oh, wow, das war's. Wir wissen, was zu tun ist.“ Es bedarf eines Folgegesprächs. Sie müssen in vielen Gesprächen eins zu eins führen und Themen behandeln, bei denen Sie Vorteile haben, damit Sie die Annahmen ausräumen oder die Missannahmen bereuen können. Es ist also ein großer Teil dieser Art von Arbeit, dass die Roadmap da ist, für diejenigen, die SAFe heute implementieren, sie verwenden. Es ist eines der hilfreichsten Tools, die Sie haben werden.
Sean Blake:
Fantastisch. Ja. Ich denke, wenn man nur den Unterschied zwischen den Tools in der Toolbox anerkennt und dann die andere Tatsache, dass man es mit Menschen zu tun hat und mit Einstellungen und Motivationen und Verhaltensweisen und Gewohnheiten, gibt es wirklich zwei sehr unterschiedliche Dinge. Es hört sich an, dass du sie alle zusammen auf diese Reise mitnehmen musst.
Gerald Cadden:
Ja. Außerdem bilden wir so viele SPCs wie SAFe-Programmberater aus. Wir bilden sie aus und bilden sie ständig außerhalb des Unterrichts bei uns und unseren Partnern aus. Was du kannst, du kannst ihnen das Framework beibringen, aber du kannst ihnen nicht unbedingt beibringen, wie man ein guter Berater oder ein guter... Ich möchte sagen, dass ich den Begriff Berater und Coach verwende, oder?
Sean Blake:
Ja.
Gerald Cadden:
Manchmal sage ich gerne, dass ein guter Berater ein guter Coach sein kann, aber ein guter Coach muss nicht unbedingt ein guter Berater sein, weil es noch eine andere Wissenswelt gibt, die man haben muss, wie setzt man sich hin und spricht mit Führungskräften? Wie lernt man die Patienten kennen und welche Art von Fragen man stellen muss, wie lernt man, diese Beziehungen aufzubauen und zu verstehen, wie man mit politischen Maßnahmen umgeht? Es gibt also Dinge, die außerhalb des Fachwissens eines SPC liegen und die sie sich aneignen müssen. Also junge Leute, die kommen und rennen, um diesen SPC-Kurs zu machen. Ich möchte euch auf alles vorbereiten, aber er gibt euch die Grundlagen.
Sean Blake:
Wenn Sie also in einer Organisation sind oder Menschen coachen, um zu ihrer Organisation zurückzukehren, wie bringen Sie ihnen diese Coaching-Fähigkeiten bei, damit sie, wenn sie reinkommen und die Politik lernen müssen, die roten Fahnen erkennen müssen, sie müssen die Abhängigkeiten bewältigen, sie müssen neue Teams in den Zug bringen? Wie geht man wirklich vor, um den menschlichen und kommunikativen Werkzeugkasten auszustatten?
Gerald Cadden:Ich denke, Sie können die Grundlagen des Frameworks natürlich vermitteln, indem Sie die Schulungen durchgehen. Aber Mentoring ist für mich der richtige Weg. Jedes Mal, wenn ich eine Schulung gebe, mache ich den Leuten ganz klar, wenn sie zurückgehen und eine Transformation beginnen, sollten sie das nicht alleine machen. Finden Sie erfahrene Leute, die das gemacht haben, und die Erfahrung sollte nicht nur mit SAFe sein. Sie sollten bei Bedarf Erfahrung mit großen Organisationen gesammelt haben, die Erfahrung mit der Portfolioebene haben. Ganz einfach, weil es Fähigkeiten gibt, die Menschen im Laufe der Jahre ihrer Karriere entwickeln, wenn sie sie zu Beginn nicht hatten.
Gerald Cadden:
Ich meine, wenn ich auf einige der schrecklichen Dinge zurückblicke, die ich in Besprechungen und vor Führungskräften gesagt hatte, würde mein Chef seine Hände vor sein Gesicht legen, weil ich jung und impulsiv und unreif war, und das sehe ich heute. Als ich das erste Mal in die USA kam, arbeitete ich mit einigen jüngeren BAs zusammen und sie sagten Dinge in Besprechungen und man musste schnell um einige Dinge herumtanzen, bis man sagte: „Das wollten wir gerade nicht wirklich sagen.“ Deshalb denke ich, dass Mentoring die richtige Fähigkeit ist. Wir können dir die taktischen Fähigkeiten beibringen, aber dir die politischen Fähigkeiten, die menschlichen Fähigkeiten beizubringen, erfordert Mentoring und Zeit.
Sean Blake:
Mentoring ist in diesem Zusammenhang so wichtig. Ist es nicht?
Gerald Cadden:
Ja.
Sean Blake:
In Ordnung. Lassen Sie uns also vor 12 Monaten auf März 2020 zurückspulen. Ein Monat, der sich wahrscheinlich in den Köpfen vieler Menschen eingebrannt hat, ist der Monat, in dem COVID unser Leben auf absehbare Zeit verändert hat. Ich weiß, dass Easy Agile viele Inhalte hatte, Artikel darüber, wie man PI-Planung aus der Ferne durchführt, wie Sie Ihren virtuellen Teams helfen können, besser zusammenzuarbeiten, und wir wussten nicht, dass COVID kommen würde. Wir haben gerade diesen Trend in der Belegschaft gesehen und wir hatten diese Inhalte verfügbar.
Sean Blake:
Und dann habe ich mir unsere Website-Analysen angesehen und wir hatten einen riesigen Anstieg bei dem, was ich vermute, waren die Leute in diesen Unternehmen, die zum ersten Mal versuchten, herauszufinden, wie man PI-Planung virtuell durchführt, wie man ihre Freigabezüge buchstäblich auf den Gleisen hält, in einer Zeit, in der die Leute entweder den Staat verließen, zum ersten Mal von zu Hause aus arbeiteten, es ist wirklich so, als ob jemand die Bombe mitten in diesen Auslasszügen abgeworfen hat und die Leute darauf herumkraxeln, wie wir sind machen wir das jetzt virtuell? Hatten Sie zu der Zeit viele Fragen dazu, wie wir das machen werden? Und wie haben Unternehmen Ihrer Meinung nach auf diese Herausforderungen reagiert?
Gerald Cadden:
Ja. Ich erinnere mich, dass ich im Januar 2020 in Boulder, Colorado, war und gerade aus dem Urlaub in Australien zurückgekommen bin. Zu diesem Zeitpunkt kam COVID auf und Sie haben im Januar 2020 von Dingen gehört. Ich habe mit meinen Kollegen gesprochen und wir haben uns gefragt, wie schlimm das sein wird. Innerhalb von zwei Monaten fällt die Welt auseinander. Und ich denke, für uns ist es eine gute Möglichkeit, diese Geschichte zu erzählen, wenn wir uns ansehen, was Scaled Agile getan hat. Wir wussten, dass unser Geschäft sehr stark vom Erfolg unserer Partner abhängt, und das ist es auch heute noch. Und als wir anfingen, die physische Welt der PI-Planung und -Schulung zu verstehen, wurde uns klar, dass das Unternehmen, wenn es völlig auseinanderfiel, sich schnell anpassen musste.
Gerald Cadden:
Wir hatten bereits eine Reihe von Prioritäten für den PI festgelegt und implementieren Scaled Agile intern im Unternehmen. Zu der Zeit leiten wir das Unternehmen als Zug selbst, weil es 170 Personen sind. Also mussten sie die verschiedenen Epen neu priorisieren, wir haben neue Funktionen veröffentlicht und es ging nur darum, was wir jetzt ändern müssen, um unsere Partner über Wasser zu halten, indem wir sie online bringen, und ein wirklich gutes Team von Scaled Agile, das sich wirklich unternehmensübergreifend darum bemüht, kurzfristige Online-Materialien zu erstellen, um die Partner auf dem Laufenden zu halten, damit sie weiter unterrichten konnten. Sie könnten Wege finden, dies zu tun, PI-Planung durchzuführen, sie überprüfen Anpassungen alles online. Deshalb haben wir eine Menge Material einfach in Form von PowerPoint-Folien herausgebracht, die sie dann in Tools wie Mural, Al Tool integrieren konnten. SAFe Collaboration — wir haben das entwickelt, und das ist im Laufe der Zeit immer reifer geworden.
Gerald Cadden:
Und jetzt sind wir in einer Welt, in der wir viel mehr Stabilität haben. Wir haben einen großen Einbruch erlebt, wie jeder andere auch, aber die Frage ist, werden Sie aus diesem Einbruch herauskommen? Also, was wir wahrscheinlich sogar im zweiten Quartal dieses Jahres bemerkt haben, als wir am Ende sahen, dass es wieder auftauchte, was unsere Partner anfingen, mehr online zu unterrichten. Die Zahlen sagten uns also, dass die Materialien, die wir produzieren, funktionierten. Für uns war es einfach eine großartige Bestätigung, dass es uns gerettet hat, sich so zu organisieren, wie wir uns organisiert haben, die schnelle Art und Weise, wie wir uns anpassen konnten. Scaled Agile hätte also den Weg vieler Unternehmen gehen können und nicht überleben können, weil unsere Partner nicht überlebt hätten. Wir hatten die Fähigkeit, uns anzupassen. Aus meiner Sicht ist es also eine großartige Erfolgsgeschichte.
Sean Blake:
Nun, das ist großartig. Wir freuen uns alle, dass du immer noch da bist, um die Geschichte zu erzählen.
Gerald Cadden:
Ja, das sind wir.
Sean Blake:
Und Gerald, ob Sie nun über Unternehmen nachdenken, mit denen Sie in der Vergangenheit zusammengearbeitet haben, oder vielleicht sogar über das interne Scaled Agile-Beispiel, das Sie gerade angesprochen haben. Gibt es bestimmte Treffen, Zeremonien oder Kontrollpunkte, die im Rahmen des Agile Release Train-Prozesses wirklich wichtig sind? Was sind die Dinge, die für Sie wirklich verpflichtend sind, oder die wichtigsten Elemente, an denen sich das Unternehmen während der eigentlichen Einrichtungsphase, in der es versucht, den Scaled Agile-Ansatz zu verwirklichen, wirklich festhalten sollte?
Gerald Cadden:
Also interpretiere ich deine Frage richtig. Ich denke, wenn Sie die wirklich wichtigen Dinge umsetzen, auf die Sie sich als Team konzentrieren müssen, ist für mich zuallererst die PI-Planung. Das ist die wichtigste Sache. Es ist das erste, was die Leute ändern wollen, weil es zwei Tage dauert und jeder kommen muss und es Unternehmen eine beträchtliche Summe an Geld kosten kann, das alle 10 bis 12 Wochen durchzuführen. Sie werden also sehr schnell davonlaufen, wie ich es in der Vergangenheit in der Autofirma getan habe. Sie treffen sehr schnell auf den Finanzkontrolleur, der verstehen will, warum Sie 40.000$ pro Quartal für ein großes zweitägiges Meeting ausgeben. Und so lügen sie, sie fangen an, jeden Punkt auf der Rechnung in Frage zu stellen, aber das ist der wichtigste.
Gerald Cadden:
PI-Planung ist wichtig. Das Prüfen und Anpassen ist das andere, einfach weil wir am Ende keine Verbesserungsmöglichkeiten haben, wenn Sie diesen Feedback-Zyklus entfernen, was wir als Schließen des Kreislaufs bezeichnen, wenn Sie ihn entfernen. Diese beiden Ereignisse selbst bilden also die Grundlage dafür, womit wir beginnen und wie wir den Kreislauf schließen, aber es gibt kleinere Ereignisse, die zwischen den Teamevents stattfinden, die natürlich alle wichtig sind. Aber wichtiger für mich ist die Konstante, das Ereignis für das Produktmanagement-Team oder das Programmmanagement-Team, wie werden Sie sie filtern, entschuldigen Sie.
Gerald Cadden:
Wer muss sich regelmäßig treffen, um das sicherzustellen, dann nennen wir das den Sync. Das ist also der ART Sync oder der POPM Sync. Sie müssen sicherstellen, dass diese eingehalten werden, da es sich dabei um dynamischere Feedback-Schleifen handelt und sicherstellen, dass gute architektonische Anforderungen oder gute Funktionen umgesetzt werden, sodass die Teams, wenn Sie zu PI Planning kommen, wichtige Dinge zu erledigen haben. Wenn Sie mir also meine drei wichtigsten Ereignisse nennen müssten: PI Planning, Inspect and Adapt und ART Sync und das Produkt POPM Sync.
Sean Blake:
Fantastisch. Ich weiß, dass es für Teams immer die Versuchung gibt, Abkürzungen zu finden und die Problemumgehungen zu definieren, bei denen sie bestimmte Besprechungen oder bestimmte Check-Ins nicht durchführen müssen, aber in Bezug auf die Kommunikation muss es für diese Teams sehr wichtig sein, sicherzustellen, dass sie immer noch kommunizieren und das Framework nicht als Ausrede benutzen, um die Besprechungen zu beenden und die Zusammenarbeit einzustellen.
Gerald Cadden:
Ja. Ja, das habe ich durchgemacht, als ich bei der großen Autofirma in den USA angefangen habe, habe ich beschlossen, das Pflaster abzuzocken. Sie hatten mehrere Teams, die an Projekten arbeiteten, und es ging ihnen nicht gut. Als ich mir die Herausforderungen ansah und beschloss, SAFe zu implementieren, sagten einige vom Management: „Bist du verrückt? Warum würdest du das tun?“ Aber sie haben mir vertraut. Also haben wir das Pflaster abgerissen und sie alle zu einem Knoten geformt. Wir haben die Einrichtung gestartet. Und ich erinnere mich, dass einige Mitglieder des Managements am Ende der PIs viele Zweifel hatten, die kamen, nachdem sie die PI durchgesehen hatten und sagten, sie könnten einfach nicht glauben, wie toll das war.
Gerald Cadden:
Obwohl der erste PI etwas chaotisch war, verstanden sie die Arbeit und die Zusammenarbeit, die Ausrichtung, nur die Diskussionen, die stattfanden, waren für sie viel aussagekräftiger. Und die Teams waren glücklicher, sie gingen in eine andere Umgebung. Es hat also die Stimmung stark verändert. Also ich denke, dass die Teams ihre Fähigkeit haben, an einer der wichtigsten Stellen gehört zu werden, während der PI-Planung, sie bekommen die Chance, gehört zu werden. Sie erhalten die Chance, mitzumachen, anstatt erst am Ende zu sein, wo ihnen gesagt wird, was zu tun ist.
Sean Blake:
Mm-hmm (bejahend). Es stärkt das Team also wirklich.
Gerald Cadden:
Ja. Ja, absolut.
Sean Blake:
Das ist großartig. Wenn ein Unternehmen also die Implementierungsphase hinter sich lässt und sich ein bisschen mehr an die Art und Weise gewöhnt, die Dinge zu erledigen, was ist der beste Weg für es, diese Fortschritte der gesamten Organisation mitzuteilen und dann diese Arbeitsweise wirklich zu evangelisieren, um zu versuchen, mehr Teams an Bord zu holen und mehr Agile Release Trains einzurichten, sodass es wirklich ein Ansatz für das gesamte Unternehmen ist.
Gerald Cadden:
Ja. Eine gute Frage. Also ich denke zuallererst an die Systemdemo, die wir machen. Also die regelmäßigen Systemdemos, die stattfinden, das ist eine Veranstaltung, zu der man Leute einladen kann. Wenn Sie also das Ende der Programminkremente erreichen, die 10, 12 oder die acht, 10 oder 12 Wochen, und Sie machen Ihre PI-System-Demo, ist das eine Gelegenheit für Sie, Leute einzuladen, die vielleicht in der Organisation stehen und die das tun werden, oder sie sind neugierig, oder wenn Sie externe Lieferanten haben, die Sie im Rahmen der Schulung mit ins Boot holen möchten, lassen Sie sie kommen. Lassen Sie sie zu diesen Veranstaltungen kommen, damit sie einfach teilnehmen können. Sie können sehen, was vor sich geht, und das nimmt einem Teil der Angst vor dem, was das Zeug ist. Es gibt ihnen viel Arbeit.
Gerald Cadden:
Also die Systemdemo, ob du es während der PI machst, aber auf jeden Fall die PI-Systemdemo und du willst die. Also eher spontane Dinge und eines der Dinge, bei denen Organisationen, die ich gesehen habe, wirklich nicht tun, ist, wenn sie Erfolg haben, die Führung rund um den Zug gehen muss, und ich hasse den Begriff „evangelisieren“, aber gehen Sie raus und zeigen Sie die Erfolge. Gehen Sie raus und sprechen Sie bei der nächsten Firmentagung darüber, wo sie waren und wo sie jetzt sind. Teilen Sie in diesem Zusammenhang aber nicht nur die Kennzahlen mit, die auf eine höhere Wertschöpfung hindeuten, zeigen Sie die menschlichen Kennzahlen, zeigen Sie, wie das Team von einem gewissen Grad der Verärgerung zu einem vielleicht glücklicheren Gefühl und besserem Feedback übergegangen ist, sondern zeigen Sie, wie Unternehmen und Technologie näher zusammengekommen sind, weil sie in der Lage sind, zusammenzuarbeiten und gemeinsam Wert zu schaffen, anstatt uneins zu sein, weil das System sie uneins macht.
Sean Blake:Fantastisch. Gerald, gibt es noch etwas, das du unserem Publikum mitteilen möchtest, bevor wir die Folge beenden? Irgendwelche Tipps oder ermutigenden Worte oder vielleicht ein paar Ratschläge für diejenigen, die erwägen, ihre Agile-Teams zu erweitern.
Gerald Cadden:
Ich denke, der eine Ratschlag, den ich noch einmal wiederhole, ist, während Sie den Implementierungsprozess durchlaufen und damit beginnen, Ihren Zug zu starten und Ihre Teams zu schulen, herauszufinden, wie Sie sie beim Start unterstützen werden. Wenn die Leute einen SPC-Kurs oder all die anderen Klassen absolvieren, werden sie nicht als sichere Genies herauskommen. Sie werden Wissen haben und sie werden den Enthusiasmus haben und auch etwas Angst haben, aber du brauchst gutes Coaching. Finden Sie also heraus, wenn Sie mit dem Implementierungsmuster beginnen, bei dem Sie die Teams usw. entwerfen, und finden Sie heraus, wie Ihr Coaching-Muster aussehen wird. Stellen Sie die Leute ein, die über das Wissen und die Erfahrung verfügen, und arbeiten Sie mit einem Partner zusammen, der das Wissen und die Erfahrung sammelt. Sie sollten nicht für immer dort bleiben, wenn Sie mit Beratern zusammenarbeiten.
Gerald Cadden:
Ihre Aufgabe sollte es sein, Sie zu befähigen, nicht dauerhaft dort zu bleiben, aber ohne dieses Coaching und das Coaching über ein paar PIs neigen Ihre Teams dazu, auf Probleme zu stoßen und rückwärts zu gehen. Um diese Dynamik aufrechtzuerhalten, geht es für mich darum, das Coaching-Muster herauszufinden. Die einzige andere, die ich auch sagen würde, ist eine gute Zusammenarbeit zwischen dem Produkt und den Personen, die die Rolle des Produktmanagements in der Architektur übernehmen werden, sicherzustellen, die Beschwerden zu beseitigen und sie zusammenarbeiten zu lassen, weil sie einen ersticken können. Steigen Sie ein und sprechen Sie vor der Markteinführung über die Umgebungen. Sie wollen keine komischen Probleme haben, wenn Sie sagen: „Oh, die Architektur ist schrecklich.“ Okay. Lass uns darüber sprechen, bevor wir starten.“ Also nur ein paar Dinge, die ich für wirklich wichtig halte, auf die Sie sich konzentrieren sollten, bevor Sie den Zug starten.
Sean Blake:
Fantastisch. Das weiß ich wirklich zu schätzen, Gerald. Ich habe in unserem Chat tatsächlich viel gelernt. Es sind dieselben Herausforderungen, die Sie vor 10 Jahren hatten, es sind dieselben Herausforderungen, vor denen wir heute stehen. Das eigentliche Problem von COVID ist die Herausforderung, wie Sie sich auf die Änderung der Denkweise konzentrieren können. Wir haben darüber gesprochen, dass die Teams bestrebt sind, sich zu ändern. Es mag ein paar murrende Stimmen geben, aber in Wirklichkeit geht es darum, dass Führung ein einladendes und sicheres Umfeld bietet, um diesen Wandel zu fördern, und um den Unterschied zwischen Coach und Berater, die Bedeutung von Mentoring. Wow, wir haben tatsächlich eine Menge Boden zurückgelegt, nicht wahr?
Gerald Cadden:
Ich kriege vielleicht Hasspost für diesen Kommentar, aber...
Sean Blake:
Oh, wir werden sehen. Die Zeit wird es zeigen. Vielen Dank, Gerald, dass Sie sich uns im Easy Agile Podcast angeschlossen haben. Und wir freuen uns, dass Sie Ihr Fachwissen mit uns und dem Publikum für den Podcast teilen. Danke, dass du gekommen bist.
Gerald Cadden:
Ich mache es jederzeit gerne. Danke, dass ich heute hier bin.
Sean Blake:
Danke Gerald.
- Podcast
Easy Agile Podcast Ep.21 LIVE von Agile2022!
„Das ist ein Abschluss von Agile2022! Es war großartig, so viele von Ihnen in der Agile-Community persönlich treffen zu können!“ - Tenille Hoppo
Diese Bonus-Episode wurde LIVE bei Agile2022 in Nashville aufgenommen!
Das Easy Agile-Team hat mit so vielen großartigen Leuten aus der Agile-Community gesprochen und über die Höhepunkte der Konferenz, wichtige Erkenntnisse, agile Zeremonien und mehr nachgedacht!
Vielen Dank an alle, die am Stand vorbeigeschaut haben, um G'Day zu sagen und ein oder zwei Tim Tam genossen haben;)
Vielen Dank an alle unsere Podcast-Gäste, dass sie einige Zeit mit uns verbracht haben, um diese Episode zu erstellen!
- Cody Wooten
- Gil Broza
- Maciek Saganowski
- Lindy Quick
- Carey Young
- Leslie Morse
- Dan Neumann
- Joe Falu
- Kai Zander
- Avi Schneier
- Doug Page
- Evan Leyburn
- John Kerr
- Josua Seckel
- Rob Duval
- Andrew Thompson
Transkript
Caitlin:
Hallo zusammen. Nun, das ist ein Abschluss von Agile 2022 in Nashville. Das Easy Agile-Team ist wieder zu Hause in Australien, und wir haben den größten Teil unserer Heimreise damit verbracht, über all die großartigen Gespräche zu sprechen, die wir mit allen Mitgliedern der Agile-Community führen konnten. Es war großartig, Kunden und Partner zu treffen, alte Freunde zu sehen und viele neue zu finden. Wir haben es geschafft, einige Ausschnitte dieser großartigen Gespräche aufzunehmen, und wir freuen uns, sie mit Ihnen, unserem Easy Agile Podcast-Publikum, zu teilen. Also viel Spaß.
Maciek:
[unhörbar 00:00:26].
Tenille:
Maciek, vielen Dank, dass du dir heute Zeit für uns genommen hast.
Maciek:
Keine Sorge.
Tenille:
[unhörbar 00:00:30], kannst du uns sagen, was das Beste war, was du diese Woche gelernt hast?
Maciek:
Oh, das war definitiv bei Melissa Perris Vortrag. Als sie über... sprach Als ob sie für mich davon sprach, langsamer zu werden. Und was wir bei Agile tun, ist nicht nur Lieferung, Lieferung, Lieferung, sondern es geht auch darum, Dinge, die wir bereits entwickelt haben, zu lernen und zu ändern und herauszufinden, welchen Mehrwert wir unseren Kunden bieten können. Es geht nicht nur um Versandfunktionen, es geht vor allem um den Wert. Das habe ich gelernt.
Tenille:
Das ist großartig. Danke. Also, was denkst du wäre die geheime Zutat für ein großartiges Agile-Team?
Maciek:
Demut. Irgendwie sollte die Teamkultur Demut und Fehler beinhalten. Und die Leute sollten keine Angst davor haben, Fehler zu machen, denn ohne Fehler zu machen, lernt man nicht. Das ist was ich denke.
Tenille:
Was wäre also, glaube ich, wenn es eine Agile-Zeremonie gäbe, die jedes Team durchführen sollte, was denkst du, könnte das sein?
Maciek:
Sicher, Retro, und das kommt wieder auf die Fehler und den Lernteil zurück.
Tenille:
Ja. Fantastisch.
Maciek:Keine Sorge.
Tenille:
Das ist großartig. Vielen Dank, dass du dir die Zeit genommen hast.
Maciek:
In Ordnung. Danke.
Tenille:
Prost.
Mädchen:
[unhörbar 00:01:42].
Caitlin:
Gil:, vielen Dank, dass du mit uns gechattet hast. Im Moment sind wir also alle auf der Agile 2022 in Nashville. Es finden viele interessante Gespräche statt.
Mädchen:
Ja.
Caitlin:
Wenn Sie einem neu entstehenden Agile-Team einen Ratschlag geben könnten, welcher wäre das?
Mädchen:
Es wäre, kleine, wertvolle Arbeiten gemeinsam zu beenden. Es hat ein schreckliches Akronym, FSVWT. Es kann also nicht auf diese Weise in Erinnerung bleiben. Erledigen Sie gemeinsam kleine, wertvolle Arbeiten. Es wird viel über Prozesse, Arbeitsvereinbarungen und Tools gesprochen. Das ist alles wichtig, aber manchmal ist es zu viel für ein Team, das gerade erst anfängt. Wenn wir also nur daran denken, kleine wertvolle Arbeiten gemeinsam zu erledigen, ist das eine großartige Geschichte.
Caitlin:
Ja, ich liebe das. Und du warst Redner auf der Konferenz?
Mädchen:
Ja.
Caitlin:
Kannst du unserem Publikum einen kleinen Einblick geben, worum es in deinem Gespräch ging?
Mädchen:
Was in vielen Situationen passiert, ist, dass Technik oder Entwicklung nicht wirklich mit dem Produkt/Unternehmen zusammenarbeiten. Und stattdessen gibt es eine Übergabebeziehung. Aber was passiert, ist, dass es ohne eine kooperative Beziehung wirklich schwierig ist, Agilität aufrechtzuerhalten. Die Leute machen viele einseitige Annahmen. Und im Laufe der Zeit führt die Art und Weise, wie Entscheidungen getroffen werden, dazu, dass die Kosten für Änderungen steigen und die Sicherheit, Änderungen vorzunehmen, sinkt. Und wenn das passiert, wird alles schwieriger und langsamer, sodass die Agilität darunter leidet. Der Kern des Vortrags war also, wie wir zusammenarbeiten können, also sowohl das Produkt als auch die Technik, auf eine Weise, die es uns ermöglicht, die Kosten von Änderungen zu kontrollieren und die Sicherheit zu erhöhen? Es geht also nicht nur um Zusammenarbeit jeglicher Art. Es gibt ganz bestimmte Prinzipien, die befolgt werden müssen. Das nennt man technische Agilität, und wenn wir das tun, können wir langfristig agil sein.Caitlin:
Großartig. Ich liebe es. Nun, vielen Dank und ich hoffe, Sie genießen den Rest Ihrer Zeit auf der Konferenz.
Mädchen:
Ich danke dir.
Caitlin:
Großartig. Danke.
Tenille:
Hallo, Tenille hier von Easy Agile, mit Josh von Deloitte, und wir werden ein gutes Gespräch über Team-Retrospektiven führen. Also Josh, danke, dass du dir die Zeit für ein gutes Gespräch genommen hast. Sie sind also ein bisschen Experte für Team-Retrospektiven. Was sind deine Top-Tipps?
Josh:
Meine Top-Tipps für den Rückblick sind also zunächst, tatsächlich eine Änderung vorzunehmen. Machen Sie keine beobachteten Lektionen. Ich habe gesehen, dass viele von ihnen tatsächlich eine Veränderung vorgenommen haben, auch wenn es am Ende nur eine kleine ist. Die zweite und ein Teil davon ist, dass Sie Ihre Veränderung vornehmen und experimentieren. Etwas, das man messen kann, etwas, von dem man tatsächlich sagen kann, ja, wir haben dieses Ding gemacht und es hatte Wirkung. Vielleicht nicht die Wirkung, die Sie sich gewünscht haben, aber es hatte eine gewisse Wirkung. Der zweite Tipp lautet: Variieren Sie Ihre Rückblicke. Eine Retrospektive, die Sprint für Sprint nach Sprint gleich ist, funktioniert für etwa zwei Sprints, und dann werden Ihre Produktivität und Ihre Kreativität außerhalb der Retrospektive erheblich abnehmen.
Tenille:
Das ist ein ausgezeichneter Punkt. Also, wie erstellt man [unhörbar 00:05:03]?
Josh:
Ich habe viel über sie nachgedacht und recherchiert und Websites wie TastyCupcakes genutzt, aber auch meine eigenen Retrospektiven entwickelt. Ich habe eine Retrospektive gemacht, die auf dem Pixar-Pitch basiert. Es gibt sechs Sätze, die jeden Pixar-Film definieren. Nehmen Sie die Basissätze, wenden Sie sie auf Ihren Sprint oder Ihren PI an und machen Sie einen Retro, und lassen Sie dem Team diese Kreativität, um ein ganzes Filmplakat zu erstellen, wenn es möchte. Regie: [unhörbar 00:05:34], weil es passiert. Die Leute engagieren sich und engagieren sich, wenn man ihnen Alternativen gibt, verschiedene Arten, Retrospektiven zu machen.
Tenille:Das ist richtig. Also für die Teams, die im Moment keine Retrospektiven veranstalten, was ist die eine wichtige Sache, über die sie nachdenken müssen, dass du... Was ist das Wichtigste, was du ihnen sagen könntest, um sie zum Start zu ermutigen?
Josh:
Wenn du keine Retrospektiven machst, machst du keine [unhörbar 00:05:54]. Also sollte ich das nicht sagen. Aber wenn du keine Retrospektiven machst, wenn du wirklich glaubst, dass du absolut nichts zu verbessern hast und du zu 100% zu den Besten der Besten gehörst, was bedeutet, dass du wahrscheinlich bei Google oder Amazon oder Netflix arbeitest, obwohl sie Retrospektiven machen. Wenn du also wirklich glaubst, dass du diesen Unternehmen gleichwertig bist, dann musst du sie vielleicht nicht machen, aber ich bin mir ziemlich sicher, dass jedes Team etwas hat, das es verbessern kann. Und das anzuerkennen und dann zu sagen, wie werden wir das machen? Die Retrospektive ist eine sehr schnelle und einfache Methode, um diese Verbesserungen tatsächlich vorzunehmen und sie in die Realität umzusetzen.
Tenille:
Fantastisch. Großartig. Vielen Dank, dass Sie sich die Zeit genommen haben, kurz mit uns über Rückblicke zu sprechen.
Josh:
Ich danke dir.
Caitlin:
Wir sind hier mit Leslie, der Präsidentin von Women in Agile. Leslie, am Sonntag gab es eine tolle Veranstaltung.
Leslie:
Ja.
Caitlin:
Sprich uns einfach ein bisschen darüber an. Was ist in die Planung eingeflossen? Wie war es, wieder alle zusammen zu sein?
Leslie:
Es war toll, die Frauen in der Agile-Community wieder zusammen zu haben, oder? Unser erstes Mal seit 2019, als alle zu dieser Veranstaltung in Washington DC zusammen waren. In den meisten sechs oder sieben Monaten der Planung hatten wir ungefähr 200 Personen im Raum. Zum Glück wissen wir [unhörbar 00:07:10], was diese Frauen in Agile-Sessions machen, die wir jedes Jahr im Rahmen der Agile Alliance-Konferenzen veranstalten, oder? Wir haben eine allgemeine Eröffnung. Wir haben einen großartigen Keynote, bei dem es sich immer um jemanden handelt, der direkt neben dem Agile-Bereich steht. Wir wollen nicht einfach nur mögen... Wir wollen unsere Weisheit und unser Wissen mit Leuten teilen, die noch nicht zu uns gehören, weil wir das ganze Agile-Zeug auf der großen Konferenz bekommen, wenn wir dort sind.
Leslie:
In diesem Teil bringen wir immer neue Stimmen auf den Markt, was wahrscheinlich eine meiner Lieblingsfrauen in Agile-Programmen ist. Drei Mentees, die mit erfahrenen Rednern gepaart wurden, treten zum ersten Mal auf die Bühne, um ihr Talent und ihre Sichtweise zu teilen. Das ist also wirklich großartig. Und dann eine Art interaktives Networking-Event. Dieses Muster hat uns also wirklich gute Dienste geleistet, seit wir das seit 2016 machen, was ein bisschen beängstigend ist, wenn man bedenkt, dass es schon so lange passiert. Und es ist zu einer großartigen Gelegenheit für die Community geworden, auf globalere Weise zusammenzukommen, weil die Agile Alliance so viele Menschen für ihre jährliche Veranstaltung anzieht.
Caitlin:
Ja, ganz sicher. Ja, es war eine großartige Veranstaltung. Ich weiß, dass wir alle viel Spaß hatten, dort zu sein. Was war Ihre wichtigste Erkenntnis aus der Veranstaltung?
Leslie:
Ich werde zu [unverständlich 00:08:14] interaktiven Netzwerken gehen, die sie mit uns gemacht hat, und uns wirklich herausfordern, unseren Mut in Bezug auf Grenzen und das Beenden von Gesprächen zu stärken. Wir müssen keinen Grund angeben. Wenn ein Gespräch uns nicht nützt oder aus welchem Grund auch immer nicht der Ort ist, an dem wir sein müssen, haben Sie absolut die Freiheit, dieses Gespräch zu beenden und einfach weiterzumachen. Ich liebe die Tipps und Tricks, die sie uns gegeben hat, um das gut zu machen.
Caitlin:
Ja, ja, das liebe ich auch. Das ist großartig. Nun, vielen Dank. Ich weiß es zu schätzen.
Leslie:
Ja. Danke, dass du mich eingeladen hast.
Tenille:
Hallo, Evan. Wie geht's dir?
Evan:
Sehr gut.
Tenille:
Das ist gut. Kannst du mir bitte sagen, was das Beste ist, was du heute gelernt hast?
Evan:
Das beste Zitat, das ich habe: „Politik ist die Währung menschlicher Systeme.“ Richtig?
Tenille:
Beeindruckend.
Evan:
Wenn du also ein menschliches System ändern willst, musst du die Politik spielen.
Tenille:
Fantastisch.Evan:
Was sich beschissen anfühlt, aber...
Tenille:
Es ist so wie es ist.
Evan:
... so ist das nun mal.
Tenille:
[unhörbar 00:09:07]. Okay, nächste Frage. Ohne welche Agile-Zeremonie können Sie und Ihr Team nicht leben?
Evan:
Rückblick. Mit der Retrospektive kannst du quasi alles andere gestalten.
Tenille:
Fantastisch. Das ist wirklich gut. Und was ist Ihrer Meinung nach wahrscheinlich die wichtigste Zutat für einen guten Rückblick?
Evan:
Oh, vertraue. Vertrauen erfordert Respekt. Es erfordert Glaubwürdigkeit. Es erfordert Empathie. Vertrauen ist also genau das, was menschliche Fähigkeiten untermauert.
Tenille:
Ja. Fantastisch. Vielen Dank.
Evan:
Ich danke dir.
Tenille:
Ja.
Caitlin:
Richtig. Wir sind hier mit Cody von Adfire. Also Cody, wie hat dir die Konferenz bisher gefallen?
Cody:
Ich liebe die Konferenz wirklich. Es war großartig. Um ehrlich zu sein, als wir das erste Mal hier ankamen, schien es vielleicht ein bisschen kleiner als wir dachten, aber die Leute hier waren unglaublich, sehr engagiert, was immer großartig war. Und außerdem verwenden viele Leute Jira und Atlassian. So viele wichtige Punkte.
Caitlin:Win-Win für beide, hm?
Cody:
Ja. Immer, immer, immer.
Caitlin:
Sehr gut.
Cody:
Ja.
Caitlin:
Es finden viele interessante Vorträge statt. Haben Sie an einem teilgenommen, der wirklich Interesse an Ihnen geweckt hat? Was ist [unhörbar 00:10:15] -
Cody:
Ja. Ich kann mich auf Anhieb an keinen der Vortragsnamen erinnern, aber sie waren alle unglaublich aufschlussreich. Tonnenweise Informationen. Es scheint, als gäbe es für alles ein Thema, was immer ein gutes Zeichen ist und solche Sachen. Also meine Notizen, ich habe Seiten und Seiten und Seiten von Notizen, was immer ein gutes Zeichen ist.
Caitlin:
Ja, das ist [unhörbar 00:10:34].
Cody:
Also muss ich zurück und [unhörbar 00:10:35] nochmal.
Caitlin:
Ja.
Cody:
Aber es war unglaublich und die Vorträge waren sehr umfangreich, also ja.
Caitlin:
Gut. Gut. Und was ist die eine wichtige Erkenntnis, auf die Sie sich freuen, zurückzubringen und mit dem Team zu teilen?
Cody:
Nun, ich denke, eine der wichtigsten Erkenntnisse für uns war, dass... Ich habe über das Engagement gesprochen, das alle haben, aber eine Sache, die unglaublich war, ist, die Geschichten aller zu hören, ihre Probleme, ihre Prozesse, all das. All diese Informationen werden also ein großartiges Aggregat sein, das wir zurücknehmen und ein besseres Erlebnis mit unserem Produkt und all den guten Dingen schaffen können. Also ja.
Caitlin:Ganz gewiss. Ich liebe es. Ich habe jetzt noch eine letzte Frage an dich. Es macht einfach Spaß. Es ist wahr oder falsch. Wir machen Australien-Quizfragen. Bist du bereit dafür?
Cody:
In Ordnung.
Caitlin:
In Ordnung.
Cody:
Hoffentlich.
Caitlin:
Also, meine Wahrheit oder Unwahrheit ist, sind Wellensittenschmuggler eine Vogelart?
Cody:
Sind Buggy-Schmuggler...
Caitlin:
Wellensittiche Schmuggler.
Cody:
Wellensittiche Schmuggler.
Caitlin:
Eine Vogelart.
Cody:
Stimmt.
Caitlin:
Falsch. Nein.
Cody:
Was sind sie?
Caitlin:
Tachos.
Cody:
Ja. Ja, ich habe einige davon in meinem Gepäck. Also hole ich jetzt die Wellensittiche raus.Caitlin:
Mit deinen Daisy Dukes.
Cody:
Exakt. Exakt.
Caitlin:
Ja. Und Cowboystiefel, richtig?
Cody:
Ja.
Caitlin:
Nun, vielen Dank.
Cody:
Ich danke dir.
Caitlin:
Ich weiß das sehr zu schätzen.
Cody:
Ja. Danke.
Tenille:
Doug, wie geht's dir?
Doug:
Mir geht es großartig. Ich danke dir.
Tenille:
Fantastisch. Nun, erzähl mir, was ist das Beste, was du heute gelernt hast?
Doug:
Ich finde es wirklich interessant zu erfahren, wie unsere Kunden unsere Produkte verwenden, von denen wir noch nicht einmal wussten.
Tenille:
Das ist unglaublich. Hattest du die Gelegenheit, an vielen der Sessions teilzunehmen?
Doug:Das habe ich eigentlich nicht. Ich war an diese Kabine gebunden, oder ich nahm an Besprechungen teil, die schon geplant waren, bevor ich hierher kam.
Tenille:
[unhörbar 00:12:01].
Doug:
Ja.
Tenille:
Das ist gut. Wenn Sie also wieder auf der Arbeit sind, was ist Ihrer Meinung nach die wahrscheinlich beste Agile-Zeremonie, ohne die Sie und Ihr Team nicht leben können?
Doug:
Ich denke, was ich zurück ins Büro bringe, ist nicht so sehr eine Zeremonie. Es ist wirklich aus der Produktperspektive. Ich arbeite im Produktmanagement. Für uns geht es also darum, wie wir erklären können, wie unser Produkt unseren Kunden einen Mehrwert bietet. So viele Lektionen, die wir daraus gelernt haben, dass wir wirklich darauf bedacht sind, sie zurückzubringen und in unsere Wertebotschaft einzubauen.
Tenille:
Fantastisch.
Doug:
Ja.
Tenille:
Danke. Das ist großartig. Vielen Dank.
Caitlin:
Er war einer der Mitautoren des Agilen Manifests. Erstens, wie geht es Ihnen bisher auf der Konferenz?
Johannes:
Nun, ich arbeite hart.
Caitlin:
Ja, gutes Zeug.
Johannes:
Ich genieße Nashville.
Caitlin:
Ja. Es ist cool, nicht wahr? Es ist so anders als das [unhörbare 00:12:46], was passiert.Johannes:
Ja. Ja, es ist gut. Ja. Es ist schön, viele Leute zu sehen, die ich seit einiger Zeit nicht mehr gesehen habe.
Caitlin:
Ja. Ja.
Johannes:
Und dreidimensional sehen.
Caitlin:
Ja. Ja, ich weiß. Ja, das ist interessant...
Johannes:
Es ist da-
Caitlin:
... [unhörbar 00:12:54] und so was passiert.
Johannes:
Ja, IRL.
Caitlin:
Es passiert viel Interessantes [unhörbar 00:13:01]. Irgendwelche wichtigen Imbissbuden für dich? Was nimmst du danach mit, um es mit dem Team zu teilen?
Johannes:
Oh, nun, das ist eine gute Frage. Ich habe hauptsächlich mit vielen Freunden gesprochen, die ich seit einiger Zeit nicht mehr gesehen habe. [unhörbar 00:13:14].
Caitlin:
Ja.
Johannes:
Und da ich erst seit ein paar Tagen hier bin, war ich nicht viel, wenn überhaupt, dort. Um ehrlich zu sein.
Caitlin:
Ich weiß. Nun, wir sind ziemlich beschäftigt mit den Stiefeln, oder?
Johannes:
Ja. Ja. Aber sicherlich sind die Arten von Gesprächen, die hier geführt werden,... Ich habe mir ein bisschen Sorgen um Agile gemacht. Ich will einfach nicht sagen... Ja, ich will es nicht sagen. Aber ich will nicht sagen, dass Agile zu einem Sprungbrett wird.Caitlin:
Ja.
Johannes:
Aber ich denke, es gibt eine Menge Leute hier, die wirklich immer noch die Ideale annehmen und wirklich lernen, tun und üben wollen [unhörbar 00:14:00].
Caitlin:
Ja.
Johannes:
Also ich bin ehrlich gesagt überrascht und beeindruckt und glücklich. Es gibt eine Menge. Es reicht, wenn man sich mehr vom Manifest zu eigen macht und manchmal vielleicht nicht alle Vorschriften, und man kehrt zu den Grundlagen zurück. [unhörbar 00:14:22] -
Caitlin:
Ja. Also lass uns darüber sprechen, über das Agile Manifest, das du erwähnt hast. Ich nehme das an. Was heißt Umarmen? Kannst du das etwas näher erläutern? Wir wissen also, dass wir die Prinzipien haben. Gibt es eine, die Ihnen wirklich mehr auffällt als eine andere?
Johannes:
Nun, meine Welt von dem, was ich zu der Zeit gemacht habe, und ich hatte viel im Verteidigungsministerium und im Wassertransport gearbeitet und meinen eigenen, leichten Prozess entwickelt, wie wir ihn vor Agile nennen. Also für mich ist der wahre Schlüssel... Das hat nicht die volle...
Caitlin:
Vollständiges Manifest, ja.
Johannes:
Aber wenn du auf die Website gehst und oben liest, geht es darum, als würden wir Wege aufdecken, indem wir etwas tun, und ich lerne immer noch, entdecke immer noch. Und ich denke, es ist wichtig, dass die Leute erkennen, dass wir unser Ego wirklich an der Tür gelassen haben. In unserem Geschäft bescheiden zu sein ist sehr wichtig. Das steht vielleicht nirgends in den Prinzipien, aber wenn das Ganze in der Präambel ganz oben steht und die Tatsache, dass wir im Blog darüber sprechen, wie wir diese Dinge bewerten, im Vergleich zum Ganzen... Da ist ein Pendel, durch das man sehen kann, wie diese beiden Dinge kollidieren. Meiner Meinung nach ist es eine der wichtigsten Eigenschaften, die wir anwenden sollten, dass wir bescheiden sind und Dinge als Hypothese betrachten. Zum Beispiel, baut Funktionen [unhörbar 00:15:58] nicht einfach von unten nach oben, wie sucht man nach den Antworten, das möchte ich, dass die Leute das mitnehmen.
Caitlin:
Das ist großartig. Das ist ein toller Rat. Nun, vielen Dank, John. Danke, dass du dir die Zeit nimmst, mit uns zu chatten.Johannes:
Du bist willkommen, Caitlin.
Caitlin:
Ja. Genieß, was [unhörbar 00:16:11] ist.
Johannes:
Ich danke dir.
Caitlin:
Ich danke dir.
Johannes:
[unhörbar 00:16:13] morgen.
Caitlin:
In Ordnung.
Tenille:
Abukar, danke, dass du heute zu uns gekommen bist. Kann ich Sie beide fragen, was Ihrer Meinung nach das Beste ist, was Sie heute gelernt haben?
Avi:
Das Beste, was ich gelernt habe?
Tenille:
Ja.
Avi:
Das ist wirklich interessant. Weil ich oft hier am Stand bin, werde ich an vielen Dingen teilnehmen können. Ich habe also zwei Dinge gelernt, die wirklich wichtig waren. Erstens ist das Easy Agile-Logo ein umgedrehtes A, weil es bedeutet, dass Sie aus Australien kommen. Es ist also in Down Under. Und dann war die zweitwichtigste Sache, über die ich heute gelernt habe, dass wir in einer Sitzung über Soziokratie gesprochen haben und darüber, wie man Experimente mit Experimenten besser machen kann, was sich zunächst etwas komisch anhörte, aber es ging wirklich darum, einen Mini-A3-Prozess durchzuführen. Für diejenigen unter Ihnen, die zugehört haben: Das wurde Toyota angetan. Es ist eine strukturierte Problemlösungsmethode, aber anstatt sie [unhörbar 00:17:02] zu umgehen und das Experiment durchzugehen, zwei- oder dreimal herumzulaufen und dann zu entscheiden, dass das das richtige Experiment ist, machen Sie weiter.
Tenille:
Ich danke dir. Wie stehts mit deiner Zeit?Kai:
Ich war die meiste Zeit am Stand, aber dadurch lernt man viele Leute auf der ganzen Welt kennen. Und eines haben wir wirklich gemeinsam, nämlich den Wunsch, Menschen zu helfen. Und es war wirklich schön, in einem Raum voller Menschen zu sein, die am Anfang ihrer Reise stehen oder schon sehr erfahren sind und ihre Motivation einfach darin besteht, andere wirklich zu stärken. Es war wirklich schön, mit dieser Art von Energie zusammen zu sein.
Avi:
Wir haben wirklich gelernt, dass unsere Freunde aus Australien hier oben genauso freundlich sind wie Sie auf der anderen Seite. Ich habe das Gefühl, wenn du auf diese Seite kommst, wirst du gemein, aber es stellt sich heraus, dass du auch hier oben genauso nett bist.
Tenille:
Nun, das hängt davon ab, wie lange du schon auf dem Flug warst.
Avi:
Oh, genau.
Tenille:
[unhörbar 00:17:44], uns geht es gut.
Kai:
Ja.
Avi: Abukar:
Exakt. Gut.
Tenille:
In Ordnung. Noch eine Frage hier.
Avi:
Sicher.
Tenille:
Was ist deiner Meinung nach die geheime Zutat für ein erfolgreiches Team?
Avi:
Was halte ich für das Geheimnis? Oh, das ist eine wirklich gute Frage. Das ist ein-
Kai:
Er ist der Beste, um diese Frage zu beantworten.
Avi:Das ist etwas länger als ein zweisekündiger Podcast, aber das sage ich dir. Das ist vielleicht keine psychologische Sicherheit, -
Tenille:
In Ordnung.
Avi:
... nur weil Google das gesagt hat und Project Aristotle das zeigt. Ich denke, um ein wirklich, wirklich erfolgreiches Team zu haben, braucht man einen wirklich erfahrenen Scrum Master. Denn zu sagen, dass das Team psychologische Sicherheit hat, ist eine Zutat, es ist nicht die einzige Zutat. Ein starker Scrum Master ist jemand, der wirklich geschickt darin ist, diese psychologische Sicherheit zu schaffen, aber auch bei all den anderen Aspekten hilft, um sich auf eine möglichst positive Zusammenarbeit und Koordination vorzubereiten. Außerdem auf der Suche nach... Ihr Name ist Cassandra. Auf Slack nennt sie sich selbst Kaizen. Kapierst du es? Das ist ein Witz. Aber das ist die ganze Sache, ein wirklich erfahrener Scrum Master hilft den Teams, die Kaizens zu finden, die sie brauchen, um wirklich leistungsstark zu werden. Psychologische Sicherheit macht das möglich, aber das heißt nicht, dass sie die Leistung steigert. Es ist eine Zutat, um das möglich zu machen.
Tenille:
Fantastisch.
Kai:
Es gibt keine bessere Antwort als diese. Lass uns einen Ausruf machen.
Tenille:
Hervorragend. Vielen Dank, dass Sie sich die Zeit genommen haben.
Avi:
Ich danke dir vielmals.
Kai:
Natürlich.
Hayley:
Wir sind hier mit Carey von Path to Agility. Carey, was hat dir an dieser Konferenz wirklich gefallen?
Carey:
Ich glaube, dass mir an dieser Konferenz bisher am meisten gefallen hat, ist die Interaktion mit all den Leuten, die hier sind. Es ist wirklich schön, sich zu treffen, verschiedene Leute kennenzulernen, Kontakte zu knüpfen und die Gelegenheit zu haben, zu sehen, was es sonst noch auf dem Markt gibt. Und dann sprechen wir natürlich über das Produkt, das wir mit Path to Agility haben. Es ist eine wundervolle Erfahrung, hierher zu kommen und alle zu sehen. Und es ist so schön, wieder persönlich unterwegs zu sein, anstatt die ganze Zeit vor einem Bildschirm zu stehen.
Tenille:Ja, absolut. Hattest du die Gelegenheit, an vielen der Sessions teilzunehmen?
Josef:
Ich habe so viel wie möglich versucht, aber es ist auch wichtig, sich die Zeit zu nehmen, um zu dekomprimieren und alles einwirken zu lassen. Also hier haben wir Spaß.
Tenille:
Ja, absolut. Wenn Sie an die Arbeit zurückdenken, was ist Ihrer Meinung nach die eine Agile-Zeremonie, an der Sie teilnehmen und die Ihnen und Ihrem Team am meisten hilft?
Josef:
Ich denke, verschiedene Wege der Zusammenarbeit zu finden, effektive Wege der Zusammenarbeit. Und wie lösen wir in Bezug auf das Arbeitsmanagement einige der Probleme, die wir haben? Es gibt so viele Tools, die das einfacher machen, und das ist etwas ganz Besonderes. Mit Menschen sprechen und herausfinden, wie sie Probleme lösen.
Tenille:
Und was macht Ihrer Meinung nach ein wirklich gutes Agile-Team aus?
Josef:
Nun, man könnte etwas sehr Klischeehaftes sagen, wie sehr anpassungsfähig zu sein und sich zu verändern und so weiter und so fort. Aber ich denke, es kommt wirklich auf die Interaktion zwischen Menschen an. Einander verstehen, sich gegenseitig ermutigen und einfach die Art und Weise, wie man zusammenarbeitet.
Tenille:
Fantastisch. Großartig. Gut, vielen Dank, dass du dir die Zeit zum Chatten genommen hast.
Josef:
Ich danke dir. Es war nett, die ganze Woche mit euch zu chatten.
Tenille:
Prost.
Tenille:
Dan, danke, dass du dir die Zeit zum Chatten genommen hast.
Dan:
Du bist willkommen.
Tenille:
[unhörbar 00:22:54] Fragen. Was denkst du ist das Beste, was du heute gelernt hast?
Dan:Oh, das Beste, was ich heute gelernt habe, ist, dass die Keynote zu den Morgenprodukten ausgezeichnet war. Ich habe ein paar Tipps bekommen, wie man Produktmanagement macht, verschiedene Strategien, wie man die Leute dazu bringt, sich auf das Taktische und Strategische zu konzentrieren. Also nur ein paar nette kleine Nuggets, wie das geht [unhörbar 00:23:12].
Tenille:
[unhörbar 00:23:13], danke, dass du heute zu uns gekommen bist. Kann ich zunächst fragen, was denkst du ist das Beste, was du diese Woche gelernt hast?
Sprecher 17:
Das Beste, was ich diese Woche gelernt habe, ist, dass es keinen richtigen Weg gibt, Agile anzuwenden. Es gibt viele verschiedene Möglichkeiten, dies zu tun. Es geht also wirklich darum, herauszufinden, welcher Prozess für das Unternehmen, in dem Sie tätig sind, der richtige ist, und diese Erfolgsmuster dann zu nutzen.
Tenille:
Nun, ich schätze, gibt es eine Art Agile-Zeremonie, auf die Ihr Team Ihrer Meinung nach nicht verzichten kann?
Sprecher 17:
Das tägliche Standup ist täglich. Ich denke, viele unserer Teams reden den ganzen Tag lang. Sie müssen sich nicht unbedingt so häufig synchronisieren. Ich hatte schon ein paar Teams, sie fallen etwa drei Tage die Woche aus und es scheint für sie zu funktionieren. Die andere vielleicht wichtigste Erkenntnis, die ich gesehen habe, sind Zeitboxen. Also keine Besprechungen von 10:00 bis 2:00 Uhr oder was auch immer es sein mag, und das wirklich aus einer erfolgreichen Perspektive zu steuern.
Tenille:
Ich denke in diesem Sinne, was macht Ihrer Meinung nach ein wirklich erfolgreiches Agile-Team aus?
Sprecher 17:
Die Fähigkeit, miteinander zu sprechen, diese Fähigkeit zu kommunizieren. Da all unsere Teams entweder hybrid oder remote arbeiten, ist es meiner Meinung nach entscheidend, sicherzustellen, dass wir über die Tools verfügen, mit denen sie das Gefühl haben, jederzeit jemanden abholen und mit ihm sprechen zu können. Und viele Leute haben immer noch keine Kameras, richtig, was mich verwirrt. Aber die Fähigkeit, Gesichtsausdrücke zu sehen, von Angesicht zu Angesicht zu sein, war so schön, weil wir das bekommen können. Das ist also der andere Schlüssel, die Fähigkeit, miteinander zu sprechen, als könnte ich die Hand reichen und dich berühren.
Tenille:
In Ordnung. Fantastisch. Tja, vielen Dank.
Sprecher 17:
Du bist willkommen. Danke.
Tenille:
In Ordnung. Rob und Andrew, vielen Dank, dass Sie sich ein paar Minuten Zeit für uns genommen haben. Kann ich Sie zunächst fragen, was Ihrer Meinung nach das Beste ist, was Sie diese Woche gelernt haben?
Rob:Für mich ist es definitiv die schnelle Skalierung von Agile, von der wir heute Morgen erfahren haben. Wir werden es versuchen.
Andrew:
Mir hat die Mathe-Programmiersitzung sehr viel Spaß gemacht und ich habe verschiedene Möglichkeiten kennengelernt, Ingenieure miteinander zu verbinden und zusammenzuarbeiten.
Tenille:
Großartig. Als Nächstes, schätze ich, was macht Ihrer Meinung nach ein großartiges Agile-Team aus?
Rob:
In erster Linie, dass sie mehr als alles andere die Kontrolle darüber haben, wie sie arbeiten und woran sie arbeiten.
Andrew:
Ja. Für mich ist das natürlich eine psychologische Sicherheit und einfach eine gute Teamdynamik, in der sie unterschiedlicher Meinung sein können, aber trotzdem respektvoll sein und großartige Ideen entwickeln können.
Tenille:
Und gibt es eine Agile-Zeremonie, ohne die ein großartiges Team Ihrer Meinung nach nicht leben kann?
Rob:
Wahrscheinlich rückblickend. Ich denke, die Teams müssen sich ständig verbessern, und das ist ein guter Weg, das zu tun.
Andrew:
Einverstanden. Ja. Ja. Ja.
Tenille:
In Ordnung. Das ist großartig. Vielen Dank, dass du dir die Zeit genommen hast.
Andrew:
Vielen Dank. Ich weiß es zu schätzen.



