feedback - Agile and Scrum Blog

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.

Collaborative Environment

Speaking of creating the right environment – even in the agile world you sometimes need to make a decision. While that’s not surprising to most managers, it’s often something that agile coaches struggle with. On the other hand, managers often struggle to collaborate and participate, while agile coaches are usually much better at it. All over in an agile environment, you need them both. Decision-making and collaboration.

Decision-making is not that hard once you have a clear purpose of what you like to achieve. But without a clear vision, there are so many options to choose from and the nature of the complex world makes many of them looking good, they all are ok, but it’s impossible to know which one of the right ones, without trying, inspecting, and adapting. And again, the ability to hear feedback and learn from it is critically needed. As in a VUCA world we can’t know which option is the right one, all we can do about it is to experiment and learn from failures. Fail fast, learn fast. There are environments where people react well to what I’ve just said. They understand that it’s better to know you are not going in the right direction sooner than later, they work in short iterations, experiments and get open and honest feedback regularly. They know it’s better to return after a week than when the entire delivery is done in a year from now. Those environments are already agile, they have high trust and are neither afraid of transparency nor failure.

But there are environments where people react with frustration on my sentence. “What do you mean by failing?” they ask. “We can’t fail here!” they say and you can sense the fear and stress growing in the space. “We would be fired if we fail.”. And I’m not surprised. They are living in a different mindset, where they still believe the world is predictable and the business problems can be analyzed, planned, and solutions delivered accordingly. They try to pretend that unpredictability doesn’t exist and that the world is not complex. Just analyze, plan, and do it. That’s it. And all the difficulty is in how to manage it. That’s a traditional mindset and if you like to change it, and increase the agility in a space, you need to start with increasing trust and transparency. Without it there is no real collaboration happening.

In collaborative environments, there are two soft skills needed – coaching and facilitation. You might never be as good at them as professional coaches and professional facilitators are, but be able to use them and help people to raise their awareness about the situation and have an effective conversation and collaborate better is always useful.

Finally agile is a change. Change of the way of working, change of culture and mindset. You can address it at three different levels – changing yourself, through your own behaviors and habits. Becoming a role model. In my mind, this is the most powerful change. Leaders need to change first, the organization will follow. Secondly, you can change the way we work by implementing different frameworks and practices. Thirdly, you can influence the organization and the system level and change the culture and social system.

Employee Engagement

Most of the organizations are doing some employee engagement survey nowadays. Mostly they do it on yearly basis, then it usually takes a few weeks to generate results, so then when they finally communicate the results, no one remembers the situation when they responded anymore, talk about aggregated results and then forget them for the rest of the year. Next year they compare them with the previous year, talk about it for a while and let it go for the rest of the year, and so on. Employees complain it takes so much time to answer that many questions and there is no value in doing so. Not surprising, and not much agile either, right. But how many organizations have agile HR? Not many. So let’s change that. Agile is about regular cycles, fast feedback loops, and continuous improvement. If you apply those principles to the Employee engagement survey, you realize that you may not ask 25 questions every year at the same period of the time, but instead, how about if we run employee engagement in sprints and every week or two ask one question. It cost almost no time to answer that, and you can make the results automatically transparent to everyone right away. They are actual and visible to everyone immediately. Then every now and then, when there is a theme emerging from the results ask the people who care about improving it for input on how can we get better as an organization. Openspace is a great tool to address such challenges, smaller sessions can be organized as world café. Communities are formed on the fly to help organizations address the challenges and come up with ideas on how to change the system, environment, and the way we work. Straightforward and simple.

If you are looking into more theory about Employee engagement the Business Agility Institute brought together a group of researchers to examine general steps and programs that may help boost engagement, present an overview of the many drivers that can impact engagement, and discuss techniques to develop engagement strategies. We’ve shared the highlights below. Read more about Employee Engagement https://businessagility.institute/learn/whitepaper-employee-engagement/.

From Good to Great: Cross-Functional Teams

