Where Detailed Positions Can Be Harmful

Traditional organizations are based on hard skills. They hire for detailed position descriptions and look for certain experiences, and once you are hired, they evaluate your hard skills and focus on growing them. It’s all based on the presumption that we know what needs to be done. And because we know what needs to be done, we can plan the work and allocate people with needed skills. Such organizations optimize for individual performance and that is usually supported by detailed position descriptions, and it all works really well, until the business becomes unpredictable, and you wake up in VUCA (venerable, unpredictable, complex, and ambiguous) world. That’s where Agile was born and that business shift turned everything around. Positions, way of working, and also the basic assumption that we know what needs to be done. 

So on the contrary in an Agile environment, we realize that we don’t know what needs to be done. The business is changing so frequently that we can’t really plan, the changes are so frequent, the expectations so unpredictable, and there are so many possible solutions that all we can do is inspect and adapt. Experiment and learn from feedback. Late 90s the world was not like that, and nowadays organizations are still created about that old belief. In a modern world, it is very hard to plan which skills we need. Technologies are so dynamic that the only skills we really need are flexibility and fast learning. And then, the more detailed position description you have, the more you are fixing the status quo and are unable to adapt to changes and innovate your business. 

In agile organizations or if you wish in organizations that require a higher level of adaptability because they are experiencing the VUCA challenges, positions are not only not needed but often harmful. Therefore, many organizations widen their descriptions and start hiring generally for team members, and engineers, or just removing positions at all as something that stays in the way of our flexibility, collaboration, and innovations. They form individuals and teams around problems and ask help people to do their best to solve them, even when it requires learning new skills or changing their practices. 

Positions are not always bad, they create a clear path where to grow and what is expected from individuals, but such a defined position often creates boundaries and gaps and limits the learning. “It’s not my work people say. Somebody else shall do it”. But people are smart. When they change jobs, they always learn new tools, practices, and methods. But for some reason we often try to limit their learning by defined positions when they work for the same organization. So if you care about creativity, adaptivity, and agility, forget positions. People don’t need them to do their job. Give them a clear vision and goals and trust them, they do their best. You won’t regret it. 

ScrumMasters Only Make Sense in Scrum

Quite often during the last few months, I heard people being frustrated with not functioning ScrumMasters. One reason for it described in a post Why Some Organizations are Laying of “ScrumMasters” is that those are not the real ScrumMasters, but hiring Scrum “Project” Masters, Scrum “Ceremonies” Masters, or Scrum “Jira” Masters which will neither help organizations to achieve their business goals nor people to feel better or do a better job and as such it can only result in “Dark Scrum”. But surprisingly there is a whole bunch of experienced ScrumMasters who are unlucky enough to be hired to traditional organizations as ScrumMasters to “manage” individuals who only focus on delivery. There is often no intent to change the way of working, managers are trying to keep the status quo and make sure the ScrumMasters have no power to introduce any practice. “You need to ask HR if you like to work with people. Just manage the ceremonies,” they say. I guess I don’t have to say that the whole experience is very frustrating for everyone. Teams are saying the ScrumMaster is not helping them and ScrumMasters burn out very soon. I usually say no to such an environment as they are not ready for a change. Personally, I always try to look for someone who would sponsor a change. If there is no willingness no bigger vision, then why am I here in the first place at all.

However, if I take such an opportunity, you need to start looking at the ScrumMaster role differently. In the first place, ScrumMaster is a leader. And that brings a whole new perspective on his role. As a first step, it’s about the vision, or I would even say a dream. Where do you want to see your organization or team? Why is it important? I rarely do anything because my job description says so, of it was in my KPIs. I did that because I believe that the individual people, team, and organization will benefit from that action. I often fight the system and most of the time challenge the status quo. So that’s where you need to start. Have a strong enough dream that is that you go for it no matter what. Even if you win the lottery, you will be going to work and trying to change things so that your dream becomes true. Sometimes there is a wrong perception that agile is about that sunny smiling environment and no performance. So let me be clear, the first thing you need to start with is business. I often ask organizations before I start helping them with change, implementing agility, or improving their current Agile/Scrum implementation why do you need to change, and they almost always say a number of reasons why is it important – predictability, time to market, customer satisfaction, flexibility, quality, technical debt, innovations, … Then I ask them what happen if they don’t change. Surprisingly, very often they pause and say well, nothing really. We are successful, we earn some money, we are good enough. So in many cases, they don’t feel the sense of urgency needed for a real change. And unless you help them to have a sense of urgency, no real change will ever happen. Can they improve? Yes. Can they adopt some practices? Most likely. But would they change their mindset and their way of working? Not that likely. So if you take a job somewhere, here are a few points you need to take care of.

