team - Agile and Scrum Blog

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.

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.

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:

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?
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.
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?
Communicate. Communicate. Communicate. And then again. Communicate. It’s a new way of working so one presentation will not kill it.
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.

Onboarding and Recruiting

It’s important to realize that the employee experience starts already before the day one during the recruiting process. In agile organizations where hard skills and past experience are not that important we often focus on cultural mix, mindset and ability to learn instead. We used to have a hard programming test for our candidates. It was so hard than our regular employee would not pass it. And it didn’t tell us much as what we really need, were people who can collaborate, learn new things fast, and were flexible. So instead, we started to ask them about what are they passionate about, what they did, what they like to do. We changed the whole process to allow people find their roles, not hire for fixed roles. You can imagine how hard it was for recruiting agencies. Give us the position description, how many years of experience they need, master degree, what technologies they asked us. But we didn’t really care. We were looking for flexibility, and people willing to grow and co-create their roles.

Another important aspect is diversity. For team dynamic is good to have a mix of different profiles. For some roles we did MBTI, and TKI during their onboarding to help team understand people’s typical behavior during decision making, and conflicts. And you can be more creative than that. Very agile organizations are often inviting candidates to join them for a day so they can experience how it is to be part of the organization, and also hear from the team perspective, what is the candidate like. Recruiting is like dating. Some other agile organizations are even doing team hiring event, where they invite all candidates for the role – for example ScrumMaster or Product Owner to spend a day together and simulate the typical day. It’s transparent for both sides, and very revealing about the way how they react in different situations. In general contact before the day one is always encouraged.

Onboarding then can start by pair working, where the new person is not only introduced to the processes and products but also to the people and teams. We always have focused on the values and culture during the onboarding. Some organizations are creating a handbook for new employees to share with them who they are, but I believe becoming part of a team and a larger ecosystem and getting a mentor who can help people start is always worth of. It helps new people to create relationships and become integral part of the system. Time invested into people development always pays back.

Time to Change Performance Review and Rewards System

I wrote here about the need of changing the HR in agile organizations. Agile HR helps organizations to adapt their culture to be more creative and collaborative and less control and compete oriented. They are here to create best employee experience from the first contact, through day one, support their growth, motivation, and increasing their value to the organization. And once you embrace such collaborative and creative culture, it’s time to redesign the performance review and overall evaluation process. The individual KPIs created by managers for upcoming year becomes irrelevant as the people are inspecting and adapting not only of what they deliver, but also what their roles are as those are changing depending on the needs. Some organizations are going towards team created and measured goals (like OKRs) but the others are removing any fixed goals with exchange to the radical transparency and strong evolutionary purpose. That’s where we talk about team organizations.

If you are not there yet, any type of the 360s, like Comparative Agility, Agility Health radar etc. can be a good start. It helps to start with receiving feedback and learning based on that. We are shifting from management feedback and ranking to self-assessment, peer-feedback, and coaching for growth with regular check-ins. I remember that the biggest shift happened where we stopped evaluating and started coaching people. Help them to design their own journey. We made organizational goals transparent and let teams and individuals to create their own goals. Together with a strong sense of the ownership, it helped to feed the motivation.

Finally the last step is to change the rewards and bonus system. It’s only possible if you already created a culture based on collaboration, transparency and purpose driven. Removing the detailed positions goes hand in hand with changing the evaluation system. The peer feedback is flowing there and back on a daily basis, most of the teams would be running their regular retrospective to improve, and help each other to grow. Most of the agile organizations are shifting towards higher base salary with no variable part as they realize that money are more demotivating factor at the end of the day. In creative complex world incentives for tasks are not really working. So that organizations are decoupling financial rewards from individual performance. If there is any bonus it’s more at the overall organizational level, split to the teams and allowing them to distribute it themselves, then given by the KIPs evaluations or decided by management. Some organizations go further on and make salaries fully transparent to everybody. Such level of transparency is a good review system as any inconsistency is visible to everyone.

Agile organizations focus on rewarding people behavior, and learning, over just doing your job. They realize that flexible working hours, self-selection of work, unlimited vacation, work from any place on the world, etc. are better motivation factors than your salary and bonus.

It’s all very different world. And it will not shift overnight. So start small, and inspect and adapt from there. The very first step is to get awareness about what culture you have in the organization and what is the desired culture. You might need a good communication, facilitation, and coaching skill to be able to help your organization to reflect that way, but that’s only the beginning. It’s all about changing mindset. Grow that mindset first, the different practices will follow.