Next blog in the “From Good to Great” series (Don’t Copy Find Your Own Way, Radical Transparency, Agile Mindset, and Collaboration) is focusing on cross-functional teams. It seems like basics, but I realized that organizations still don’t fully understand why the cross-functional teams are critical to Agile and Scrum success. I guess it is grounded in the fundamental mindset shift, where the organizational focus is moving from functionality driven to the value driven. In traditional organizations, the delivery of functionality was the key. That’s what we focused on and that’s what we measure. It’s the world of allocation and reworks caused by misalignment which all over creates so many dependencies, that delivering end to end feature is a nightmare and takes forever.

Business value

In agile organizations, the focus is changing to deliver business value. And here is the problem. Business value is hard to measure before you get feedback from the customers and users. There is no formula. All you have to do is to get feedback fast and inspect and adapt based on that. And here we are: the cross-functional team is an enabler of fast feedback as there is no way users will give you quality feedback on the backend or one system change while they have a hard time to imagine what does it mean for them. They give feedback on the end to end functionality, that actually often goes across all the technologies and systems in your organization. As such, teams need to be able to deliver value end to end. Otherwise, you are mentally at the manufacturing line where teams work in sequential mode and trying to parallelize this work creates so many dependencies that are making your life hell and preventing teams to focus on the value. They micro-focus on the part of functionality without seeing the whole and the feedback will suffer.

The typical misunderstanding is that cross-functional team means that everyone needs to be expert on everything. But that’s not needed. All we need to have is a team willing to learn and take over responsibility for the end to end value delivery. A team, which can take any item from the backlog (which is end-to-end functionality which brings the value by the definition) and finish it together. They don’t need to take it as individuals, they collaborate as a team. In most of the cases, it’s not that hard in reality once you overcome the initial resistance of team members and the overspecialization mindset of the organization. Try it, and see that I was right :).

Impact

In addition to what has been said, we don’t do functionality because we can, we don’t do it because we believe there is a value, we implement it as we expect something to happen. It is impact driven, strategic approach. And that’s a game changer. In order to be able to measure impact, we need to be able to deliver working product frequently so you can really see how different functionalities changing people behavior. And to do that, cross-functional teams are the essential enabler.

During their agile journey, companies often ask what shall we do if we can’t have cross-functional teams. And the truth is I don’t know, except make it happen. It only needs courage and focus, which are two of the Scrum values after all so nothing new. All over, Agile without cross-functional teams is only empty process, kind of a fake agile where we are using the terminology but not changing the mindset at all.

From Good to Great: Agile Mindset

The next blog in the From Good to Great series which started by Don’t copy, find your own way and Radical transparency is focusing on the most important part of being Agile – Agile mindset. The mindset change is very difficult to describe. People who are far from being Agile are often saying “That’s what we are already doing, so what is this buzz about Agile about?” or “This will never work in reality, Agile is only for unicorns.” But it still exists so I thought I will share with you the picture how I see the Agile mindset change journey now.

Delivery

At the beginning of the Agile journey, it’s all about output. The delivery is the key. People care about efficiency, measuring velocity, estimating effort and complexity using Story points, T-shirt sizes, drawing Burndown charts. “How can we deliver faster?” is the most common question. People want to measure everything. They still believe the work which needs to be done can be analyzed and planned, so they create mini ‘stories’ aka business requirements with all the details specified, often using acceptance criteria to add more details. They also believe that we only need to follow the plan and deliver everything as described as soon as possible to be successful. Nice and simple world. But that’s not what Agile is about so you can freely forget most of the practices mentioned above. They might be better than some others from pure traditional world, but most of them have nothing to do with being Agile. It’s just ‘fake Agile’. On the other hand, most of the people couldn’t learn how to dance overnight, so a bit of ‘fake Agile’ might be a good step towards the mindset change. To be fair there are some aspect teams need to master at this level, mostly going back to the XP (Extreme Programming) like continuous integration, shared code, TDD, regular refactoring, and pair programming or mob programming, but that’s not enough to be agile.

Strategy