To start with, answering the following three points is essential:

  1. Why – define business goals. How the organization is going to benefit from a change? Why is it important for us to change? What happens if we don’t change?
  2. Who – define your allies. Changing an organization is never one man show, it’s too complex for that, so create a team. It’s more creative and innovative and will better address the complexity of the system. Create a transformation team that will guide the organization around its agile journey.
  3. What – define your dream together, your vision of the change. What needs to change? What would it look like?

Once you initiate the change, you need to keep going.

  1. Communicate. And when you do so, communicate again. And again. And again. Agile brings very different way of working, different mindset, and different perspectives. Hearing it once is usually not enough.
  2. Remove obstacles. Transformation teams often create a transformational backlog with impediments and things that need to improve. For example, education and understanding, legal and contracts, PR and motivation, but also things like cross-functionality, self-management, individual goals, etc.
  3. Celebrate success. Even a small step is worth celebrating. Don’t forget that. It works for both teams involved and also for the people around who might get inspired and give it a try. Don’t forget that it’s not agile that scales. Success scales.
  4. Keep changing. Agile is about continuous change. Look for small improvements, and change step by step. You never going to be done, but you will always see progress if you look back. So don’t stop changing. There is always a better way.

Top 10 Retrospective Formats

There are so many books, blogs, and sites describing different retrospective formats, but it’s still one of the most common questions I get in the ScrumMaster classes.

When I started as a ScrumMaster, I was only using one format for about two years – and it worked. We got used to it and I learned how to facilitate it and generate meaningful improvements for the team. When I started coaching different organizations, I realized what variety is available and started practicing different formats. I guess that at that time I became more confident with my facilitation skills and stopped being afraid of experiments.

Don’t forget that the goal of a good retrospective is not to complain but to improve so you need to come up with an actionable improvement for the next Sprint. But let’s start with how structure of a good retrospective works. It’s common practice to do some check-in activity, for example by asking “If you are a weather, what kind of weather are you?” to get the focus of everyone. It doesn’t have to be long but it’s a good energizer. Then you explore the possibilities and gather the data so you can reflect. It usually generates too many ideas, so you need to narrow it down to the topics that are most important for the team i.e. grouping, dot voting, etc. Then you explore the most important topic looking for options “What can we do as a team so that this will never happen/improve”. When you generate several options let the team choose what they like to commit to. Too many actions usually don’t stick, and the team will not do them next Sprint, so don’t aim for too many. One improvement is better than many on a to-do list. If you like to get more details on the process check a talk I gave at several conferences.

Now once we summarized the goal and structure of a good retrospective, let’s have a look at my top ten formats.

Retrospective #1 – Plus and Delta

This retrospective format is the foundation most ScrumMasters start with. Team members take turns saying what they like, what they should continue with, and what they like to improve. It’s simple, everyone has a voice, and you don’t need much preparation.
Retrospective

Retrospective #2 – Star

Another popular retrospective format is called star where you expand the classic format of two questions into five segments and let the team look at the given Sprint from different angles – start, more, continue, less, stop. The team usually writes their suggestions on postits. This retrospective format broadens the perspective and usually generates more topics for the team. It is also easier to get the whole team involved as writing is often easier than having everyone speak.

Retrospective #2 – Star

Retrospective #3 – Speedboat

Once you’re bored with classic retrospective formats, try something more playful. I think the most classic is the speed boat metaphor. The wind in the sails represents what helps us, the anchors represent what is stopping us. And there is no limit to creativity in designing the picture. If you let the team design the picture, it will be even more fun. It encourages the team’s creativity and brings up topics that wouldn’t appear in regular retrospectives.