In a summary, Agile HR helps organizations to change their culture to be more creative and collaborative and less control and compete oriented – we build organizations around motivated individuals, involving them in co-creating their journey. Agile HR focuses on the best employee experience from the first contact, through Day one, support their growth, motivation, and increasing their value to the organization. It’s not about processes but a different culture, different mindset.

Psychological Safety, Motivation, and Growth

In my previous post, I was writing about the need for awareness of what is happening in the organization. Looking deeper into the culture, safety is a prerequisite of collaborative environments. Without it fear of failure will take over and people stop experimenting and try new things and start hiding behind roles, rules, and processes. The level of psychological safety correlates with team performance – people need to have trust that they won’t be punished when they make a mistake. One of the famous studies done by Google in 2012 on teamwork and team performance – Project Aristotle – identified that psychological safety is the most important for a team’s success. Creating safety is key for motivation and if your environment is not safe enough, no agile can be successful there. Agile and Scrum teams address the safety issue by operating in very short iterations. Even if the entire iteration fails, it’s so short, that it won’t create any huge problem. We can still learn and improve. At the end of each iteration, there is a time to reflect, inspect, and adapt via regular retrospectives. It’s not about being perfect and never fail. But in agile space, we take failure as a good thing – an opportunity to learn.

It’s interesting how some organizations are almost freaking out when they hear about learning through experimenting. I guess they imagine the experiment as something big, like the whole product. No surprise they are afraid to fail the entire thing. But experiments in agile are small and tiny steps. In the nowadays world, there is no clear solution exists. Problems we are mostly facing can’t be analyzed, planned, and delivered according to that plan anymore. The plans are failing. For that, most of our problems are too volatile, uncertain, complex, and ambiguous. In the VUCA world, we can’t just say what needs to be done because we don’t know how to solve it yet. However, what we can do is an experiment, try different options, and learn from feedback. The three pillars of empiricism are transparency, inspection, and adaptation. And empirical process core for an agile environment.

The other interesting shift we are facing in agile organizations is about motivation. Traditionally organizations focused on extrinsic motivation factors where a reward is used as a motivator for specific activities. Already from school, we are stimulating the fixed mindset where people believe their basic qualities, like their intelligence or talent, are given and talent creates success without effort. On the other hand, in agile organizations, we rather focus on intrinsic motivation, where we believe that people do the work because it’s internally rewarding. It’s fun and satisfying. In agile environments, we stimulate the growth mindset where people believe that one can always improve, or exceed their natural talents. Now let’s pause a minute here. How do you motivate people? What is your organization doing? Is it more extrinsic motivation (money, bonuses, gifts, …) or intrinsic factors (purpose, autonomy, environment, …) ? Do we believe they are creative and smart and can learn what is needed from them? Or do we approach them more as machines?

All we need to do is to create a good learning environment, help people to be confident, and deliver continuous feedback. And here is the role of leadership and specifically HR in an organization. Agile HR is here to help create such an environment that is safe to fail, rewards learning, and builds a growth mindset. It seems to be simple, but in reality, it’s often where organizations are failing.

To assess your environment, you can ask a few questions:

Are goals clear to everyone?
Do you believe that the work you are doing matters?
Do you expect team members to take accountability?
Can you trust team members to do their best?
How comfortable do you feel taking risks on the team?
How comfortable do you feel depending on your teammates?

Remember, the level of psychological safety correlates with team performance, so it’s a good place where to start your business agility journey.

Agile Transformation Metrics

It’s very common that people ask me how they shall measure the success of their Agile transformation. It’s a hard question because there is no meaningful metrics unless you know why you decided to start the agile transformation at the first place at all. Agile is not your goal, it’s just a way how to achieve some of your more strategic goals i.e. address complexity better, be more change responsive, shorten time to market, be more flexible, … And once you know why you are starting your agile journey, then those reasons are exactly the metrics you are going to measure at the organizational level. All are business-oriented and value-driven (outcome), so there is no velocity, no story points as those are focusing on output.

