team - Agile and Scrum Blog

The Power of Continuous Improvement

Very often, people are expecting changes to happen instantly. They are impatient, they want everything now. But changes take time and effort. Change is definitely not a straightforward activity; it never goes as you plan it. In order to succeed with change in your organization, you need to be creative, innovative, and playful. And on top of that, you need to be patient. One of the reasons why I like Scrum, is because it’s incremental and iterative not only in delivering the value to the customers, but also in its own implementation. Step-by-step, you are figuring out what does it mean to be agile for us, how to use Scrum, and how shall we implement the different artifacts and events. There is no cookbook, you need to figure out your own way.

At the beginning, don’t look for any perfection, just start with anything that is good enough. You need to have a team that can deliver at least some sort of limited value. A team that has a chance to become at least a bit cross-functional. A team that over the time can take over the responsibility and ownership and become self-managing. Once you have this starting point, a team willing to give it a shot, all you need is to incrementally inspect and adapt. Small, little iterations. Every iteration, you discover what is working and make it stick; each iteration reveals what needs to be improved and comes up with an actionable step for the next sprint to improve it. It doesn’t have to be a big change, quite the opposite. Small steps work generally much better. This way, they’re safe to try and more likely to happen. They don’t look like they can change the world instantly, but if you look back where you’ve been six months ago, you realize you’ve made a huge step.

Overall, I would say, if you don’t take anything out of the Scrum framework but Retrospectives, do them regularly and make sure they bring incremental changes, you end up at a much better stage than you’ve been before. Being agile is about being adaptive. Be creative and take it one step at a time. Play with the change. An incremental change is the key practice that can make you truly Agile. It’s not about tools. It’s a different way of thinking, and incremental changes are a key part of that new way of thinking and approaching things.

Stop Solving

One of the biggest issues ScrumMasters have at the beginning of their journey is to believe that they are here to solve the problems, but this is just wrong. You’re not here to solve the problems, quite the opposite. Your ultimate goal is to create a self-managing team that can solve the problem. Solving is not your job. You’re not a team assistant, you’re not a team mother, you’re a coach who can help your team to take over the responsibility and ownership, so they will make that problem go away. I think that’s the hardest part of being a ScrumMaster. I mean there is a lot. You need to learn all the agile practices, understand Scrum, learn about different frameworks, different techniques, different tools. You need to be good at explaining things, you need to be a coach, and facilitator, and you need to help them be successful.

But I think the most difficult part is to stop solving things. That’s the beginning of your leadership journey. From being an expert to becoming a catalyst leader or agile leader. And here is the problem. If you are not solving things with your own hands, you often feel you are not creating value. You feel redundant. When I started it was not much different for me. I was helping the team with everything I could without realizing I was in their way to becoming self-managing. I never gave them an opportunity to make their own choices nor learn from their mistakes. I was always there to save them. My lack of patience was actually limiting their progress to become a high-performing team.

You are not here to solve anything, ScrumMasters are here to create an environment where people can grow, and take responsibility and ownership for their own journeys. Help them, support them, and let them make their own choices even if that means they can fail. We all learn through failures. Develop the patience to observe and let go. Build the trust they can make it. Soon you will be surprised how great teams emerge from such a trustful environment.

Reinventing Collaboration

The recent shift to the virtual space and home office created a more convenient work-life balance but created very new challenges as well. How to grow talents, how to collaborate, and how to build relationships.

In many cases, people simply went back to individual work. In many organizations, the only time where they see each other is some sort of Standup that looks more like a status meeting where individuals who have their own tasks, share their progress with anyone who is interested which is usually close to no one as the don’t collaborate and don’t have the shared ownership.

Such Standup is kind of an energy killing boring micromanaging practice. So maybe you should kill it as well and give people more time to work on their individual tasks. And when I said the only time ‘they see each other’ I was not that accurate either as in many organizations people are not using their cameras. Now what remains from being agile in such environments? Not much.

Another challenge we are facing is how to grow talents in such an individual culture where people don’t see each other and don’t build relationships with either their colleagues or their customers and stakeholders.

People often ask me about this principle of the Agile manifesto, implying that agile cannot be used in a virtual, geographically distributed world.

“The most efficient and effective method of

conveying information to and within a development

team is face-to-face conversation.”

But why not? It doesn’t say co-located, it says face-to-face or as we call it now video-to-video. So that’s not an issue. Technology is not an issue either as Zoom for example can create a team space where people can connect during the day and collaborate, discuss, share, and help each other. Similarly to the office space where they were in the same (physical) space and collaborate, they are now in the same (virtual) space and collaborate. It’s even easier as they can share screen, move to the breakout room, talk to each other if needed, and leave for lunch and come back after.

I guess the biggest issue is not where you are located but if you are willing to collaborate. Is there a need for teamwork, or is the nature of the business simple enough so they can distribute the work and work individually. If the nature of your work is complex, collaboration in the virtual world is perfectly possible. If you choose to work individually, don’t pretend you are doing Scrum as team collaboration is one of the cornerstones and the only thing that can emerge from that would be a “Dark Scrum”, and that’s neither fun nor functional.

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.