Retrospective #3 – Speedboat

Retrospective #4 – Three Little Pigs

“Three Little Pigs” is a fairy tale about little pigs that build their houses from different materials. The first pig was lazy and built a straw house to play quickly. The second put a little more energy into building the house and quickly built a house out of sticks and ran off to play. The third worked all day and built a house of bricks. The next day, a wolf walked by, smelled a pig through the straw, and was already looking forward to dinner. He blew up the first house, and the little pig just barely managed to hide the second house, when the wolf broke the sticks with one blow the little pigs ran away to the brick house. When the wolf was unable to break it down, he decided to climb into it through the chimney. But the pigs were ready for that, prepare a pot of boiling water and the wolf never returned…

This retrospective uses the story as a metaphor and has the team compare their system and operation to a house made of straw, sticks, and bricks. This retrospective often helps the team identify longer-term stability, sustainability, and technical debt issues.

Retrospective #4 – Three Little Pigs

Retrospective #5 – Mad Sad Glad

This retrospective tries to look at the way of working through our feelings. Team members describe what makes them mad, sad, or glad. As with the previous formats, you can use postits or just let everyone talk. Not everything is rational and measurable, and it’s good to give space to feelings.

Retrospective #5 – Mad Sad Glad

Retrospective #6 – Timeline

Sometimes the team tell you that they don’t remember everything that happened. In that case, you can try drawing a timeline and have them write down the events already during the Sprint. At the beginning of the retrospective, you revise such a timeline and let everyone remember what was happening when the note was written.

Retrospective #6 – Timeline

Retrospective #7 – ESVP: Explorer – Shopper – Vacationer – Prisoner

Sometimes it happens that the team doesn’t work properly, and they don’t want to participate in the retrospective. ESVP format looks at team dynamics and explore individual team member’s attitude. Explorers are ideal team members. They get involved, are active, come up with ideas, take responsibility. The shoppers are a bit more passive, but when they see something interesting, they get involved and ‘put it in their cart’. The vacationers are cool, glad they don’t need to work. They usually don’t get much involved but are not distracting either. The prisoners don’t want to be here and often are quite aggressive. They can poison the entire event.

At the beginning of the retrospective, let everyone where they are. When you find out that you have most people as prisoners, there is no point in continuing the classic retrospective. Instead, try to look for the root cause and how to help them get out of the prison.

Retrospective #7 - ESVP: Explorer - Shopper - Vacationer - Prisoner

Retrospective #8 – Appreciation

Positivity is the key. Research says that the well-functioning teams have a ratio of positive vs. negative events on average 5:1. Therefore in this retrospective, team members will appreciate the contribution of other team members.

Retrospective #8 – Appreciation

Retrospective #9 – Road to the Beach

One of the more creative forms of retrospectives is based on children’s games. It can take many forms, for example, a trip to the beach representing a metaphor of a Sprint where individual members imagine the Sprint as a trip to the beach and begin to describe it. “On the way to the beach a storm comes,” says the first. And another team member continues: “On the way to the beach a storm came, and we got lost and didn’t know where to go.” And another team member repeats what those before him said and adds another event: “On the way to the beach a storm came, we got lost and we didn’t know where to go and the road was wet and muddy…” and so on. Every event in the journey to the beach is a metaphor for what happened in the Sprint. Sometimes the team needs a change, and this retrospective is fun. Everyone has to guess what each part of the way to the beach meant in reality and also be able to remember the whole story.

Retrospective #9 - Road to the Beach

Retrospective #10 – Bingo!

This retrospective format is the most creative. Do you like playing Bingo? Well, that’s good news because you can play it with your team at the next retrospective. Together, the team brainstorms the events that happened within the Sprint either on cards or on an online board. When brainstorming on sticky notes, everyone must write down the same set of events. Everyone builds their own Bingo! board – the cards are the same, but everyone chooses the position of the individual cards themselves. One team member shuffles the cards and reads them one by one. The others mark what has already been said wait for “Bingo!”. The team member that got a Bingo! explains to the others how he experienced the mentioned events. Then the cards are shuffled again, and another person reads. It is a very playful form of retrospective, and it strengthens positivity in the team and shows different perspectives.