If you want to have a fast culture check on how far you have moved towards the agile mindset, you may look into how many experiments the teams are running, what are their actions from the retrospectives, and how they help them to deliver more value, how likely your teams take failure as learning vs. blaming opportunity, how close are they to customers, and how they collaborate vs. work individually or in silos. As a follow-up, you can have a look to your positions (are they rather broad supporting cross-functional teams than detail task-oriented), recruiting (are we hiring for approach and personality over the hard skills), performance review (team-oriented based on peer feedback over the individual), goals and objectives (team-based focused on purpose and outcome over tactical and individual KPIs focused on output), … and I can continue.

Looking to technical practices, you can check how your software teams implemented Extreme Programming practices i.e. Continuous Integration (even one-minute old code is old code), TDD – Test Driven Development (and overall attest automation), if they use pair programming or mob-programming to collaborate, having strong Definition of Done, focusing on one story at a time, and are ready for Continuous Delivery.

All over Agile is about team collaboration, customer-centered value-driven way of working, and short feedback loops. The rest are just practices, processes, and tools which might support your journey or not. The most important is not what exactly you are measuring, but what you are going to change based on that metric. If the metrics is helping you to improve and change your way of working, it’s a good metric. Measuring something just so you have it, or so you can draw a chart is a waste of your time.

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.

Barriers of Agility

In most of the surveys about barriers of agility in organizations, you learn that the top three places are culture, structure, and leadership. There is no surprise. Organizations were designed for a different world where you can analyze the situation, plan what you are going to do, cascade the goals through the organization, and deliver it accordingly with minimum change requests, simply for the predictable world. The problem is that in the last decades the world has become less predictable and changes were more frequent, the VUCA challenges overtake our everyday life reality and the organizations realized they are too slow to respond. Like dinosaurs thousands of years ago. Change is inevitable. Analyzing, planning, and following the plan is not an option anymore.

Innovations, creativity, and flexibility are new norm and organizations which can create environments where teams are self-organized, collaborate on maximizing the business value, and co-creating the organizational goals are taking over positions in the Fortune 100 list. Most of the big corporations are still in the cage of the old-world reality. They optimize for speed. But speed is not that important asset anymore as going fast in the wrong direction doesn’t lead anywhere. Instead, we need flexible environments optimized for creativity. Thinking about flexibility, the organizational structure needs to change to allow it. Departments focused on competences or components, not business value, is meaningless. They kill creativity. Hierarchy keeps responsibility by the managers and prevents people from taking ownership and decide themselves. Again, it kills creativity.

Culturally the traditional organizations are leaning towards competing over collaborating, and controlling over creating. The practices of detailed positions, reward systems, performance reviews, and individual goals and objectives are keeping the organizations in competing and controlling quadrants.

Finally, the leadership needs to change significantly. Traditional organizations were expecting leaders to be Experts or Achievers. Agile organizations need Catalysts. They need leaders who are visionary, purpose-driven, are able to see the business and organizations from different perspectives. They enhance collaboration and are good at building teams and networks. They search for win-win solutions, are good coaches, and helping others to grow. They support running experiments and use failure as learning.

All over we can say that Agile Organization needs different leaders, cultures, and structures. You don’t have to start with changing all of them at once, but sooner or later such change is inevitable. The fewer barriers you give agility on the way, the more likely the frameworks, methods, and practices make a difference and help you to be successful in the VUCA world.

ScrumMaster Mind

Great ScrumMasters are patient, can give space and dedicate their time to help other people grow. They are servant leaders and Catalysts. It sounds simple and not conflicting at first look, however, the real disconnect people feel at first, when they came across the role, is often about their ability to let things go. As a ScrumMaster, you are not responsible for the delivery. As a ScrumMaster, you need to let them fail. As a ScrumMaster, you can’t make a decision for them. “But I need to make sure they deliver the Sprint!” people often say with fear in their eyes. “I need to make sure they are efficient!”, “I need to tell them … ”. Not that quite. Being a ScrumMaster is a very different role than being a Project Manager. They actually can’t be more different from each other. Project Managers are responsible for delivery, they shall manage, make decisions. ScrumMasters are coaches, they help other people to grow. They are facilitators, help the conversation to flow, but don’t interfere with the content. The team is responsible for delivery, the team is responsible for organizing themselves, and the team is also responsible for improving their way of working. ScrumMaster can help them, but not push them. The ultimate goal of the ScrumMaster is to do nothing – or if you wish to build great self-organizing teams.