The more you apply the agility, and aspects like self-organization to raise empowerment, cross-functionality to be business value driven, and frequent product reviews to be customer-centric, the more your focus turn from delivery to the vision: Why are we doing it? For whom? What makes it different? What is the value? How are we going to change the world? People start to see that delivery is important, but just prerequisite. It’s not about delivering faster (but wrong things). It’s about maximizing value, which actually can be achieved by delivering less than before. The million-dollar question is how can we know this item brings value. The answer is surprisingly simple: Feedback. You can start with the implementation of Scrum. Short Sprints help teams to focus value delivery through defining Sprint Goals, cross-functional teams enable fast feedback from customers through regular Sprint Reviews, and good Product Owner brings decent business knowledge and creates a relationship with the customers so the feedback makes sense. Tools like User Stories and Story Mapping, which are by definition customer-centric value-driven (if used how they are supposed to be) are useful concepts to start a conversation about the business value. At this stage, people believe that if they have a good vision, and understand the customer well, they are going to be successful. Sounds great, the only weak point is that often that’s not enough in nowadays constantly changing the world.

Impact

Finally, the last stage of the Agile mindset change is acknowledging that we don’t know where the value is, we can’t analyze it, we can’t plan it. All we can do is to iterate and inspect and adapt. This stage is finally where we stop pretending we know where the value is, and start heavily experiment. Note, that 80% experiments must fail by definition, so you need to run very small tiny reality checks which are expected to be opportunities for learning. Teams learn fast from day to day failures, always looking for better ways, and when every experiment goes as they expected they take is as an indicator of lack of transparency, honesty and relevant feedback. All over radical transparency is their best friend, empowerment doesn’t stop at the at the team level but goes through the entire organization, and emergent leadership is the key engine to creativity and innovations. The delivery at this mindset stage is needed but is quite unimportant. It’s like walking. You would say you need to walk to get somewhere. But if you don’t know where the ‘somewhere’ is, walking no matter how fast only makes you tired. At this stage, it’s not even about a strategy that much as the strategy is emergent and changes depending on the feedback. It’s all about if the outcome created impact. If you know what do you want to achieve, you can measure if it’s happening. The sooner the better. Gojko Adzic and his Impact Mapping is a good tool to start. As he often shares in his stories you don’t implement functionality because you know how to implement it, nor because someone believes or say it is a good thing to be done. You do it to achieve your goal. If you have any evidence that the impact you need to achieve it is happening, you continue. If not, you stop and find another assumption to test. If you think about it, this is a very different way of prioritization, working, and thinking. That’s the real agile mindset. Once you embrace such a way of working, you are Agile.