Retrospective #10 – Bingo!

Why Some Organizations are Laying of “ScrumMasters”

For some time there was a trend of laying off so-called ScrumMasters from mostly big organizations. At first, it looks like Scrum is over. However, I would be careful with such conclusions. When you look closer, they are not really firing real ScrumMasters but some sort of delivery managers as they often call them or as I described them in my previous blog post – Scrum “Project” Masters, Scrum “Ceremonies” Masters, or Scrum “Jira” Masters. And they are also hiring them for such skills and responsibilities so it is no surprise. Those employees are mostly just pretending to be ScrumMasters. The problem is they often lack agile experience, lack coaching and facilitation skills, are not trained, and their managers often expect them to micromanage the delivery as they were always used to having everything under control. In other words, the environment is still so traditional that without strong leadership, desire for change, and experience in changing organizations they burn out and give up. “It would never work at my organization”, they say.

Indeed without them initiating the change, it will never work. Every change needs significant energy to change the status quo. And one of the responsibilities of great ScrumMasters is to work at all three levels of the #ScrumMasterWay concept:

Firstly, at My Team level, they need to be able to build a team from a group of individuals. Help them to be self-managing and cross-functional so they can deliver value end to end. Explain to them the dynamics of Scrum, facilitate events, and help them to take over the ownership and responsibility for their way of working. Once the initial work is done and the team starts picking up, they need to coach them so they constantly look for improvements.

Secondly, at the Relationship level, ScrumMasters need to work with teams that collaborate on bigger products. Helping Product Owners to shift from a delivery mindset to a value mindset, build a real value-driven Backlog, and prioritize. Facilitating larger refinements with multiple teams, stakeholders, customers, and the Product Owner. Supporting Product Owners to take over the responsibility and ownership for the entire product success focusing on return on investment and customer satisfaction, not just delivery.

Finally, at the Entire System level, ScrumMasters need to help the entire organization to embrace agility. In other words, be more adaptive. Loosen their budgeting the planning cycles, and be ok with uncertainty. Implement a fast feedback loop, and don’t be afraid to inspect and adapt. By increasing the transparency step by step they need to build trust in this new way of working. It’s the only way how to sustain the current world of constant changes and be ready to solve complex business problems. Simply help the organizations to be ready for whatever the future brings.

All over ScrumMasters need to start their ScrumMaster journey at the My Team level. Working with small teams, experiencing what difference can Scrum and agility make at the team level. Learning about the dynamics of Scrum, self-management, and cross-functionality. The same skills and experiences are then applied to larger entities of Relationship and Entire System Levels. They learn on the way.

In order to be successful, large traditional organizations need a certain number of ScrumMasters experienced with the entire system level so they can coach the organization on their agile adoption journey. Hiring Scrum “Project” Masters, Scrum “Ceremonies” Masters, or Scrum “Jira” Masters will never help and can only result in “Dark Scrum” that not only doesn’t help the organization achieve their business goals but demotivates everyone and often results in firing those “fake” ScrumMasters. It’s sad, but it’s quite a common step for traditional organizations on their agile journey. Indeed you can skip it, and hire real ScrumMasters and start changing right away, but for many organizations, it’s too radical approach. They still hope they can be successful in dealing with complexity in nowadays constantly changing world without change. I don’t think so. I believe the change is inevitable. But we’ll see what the future brings, and what organizations will struggle, and what organizations will survive.

The Power of Metaphors

One of the tools I have started using more over the years is a metaphor. Many years ago I was taught the Speed Boat retrospective and tried it with teams. It brought great energy and fun, it helped us to uncover different perspectives. But it never occurred to me that I should take the idea to the next level and use it in other situations. So let’s have a look at different situations where metaphor can be useful.