For example, imagine a team, which is super confident that they are going to finish all the parts they planned for that Sprint. In the middle of the Sprint, you can see from the board that they are not in the middle of the work, not even close. They started many items but didn’t finish much. It seems to you that they are not well organized, abandoning problematic tasks and not collaborating. What are you going to do? When I ask this question at the classes, most people feel a strong need to guide the team, tell them how they shall organize, and when we talk about the fact that as a ScrumMasters they have no power to decide for them, they are very uncomfortable. “But I have to make sure they deliver it”, they say. “I can’t let it go, what my manager would think?”. And it’s very hard for them to accept the fact they can’t push them. They can try their best to coach the team and show them what can possibly happen, but if they are still confident and don’t see that as a risk, eventually you need to let it go and let them fail. Failing one Sprint is not a problem. At the end of each sprint, there is a Retrospective and that’s the time where you can help them reflect on what just happened and come up with action steps on what are we going to the differently next time, so this will never happen again. ScrumMasters are not responsible for Sprint delivery (the team is), ScrumMasters are not responsible for the product delivery (that’s Product Owners job), but they are responsible for making the team self-organized and improving. It’s not that hard as it looks. Try to let things go next time, failure is a good thing. Fail fast, learn fast.

Hierarchy

I recently posted a quote from a conference saying that “Removing hierarchy and cross-team dependencies made space for strong collaborative teams.” Interestingly, I got many comments and questions about it. So let’s talk about hierarchy and why we don’t need it in Agile space.

But before we dive deeper… What is the hierarchy? – using dictionary definition: “Noun – a system in which members of an organization or society are ranked according to relative status or authority.”

Traditional Organizations Need Hierarchy

Organizations where employees are ‘ranked according to relative status or authority’ is what we inherited from the traditional organizational paradigm which is built on top of the belief that hierarchy is the key – every organization needs to have an org chart, we have to have a clear line of reporting and decision making. And I’m not saying it’s wrong, you can keep all the traditional practices like a career path, positions, performance reviews, KPIs, etc. however such organizational design is not what I’m interested in and has nothing to do with ‘being agile’. Traditional organizations might be still well functioning, applying some frameworks and ‘do agile’, but the mindset at the organizational level is just not there yet.

Agile Organizations Are Flat

What I’m interested in is applying an agile mindset at the organizational level. Help not only individuals to ‘be agile’, but the organization as well. Agile is fundamentally changing the way organizations operate. Agile organizations are built on a new paradigm. They have a team as the key building block and are forming collaborative, creative, and adaptive networks from them. In a team, we don’t have status, and we have no ranking either. All team members are peers, with no positional hierarchy and power. Indeed, you can gain respect from the other team members in a team, but you can also lose it if you don’t bring value to the people around you anymore. It’s flexible and dynamic. All you need is radical transparency, peer feedback, and honest culture with implicit trust. You might say it’s a lot, and I’m far from saying it’s easy. However, once you experience it, you never want back to the traditional world.

Who decides on the process? Teams. In a flat organization, they are not only self-organized, but self-managed (so they are responsible for the processes), self-designing (so they are designing teams), and self-governing (so they are setting overall direction). To get more insights on those terms, see how LeSS defines them. All over, you don’t need much more than what I already mentioned – transparency, feedback, and trust. If that’s too abstract, you can get inspired by Sociocracy 3.0. It will give you more ideas on how to get there.

Who set’s the goals and objectives? No one. They are co-created by the teams, reviewed through radical transparency, and inspected and adapted via frequent feedback to flexibly address the business challenges. At the end of the day, fixed goals are useless in the VUCA world. VUCA stands for volatility, uncertainty, complexity, and ambiguity. In other words, we speak about the world which is not predictable anymore. The cascading goals neither unify nor motivate. The more decentralized and autonomous the organizations are, the higher need is there for a strong evolutionary purpose. Co-created and owned by all. Transparent. You can get inspired by Frederic Laloux’s work.

What about budgets? Who says we need to have a budget in the first place. Again, you don’t need much more than what I already mentioned – transparency, feedback, and trust. Make all the finances transparent, and use instant peer feedback to review it. If that is too radical, you can get inspired by Beyond Budgeting.

All over, I guess you got the pattern. In an agile flat organization, we don’t need most of the traditional practices. All we need is radical transparency, peer feedback, and honest culture with implicit trust. No one is saying that you have to turn your organization into a flat structure and an agile mindset. But if you want to do that, be ready to redesign the way you work entirely.