I travel and speak at many conferences per year, and often to help them promote their event I draw a picture from some interesting talk. This time I decided to share Gojko’s keynote sketch from Agile Vilnius (#9 to attend this year 🙂 ) here as it is well aligned with my blog post and there is never too little visualization.

Deadlines in Scrum

One of the topics most of the project managers and traditional organizations at the beginning of their Agile transformation journey are struggling are deadlines. How can we do Scrum and commit ourselves to the date when we don’t know the scope? Let’s make this clear. Scrum is purpose driven, not functionality driven. What does that mean? It’s not about delivery, it’s about achieving the certain outcome. And that’s a game changer. Instead of fixing the whole scope at the beginning, we spend the time to understand the purpose. Form a vision. What do we want to achieve? For whom? Where is the value? How are we going to change the world once it’s done? What makes it different?

Once you have enough mutual understanding of the business value and the vision, you are ready to continue. So, we agreed that in long-term, you need to achieve this, what about mid-term? What is the most important to achieve now? Where is the biggest risk we need to mitigate by feedback? What impact do we need to get? Once you have this release agreed, you are ready to start Sprints. Again, Sprint is not about precise functionality delivery, but achieving certain impact, deliver value and learn from that. Therefore, there is a Sprint Goal – a small vision for a Sprint, answering a question what do we need to achieve in the short-term.

Finally, none of those deliveries can actually fail. Of course, you can learn that your business idea was wrong or the value was not where you would expect it. That’s why we use Scrum, to test our hypothesis. But the nice thing is, that neither Sprint nor release can actually fail the delivery if you prioritize well because 80% business value is hidden it 20% of the functionality. If you prioritize the value, you always achieve the goals.

So next time when your customer ask when it’s going to be done, you can invite him in the conversation about the value, vision, release charters, and Sprint Goals. Don’t ask what they want, ask what they need and why. Only then you are both going to be successful with Agile.

Agile Leaders are the beginning of modern management

In order to achieve success at the organizational level, we need to start management talent development program to create leaders who will help to grow a company, make quick decisions and stay ahead of others. Modern leadership style is no longer applying the traditional model of the “leader-follower”, i.e. one decides and the other executes orders. Nowadays, when most employees are from the category of creative workers and the company is looking for innovation and creative ideas to stay competitive, the leader-leader model is a more effective one, where the leaders’ main goal is to help others to be successful leaders. What is modern Agile management or Agile leadership about?

Excellent Agile Leader has four core competencies: Ability to define the vision, motivate, gain feedback, and ability to influence through themselves, others and system.

The ability to formulate a vision is the engine of change and motivation. A vision is not necessarily linked to product and business but should be focused on the organization and its purpose. The second competency is the ability to motivate and give the energy. It is a competence closely related to the vision. If you have a good vision, it motivates itself. Agile leadership builds on so-called internal motivation to strengthen the autonomy of individuals and teams. The third of Agile leader’s competences is feedback. Feedback is DNA component for Agile Organization together with openness and transparency. The art of getting system-level feedback is critical for the leader. The last is the art of influencing complex environments. Change things, people and their behavior, support and consolidate culture. Agile leadership begins with a change of self, your judgments, values, and behavior, style of work. Great leaders start with themselves as a role model, to change the way they show up, how they interact with others, and how they can inspire people around them to collaborate, create a team spirit, and become leaders. They are capable of working with the entire system and influence the whole organization and its culture.

Agile Leader Wheel also defines four supporting competencies to help leaders define the right approach. When is it better to decide and when decisions can be delegated and it’s better to collaborate. At the same time, when it’s better to take a role of facilitator and when start coaching. We do not talk that much about coaching individuals, which of course may be useful, but coaching the whole system – teams and organizations as a whole. Excellent Agile Leaders have not been born as Agile Leaders, but they are constantly looking for new ways to get better and to gain and strengthen the above-mentioned competencies.

Review bazaar

One of the most interesting advanced techniques how to run Sprint Review is the Review bazaar where there is no official Sprint Review meeting, but we run it as a bazaar where different teams are showing their work simultaneously. What’s happening is that each team is creating a space where they show the product to anyone who shows up. They give them opportunity to try the product, touch it, and experience it. There is no presentation, no need to stay if the functionality is not interesting.

Review bazaar is quite advanced technique as organizations are often obsessed about control and centralization is their second nature so it takes time until they feel comfortable enough to let it be decentralized. If we go back to the purpose of the Sprint Review and think about how we can get the best feedback to our product, you realize that it can actually serve this purpose much better than traditional Sprint reviews. However without openness and trust, Review bazaar is never possible.

To make it short list – if some of the following feels familiar…

Your Sprint Reviews are too formal,
People are not giving you a feedback,
Most of your stakeholders coming to the Sprint Review are not interested in every feature so they find the review too long,
Sprint Review is too long,

…you might like to try the Review Bazar. You will realize that it has very different dynamic and the feedback you get if much more valuable.

How to make great Sprint Review

Scrum Reviews have been for a long time left out of our focus. Teams and ScrumMasters are asking how to improve Sprint planning, Standups, Retrospectives, but most of the time there are no real questions related to the Sprint Review. So how to make the Sprint Review great? Firstly let’s review the goal of this meeting which is to get feedback on our product. So no status of done vs. not done Product Backlog Items has any space here. No slides with any Burn-down or Burn-up charts, no velocity comparism.

The Sprint Review shall show real working product to our customers so they can give us a feedback. Yes, to the customers, not Product Owner (note that customers are all stakeholders, users, people who pay for the product, simply anyone both internal and external who has any expectations from that product). Showing the product to Product Owner makes no sense as he is part of the Scrum team and collaborated on the solution during the Sprint.

We don’t present technical solution, but business value delivered and we let team members take the opportunity to show that they did and get the applause :). However, if in some rare cases you happen not to get that enthusiastic feedback, and your customers get angry for any reason, the Product Owner makes himself visible and protects the team. After all it’s his responsibility to understand the customer well enough so those misunderstandings won’t happen.

Your Sprint review is great if you …

Show the real product
Let users experience it
Don’t have any presentation / slides / status
Development team is presenting
Invite real customers / users
Product Owner is most of the time quiet and doesn’t need to interfere