Organizations are often used to look at outputs, measure effort, and compare velocity. One of the shifts that need to happen is from functionality to business value or in other words from output to outcome. And it’s not an easy shift, especially when the organization is still project-oriented, running on the “fixed scope” mindset. One of the reasons I’m using the metaphor with Product Owners is to shake with their business as usual – we deliver requirements – and reset their thinking about the product. I’m leveraging the Three levels of Reality concept I learned from ORSC and guiding them through the Sentient Essence level by exploring a metaphor, through the Dreaming level where the most collaboration at Backlog refinement is happening, to the Consensus Reality level they are used to by setting goals and objectives. The Sentient Essence level is about feelings it’s the spirit of things. It’s where the purpose is born. And the purpose is often forgotten in traditional organizations.

Three Levels of Reality

Using a metaphor is also a great icebreaker and team building. You see how different people collaborate, how they react to different perspectives, and look for commonalities. It can help teams to create an identity and become a better team together.

It’s also a great tool for ScrumMasters to reflect on where they like to have the team or the entire organization in six months, a year, or three years.

I’m often starting by letting individuals draw some animal, real or imaginary. Depending on the situation I might help them explore that metaphor more to uncover different aspects of it. Drawing is just one way how to visualize the metaphor. You can ask people to describe it, to create a gesture, song, or dance. There are no limits.

For example “We are like a flock of birds, they can fly fast, but not for long. Some got tired quickly and started falling down but the others continued without noticing. They are strong, they have great eyes, but once they start the journey they don’t like to change the direction.”

Then we compare the individual drawings, looking for similarities and uncovering the differences. And start integrating different perspectives into a coherent picture. It’s different than talking about numbers, goals, and objectives. It brings energy and creativity and I would encourage you to try it. Let me know how it worked for you.

Hiring ScrumMaster?

One of my biggest passions in the agile space is developing great ScrumMasters and helping them to become successful in their role. I become ScrumMaster in 2005 and I didn’t know much about either Agile or Scrum. I did all the mistakes you can ever imagine. I didn’t know anything about coaching or facilitation. Instead of acting as a leader, I was more like a team mom. Later, when I realized the whole potential of the role, and become the real ScrumMaster I decided I need to give back to the community and I dedicated quite a lot of effort trying to explain to individuals and organizations what is ScrumMaster really about and why is having great ScrumMaster related to the success of the agile journey. But no matter how long is this all Agile and Scrum around, despite the effort, there are still companies who are hiring ScrumMasters who cannot be successful. So let’s have a look at the most common misunderstandings.hiring a ScrumMaster for failure

Scrum “Project” Master

Deadlines are important. So let’s tweak the role a bit and hire a combined role of “Project Manager/ScrumMaster”, “Agile Project Manager” or “Agile Delivery Manager”. They are experienced in planning and making sure we keep up to speed and follow the plan. They usually manage the Sprint Backlog and often micromanage individuals.

Scrum “Manager” Master

We have to be efficient. We need to deliver more functionality faster. Speed is the key to the success. So let’s have the “Scrum Manager” to help people organize. Someone needs to allocate tasks and measure that they are working and not pretending or hiding behind the Scrum process. Someone also needs to check the progress at Daily Scrum. Someone has to make sure there are results. Such environments often take velocity as a key metric and ask Scrum “Manager” Master to create Burndown charts and other reports.

Scrum “Technical” Master

Many organizations are missing traditional Team Leaders. A senior technical person who will guide the rest of the team members, distribute their tasks, helping the Product Owner with the estimates. Decide on the Sprint commitment. So here we are Let’s hire an expert – Scrum “Technical” Master.

Scrum “Ceremonies” Master

This is my ‘favorite’. We have a Scrum Master to make sure the ceremonies are happening. It’s not a valued position as it downgrades into a team assistant who needs to schedule and manage meetings. Therefore it’s not much popular and most organizations would combine it with a developer/tester/business analyst role. In some cases, it turns to “Scrum Police” as the only explanation they are able to come up with is that ‘Scrum defines it this way, follow the rules’.

Scrum “Jira” Master

This is very typical nowadays. ScrumMaster needs to know Jira, update it on regular basis, and generate reports. Such ScrumMasters are often micromanaging individuals, adding complexity through difficult workflow and complicated processes. They are focusing on various different estimates, at the story level using story points which they often link to man days and hours at the task level which are being re-estimated every day to be accurate.

Scrum “Owner” Master

It’s a waste of our time to have two people when in the traditional world we only had one project manager. ScrumMaster can act as a Product Owner at the same time. In their mind, ScrumMaster is some sort of process assistant for 10-15% anyway so why not. Such a person usually doesn’t have enough business knowledge and ends up being a requirements seeker, not looking for value, and not deciding on priorities. They take a backlog as a to-do list where everything needs to be done.

Scrum “Flock” Master

Finally, some organizations have one ScrumMaster for many teams. No matter how experienced are they, they usually burn down. They don’t have enough time to focus on all teams, so they end up being everywhere and nowhere, and therefore their impact is very limited.

Maybe you find yourself in multiple dysfunctions at the same time. That often happens. But no matter how different they are, they all share one common outcome. They don’t work and you end up with “fake Scrum” or even “Dark Scrum” and no ScrumMaster.

So what’s the real ScrumMaster role about? For the beginning, you can start with the assessment below. Take it as just a start. There is more to be a great ScrumMaster, but if you have the following top 10 points right, you are at a great place already.

  1. My primary measure of success is team self-management
  2. My team is continuously improving their way of working
  3. There are no roles in the team
  4. The team is cross-functional and able to deliver end-to-end value
  5. We measure value, not an effort
  6. I can coach and facilitate conversations and collaboration
  7. I’m not responsible for a delivery
  8. I’m able to work at all three levels of the #ScrumMasterWay concept (My Team, Relationships, and Entire System)
  9. I’m a leader, helping others to grow and supporting organizations on their agile journey
  10. I love Agile and Scrum, and I’m an active part of the Agile community

If you are interested about a real ScrumMaster, check out my book The Great ScrumMaster: #ScrumMasterWay.

Agile is a Change

It’s more than 20 years since Agile Manifesto and some organizations still take Agile as another process or tool. But it can’t be farther from reality. We try to explain that it’s not about “doing” agile but “being” agile. That it’s about changing the way of working and thinking, the overall mindset. But companies are often looking for shortcuts and searching for simple solutions. Rename some processes, create a new role, or buy a different tool. Though that could be useful, it’s not the core of the change.

But let’s start with who should be driving the transformation and who should be implementing Scrum in the organization. Surprisingly for many people, it’s not some manager but someone who has their own experience with agile, scrum, self-management, and end-to-end cross-functional teams – the ScrumMaster. Indeed that person should be an experienced agile coach who is ready to demonstrate leadership and take ownership of a change, working at the Entire System level of the #ScrumMasterWay concept.

There are many concepts that they should be familiar from System Coaching (i.e. ORCS) to classical change management i.e. (Kotter’s Eight Steps of successful change). But in a nutshell, you can start a change with the following steps:

  1. Why – create a sense of urgency – Why is it important to the organization? What will happen if we don’t change? Unless you can create a sense of urgency, the change is unlikely to be successful. Do others see it the same way? Do they feel the same need?
  2. Who – find your allies – Identify the supporting team that will support you and helps you to implement the change. It can be the group of ScrumMasters, but it’s not limited to this group. You are looking for enthusiasts who would be willing to invest their time and name into promoting the change.
  3. Vision / Dream for a change – Do you have a dream of the future? In a year from now, where would you like to be with this organization/group/team?
  4. Communicate. Communicate. Communicate. And then again. Communicate.  It’s a new way of working so one presentation will not kill it.
  5. Celebrate success – don’t forget that it’s not processes and practices but the success that scales. Make it visible and don’t forget to celebrate each successful step. Instead of focusing too much on what we are struggling with, start with what is working well and make sure it sticks. The rest will be improved step by step.

Top 10 Agile Podcasts

Lately, I realized that people start listening more than reading and that podcasts become quite popular. So here is a list of my personal recommendations on top 10s agile podcasts.

#1: The #AgileWay Podcast by Zuzana Zuzi Sochova

#AgileWay podcast is exploring challenges organizations face on their agile journey. How to become a great ScrumMaster, how to change your leadership style, or how to embrace agility at the organizational level. Zuzi has also Czech language podcast “Jsme Agilni”.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/agileway/id1555101534

#2: LeSS (Large Scale Scrum) Matters Podcast by Ben Maynard

The LeSS (Large Scale Scrum) Matters podcast guides you through a proper understanding of how to use Scrum with multiple teams. Ben invites practitioners from the LeSS community to share their experiences with scaling Scrum.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/less-large-scale-scrum-matters/id1605120218 

#3: (Re)Learning Leadership Podcast by Pete Behrens

(Re)Learning Leadership podcast is facilitated by Agile Leadership Journey founder Pete Behrens. The current ways of leading are failing to meet the challenges of our disrupted workforces. Today’s leaders have a choice between adaptation or atrophy: are you ready to evolve your mindset and accelerate change within your organization?

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/re-learning-leadership/id1551181774

#4: Relationship Matters Podcast by CRR Global

The Relationship Matters Podcast  We believe Relationship Matters, from humanity to nature, to the larger whole. Beyond Emotional Intelligence (relationship with oneself) and Social Intelligence (relationship with others) is the realm of Relationship Systems Intelligence where one’s focus shifts to the relationship with the group, team or system. This podcast is not specifically about agile, however in agile world relationship matters.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/relationship-matters/id1507583306

#5 The Collaboration Superpowers Podcast by Lisette Sutherland

The Collaboration Superpowers Podcast by Lisette Sutherland focus on remote work. Recently the remote work becomes a necessity, but not many organization knows how to make it healthy, effective, and collaborative space. Lisette Sutherland, one of the most experienced people about remote work I know,  is interviewing people and companies doing great things… remotely! These interviews are packed with stories and tips for those whose business models depend upon successfully bridging distance to accomplish knowledge work.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/the-collaboration-superpowers-podcast/id931999061

#6: The Agile Book Club Podcast by Justyna Pindel and Paul Klipp

The Agile Book Club by Justyna Pindel and Paul Klipp is a podcast about books. Agile books. Every month, Justyna and Paul review a different agile book, sharing our thoughts, elevator pitches for the books, favorite quotations, and key takeaways.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/agile-book-club/id1465706071

#7: Agile Toolkit Podcast by Bob Payne

The Agile Toolkit Podcast by Bob Payne is one of the first agile podcasts, interviewing agile community about agile software development, methods, tools, and business agility.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/agile-toolkit-podcast/id78532866

#8: Scrum Master Toolbox Podcast: Agile storytelling from the trenches by Vasco Duarte

The Scrum Master Toolbox Podcast by Vasco Duarte interviews Scrum Masters and Agile Coaches from all over the world to get you actionable advice, new tips and tricks, improve your craft as a Scrum Master with daily doses of inspiring conversations with Scrum Masters from the all over the world. Some of the topics we discuss include: Agile Business, Agile Strategy, Retrospectives, Team motivation, Sprint Planning, Daily Scrum, Sprint Review, Backlog Refinement, Scaling Scrum, Lean Startup, Test Driven Development (TDD), Behavior Driven Development (BDD), Paper Prototyping, QA in Scrum, the role of agile managers, servant leadership, agile coaching, and more!

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/scrum-master-toolbox-podcast-agile-storytelling-from/id963592988

#9: Bridging Agile and Professional Coaching Worlds Podcast by by Tandem Coaching Academy

Bridging Agile and Professional Coaching Worlds is a podcast with focus on anything and everything coaching – from Agile to Professional. We bring you the best of the best from the Agile and Professional coaching world, building that bridge between the two. We envision the future where Agile world embraces professional coaching skills and competencies, bringing them closer together.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/bridging-agile-and-professional-coaching-worlds/id1499503189

#10: The Working Genius Podcast with Patrick Lencioni

The Working Genius podcast by Patrick Lencioni is designed to help people identify their natural gifts and find joy and fulfillment in their work and life. What type of work makes you thrive? Are you burning out because your job requires you to work in your areas of frustration? How can teams and families better tap into one another’s gifts? This podcast answers all these questions and more. This is another podcast that is not agile by focus, but quite relevant in agile space.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/the-working-genius-podcast-with-patrick-lencioni/id1553105854

Other great podcasts recommend by the community:

There are many more. Let me know if there is a podcast you like missing and I’ll add it here.

who is agile?

Who is agile? is the video edition of the leanpub e-book of 2010. A book of personal reflections on journeys where people stumbled on agile.

Agile Amped Podcast – Inspiring Conversations

The Agile Amped podcast by Accenture | SolutionsIQ is the shared voice of the Agile community, driven by compelling stories, passionate people, and innovative ideas. Together, we are advancing the impact of business agility.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/agile-amped-podcast-inspiring-conversations/id992128516

Agile FM: “The Radio for the Agile Community”

Agile.FM by Jochen (Joe) Krebs interviews interesting agilists and bring their stories for a few years already, recording at many conferences. They cover a wide range of topics, for example Scrum, Kanban, Lean, Extreme Programming, CSM, PSM, Product Owner, Communication, Leadership, Agile Transformations and Cultural Change.

Listen on Apple Podcasts: https://podcasts.apple.com/us/podcast/agile-fm/id1263932838

A day in the life of an Agility Enabler

A day in the life of an Agility Enabler podcast by Jesus Mendez helps with building the next Agility Enabler’s generation in Montréal, Canada. Highlighting talented Scrum Masters, Agile Coaches and Agile Leaders from the Lean/Agile Montreal’s community, it intends to reveal what a day in the life of an Agility Enabler looks like and to help the audience with discovering the human being behind the Agility Enabler, its personal story, challenges, successful stories, tips, tricks and many more.

Listen on Apple Podcast: https://www.listennotes.com/podcasts/a-day-in-the-life-of-an-agility-enabler-tEmuaAecxbf/#

Appreciation

It’s the end of the year, and that’s always a good time to reflect back. So how about if you do a very different retrospective this time, and instead of focusing on improvements talk about some great things which happened this year. What did you change which helped you to be a better team? What made you happy? What do you appreciate about your colleagues?

You can say it directly, print the cards, use the images in a Mural template where people can fill them in, or design your own cards. It’s not about the form, nor tool. It’s raising the positivity of the space, showing others your appreciation. Great teams do that regularly. Great organizations do that across the teams and departments. You might be one of them, and this suggestion would feel like nothing new. However, too many organizations are busy to stop for appreciation. They need to deliver, work faster, achieve the goals. If that feels like your environment, break your habits, and introduce more positivity, more appreciation. Not only before the end of the year but regularly. It will bring the results soon.

Failing Fast

To my huge surprise, I realized that the concept of failing fast and learning from failure is difficult for some people to accept. They always feel the frustration when I say that ScrumMaster needs to feel comfortable to let the team fail so they can learn. I wrote about it here a few times, so you most likely know it, but the goal of a ScrumMaster is to make teams self-organized. They are not their assistant nor their mothers (as it might end by being dependent on a ScrumMaster), they are not their managers (the team is self-organized, fully responsible for their decisions), ScrumMaster is a coach, facilitator, helping the team to take ownership and realize they can solve most of their problems by themselves. And with every decision you take, there is a responsibility going hand in hand, and risk that you might fail. It is OK to fail if you learn from it. So ScrumMasters are not responsible for preventing failure, but for making sure the team will learn from it and figure out how are they going to work differently next time, so it will never happen again. And that’s very different from what the project managers have in their job description. And here is why – Project Manager is responsible for making decisions, ScrumMasters is not. It’s either the Development team (for how are they going to organize themselves to maximize the value towards the Sprint Goal), or Product Owner (for maximizing the value, prioritizing the backlog, and achieving the overall product success including the return on investment).

Agile is about safety to experiment and learning from feedback. In the VUVCA world, you never know what is the right functionality which will multiply the value and success. You need to inspect and adapt. Learn from failures. Be ready to respond to changes and be flexible to shift the direction based on feedback. Scrum has it all. Short Sprints which make it safe to fail, Retrospectives which ensure fast learning, Sprint Reviews which create a platform for frequent customer feedback, and Product Owners who take care of maximizing value and return on investment. It’s one thing to read it, and another to live it. What happens in your body if you hear “Your Sprint just failed.” Is it closer to the panic and looking for who to blame or is it closer to being curious and excited to search for improvements? It’s a simple question that indicates the level of agility. Failure is a good thing. All you need to do is learn from it.