Author: Zuzi Sochova

10 Most Common Mistakes of Product Owner

Being a Product Owner is not simple. At the end of the day, Product Owners are responsible for the overall Product success. They need to have business knowledge, authority and time. But let’s have a look what are the typical mistakes of a Product Owner as this is one of the very common questions at the classes and learn from that perspective. Here is the list:

Doesn’t Have a Vision

Without a clear vision, there is no direction, no way Product Owner can prioritize, and no Scrum. It’s just a mess where all we can do is to say “everything needs to be done”. The key responsibility of the Product Owner is to have a vision and be able to share it with everybody. Agile organization is about having an evolutionary purpose. If you don’t have it, why are you even here? Similarly to the vision, we have a Sprint goal in Scrum. Without it, everything seems like a good idea to do in Sprint. Sprint goal helps us focus on the need, the real business value.

Can’t Say No

There is no way you can do everything. There are so many options in a complex world. So much functionality customers can ask for. The Product Owner who says yes to all wishes from the customers will fail as the quantity will burn out the organization. Instead, Product Owners are prioritizing based on the business value, and as 80% of value is hidden in only 20% of the functionality, they need to say no quite often during their prioritization.

Doesn’t Have the Business Knowledge

Business knowledge is wider than just a product understanding. It covers the understanding of customers, the market, and the competitive landscape. Without such deeper understanding, Product Owners can’t make a decision and are drafted by different stakeholder groups into their politic fights and the products are usually failing to deliver the real value. Product Owner doesn’t have to be technical, but the business knowledge is critical to their success.

Can’t Prioritize

Product Owner who believes everything needs to be done is not a Product Owner but customer or stakeholder. Prioritization is key in Scrum, at any time you shall know what is more important than the rest and what are we going to invest our energy (effort and money) into next and the rest later or never, depending on the feedback and impact we achieved by the value delivered. There is always more functionality which can be implemented. But maybe that little we already did is good enough for now and we can focus on some other more important areas. As I said already, 80% of value is hidden in only 20% of the functionality. There is no need to implement 100% of the ideas you have.

Don’t Have Negotiation Skills

The Product Owners without negotiation skills are very weak Product Owners. They often end us accepting everything customers ask for and are struggling to say no. Negotiation skill help Product Owners to understand not only what the users want but also what they need. Ant that’s the key part of the prioritization.

Estimates are the Key

Product owners who focus too much on estimates are mentally tight to the functionality, not the business value. In the traditional world, the estimates are important as all we care about is delivery, and we need to deliver more. In the Agile world, it’s not about delivering features. It’s about achieving certain business value. And those two have often only very little in common.

Doesn’t experiment

Product Owners who believe they can create a plan (in agile called Backlog) and then step by step execute it with the development teams during Sprints are not real Product Owners. Backlog can’t be farther from a plan and an iterative approach of delivery is here to inspect and adapt and learn from experiments. Find out where is the real value. The approaches like Lean Startup are quite useful here.

No Impact

As we said, Product Owner shall be able to run experiments. In a way, every backlog item is an experiment where you expect something will happen as a result. That’s the impact. Without knowing why you invest team time and energy into it, why to do it in the first place? Running an experiment without knowing how are you going to evaluate it is silly. That’s not an experiment but functionality you plan to deliver no matter what. Why? Because it’s important. Because I said so. Instead, spend more time identifying the impact so you know why you do it and what you expect to happen. Tools like Impact Mapping are quite helpful here.

Multiple Products

Or shall I say systems, or projects? Because product definition is much wider than that. Product Owners taking care of multiple product don’t have focus, and often don’t have time. Considering Product Owner is the person responsible for the overall product success including the return of investment, it’s quite useful to have the focus for making the product successful and don’t switch the context all the time.

Not Part of the Team

Product Owners sometimes feel they don’t belong to the team. They act as Backlog managers, telling the team what to do, and then waiting to get results/blaming at the end of Sprint. Instead of that, Product Owners are part of the Scrum team, they are team members, they shall collaborate with the team on delivering the value and achieving the Sprint Goal. They are part of the team.

10 Most Common Mistakes of ScrumMaster

Great ScrumMasterBeing great ScrumMaster is a journey, where you have to learn a lot about Agile, Scrum, coaching, facilitation, change, business agility, technical practices, leadership… But all over it all starts with having the agile mindset. This time, I’m not focusing on who you need to be, but quite opposite what you should avoid, as one of the very common questions at the classes is what are the most common mistakes of ScrumMaster. So here is the list:

Being a Team Assistant

Taking care of the team, solve issues (impediments) for them, plan meetings… It’s easy to get there as it seems to be helpful. But only in the short term. Long-term, it will create unconfident people who rely on ScrumMaster and never take over responsibility and ownership. Instead, you shall show them they can solve most of their problems by themselves, and be a good coach, facilitator and servant leader.

Share ScrumMaster Role with Another Role

Such ScrumMasters have usually lack of focus. They don’t spend enough time observing, finding better ways for the team to become great, and are happy and done with the role once everything is ok. Instead of sharing ScrumMaster role with another role, have ScrumMaster full time, let them focus on how they can become great ScrumMasters and truly master the agility so it will help the entire organization. Give them space to invest more time to the other levels of the #ScrumMasterWay concept.

Team Only Focus

Speaking about #ScrumMasterWay concept, many ScrumMasters believe that their only role is to support their development team to be great. I mean this is fine, but it’s just a tiny part on the ScrumMaster journey. It’s like a kindergarten. You need to experience it. That’s where you learn and practice all State of Mind approaches, that’s where you get confidence in yourself as a leader and change agent. But even if you are super successful, it’s only changing at the team level. You need to go broader and follow the other steps of the #ScrumMasterWay model and change the entire organization into an agile organization.

Technical Expert

Being a technical expert is dangerous for ScrumMasters. They feel a strong need to advise people on what to do. If you know a better solution, it’s just easier to tell them, then help them to figure it out. Instead, ScrumMaster shall trust the team they are the experts and coach them so they become better.

Manage Meetings

ScrumMaster is neither manager of the Scrum meetings, nor responsible for scheduling them. Instead, ScrumMaster shall be a facilitator, who takes care about the form of the conversation, not the content.

Don’t Believe in Scrum

How many times you’ve seen ScrumMaster who is doubting about the core Scrum so much that no one is following them? You need to be sure it works, need to believe in it, need to be the biggest Agile enthusiast all around. Otherwise, you can’t make the others to follow.

Apply ‘Fake Scrum’

Sometimes ScrumMasters take Scrum as just a process, don’t search for deeper understanding. Just do it (Daily Scrum, backlog, ScrumMaster role, …) as Scrum says so. They don’t have the right mindset. Agile and Scrum is not about practices, it’s a different way of thinking. It’s about “being” not “doing”.

Waiting for Someone Else to Start the Change

ScrumMasters often wait for someone else to initiate a change. They are reluctant to take over responsibility and ownership and the organization is not moving anywhere. Instead of waiting forever, ScrumMaster shall be a change agent, responsible for the entire organization Agile journey.

Scrum and Agile Expert

It’s enough to understand Agile and Scrum. Which is simple so we are done. Being ScrumMaster is a journey, and you can never stop learning. Even if you feel you know Agile and Scrum, there is always something new. And there are those other domains you need to master: coaching, facilitation, change, business agility, team dynamics, technical practices, leadership, … The learning is never ending.

We Are Great Team, We Are Done.

Often ScrumMasters let their team believe they can be done. The team is good, we finished our Agile transformation. Don’t bother us with new ideas. We know how to work. We are self-organized. You can never be done in a complex environment. There is always a better way. So instead of this false believe, ScrumMasters shall coach the team so they see other opportunities to inspect and adapt.

Do we need CEO in Agile Organization?

Agile at the organizational level changes everything. I wrote here already about Agile HR, Agile Board of Directors, and Agile at the Executive Team Level. Let’s have a look at the top of the organization. Should it remain the same? Or shall we go one step further and change it as well?

Searching for an “agile mindset CEO” is frankly a nightmare. Everyone who tried it can confirm that. There are not many CEOs with enough Agile experience yet in the world and those few who has it are not likely looking for a job as they are usually quite happy in their current organization. So, no matter which executive search firm you choose, or what you write to the position description, the search firms are no real help here. Unless you already spent effort up front on growing the talent internally, you need huge luck to get someone who understands agile more than a basic theory. No matter how desperate you are searching for a CEO, this is still just a small obstacle, not the real reason for a structural change.

The real need for top-level change starts when most of the organization is having an agile mindset. The Agile transformation is about being agile. How many times you’ve heard this request: “How about if our management give us more support on your Agile journey?”, “How about if our executive team is Agile and don’t just push it to us?”, “How about if they practice the same way we work as well?”Would that make it a difference? Maybe. So why don’t we go one more step ahead and change from the top and become a role model for the entire organization? As the organization has changed and Agile is not solely the domain of the IT anymore, but the business agility got into every department, the need for a change at the top level is inevitable. Why do we need a CEO in the first place? Just because that’s how organizations always been? Shouldn’t we ‘eat our own lunch’ and change the way we work entirely? Shouldn’t we apply the same principles the team do? Sounds simple, right.

And as usually it is simple to understand, hard to do as it needs courage. Courage to say “We are going to be different.” We will have Organizational ScrumMaster and Organizational Product Owner instead of a CEO because it will be closer to the way we work at this organization, fits our values, and last but not least we believe it will help us to be more flexible and adaptive at the organizational level. And that’s worth of trying.

The Organizational ScrumMaster would be focusing on the right culture, mindset and structure, so we become high-performing innovative organizations which embraced agility, and Organizational Product Owner would be focusing externally to the business, vision a purpose to we know where are we heading and why and are value driven. Both roles need to respect each other and be open with each other, the same way as it is in a single Scrum team, as together they will be part of the Organizational Leadership Team, and the network structure of self-organizational teams. There are two roles in Scrum by a reason instead of one. When you ask people if they would suggest to combine them, no one feels it is a good idea. And at the top organizational level, we would still do it? The similar reasons are valid at this level as well. When you think about it, it fits the way we work much better, then a single CEO – supports the right organizational mindset, transparency, and collaboration, it is consistent with who we are.

From a legal perspective, it is perfectly possible, and it’s not that much work either. You might need to change the bylaws a little, but there is no reason why you can’t do it. From a hiring perspective, it’s much simpler, as you are not looking for that ‘superhero’ personality who would be great with both internal and external sides. Try it. As I said already, all you need is courage. And that’s one of the Scrum values anyway. Experiment, and from that stage inspect and adapt. Now, do I believe that this SM-CEO or PO-CEO will eventually make themselves out of job? No, I don’t. It’s the same as the team level. Even if the team is self-organized and knows the business well, there is still work for ScrumMaster and Product Owner. Similarly, at the organizational level, there is still a need for Organizational ScrumMaster and Organizational Product Owner even when the network of collaborative teams got self-organized, business value-driven, and customer-centric. The Organizational ScrumMaster and Organizational Product Owner would use Leader – Leader style to build other leaders around them, and if they are successful, the organization will become purpose driven where leadership will be emergent and structure liquid. The same way as it is in the Scrum team, the Organizational ScrumMaster and Organizational Product Owner will move from those who explain, tell and share, to those who coach, facilitate, and keep the system spinning. And that’s what is the Agile Leadership about.

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.

Component teams

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.

Cross-functional teams

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: Collaboration

Next blog in the From Good to Great series (Don’t Copy Find Your Own Way, Radical Transparency, and Agile Mindset) is focusing on the collaboration. There is nothing magical on it, just people are so got used to working as individuals that they forgot what the collaboration is about. However, collaboration is the key aspect of the Agile environment and if you can’t collaborate, there is no way you become Agile.

The traditional organizations are all about processes, rules, and delegation. All we need to do is to analyze the situation, come up with the way we want to handle it, and describe it in a process, and follow it. It shall be enough. It’s the world where we simply rely on processes in our day to day decision making. In simple situations, it works well, as the transparency and predictability of the situation are playing in favor. In complicated situations, it might not be flexible enough and people and organizations will struggle to react properly to the situations. In a complex situation when it’s hard to predict what happens it’s mostly failing.

“Tight processes are killing creativity and only work at simple and predictable situations.”

The more complicated is the situation you face on day to day basis, the more are companies failing to describe the process to be followed. It seems to be unavoidable that rules and practices are not enough to be successful, delegation come in place and the situation results in creating new roles and position for those who are responsible for certain part of the process. It allows more flexibility and responsiveness as people on the contrary to the processes can make a judgment based on the particular situation and solve it better. It’s the world of individual responsibility, where we create a single point of contact we can blame when things go wrong. Similarly to the previews process-oriented world, there is no real collaboration happening. Either I do it, or you do it. And it must be clear who is the owner.

“Individual responsibility kills collaboration and team spirit.”

Finally, over here we cross the line of collaboration. At least from a technical point of view.

This already starts feeling like a collaboration. At least at the first look, as there are more people working together. However, there is still one person responsible and the other just helping them. It’s a good first step, but at the end of the day, it’s closer to the delegation scale, than collaboration as the unequal ownership make one side more invested in the results than the other, where the owner usually makes decisions, plans, and responsibility, while the other support them with the inputs. It’s still more likely to create blaming than shared ownership and responsibility. While it may be a good first step, it’s not collaboration as we speak about it in an agile environment.

“Helping each other on their tasks is not a collaboration. Collaboration needs equal ownership.”

Finally, there is a real collaboration, where people have shared responsibility, shared ownership, and one goal together. It’s not important who does what, there is no task assignment up front, they all just do what is needed and make their decisions at the time. This is a type of collaboration, is what makes teams in Agile and Scrum great. Such collaboration creates high performing environments. If you truly want to be agile, and not just struggle to pretend that following practices are enough, it’s time to get rid of individual responsibility, which is often grounded in your org chart, position schemes, and career paths and learn how to create a real collaborative environment with shared responsibility and ownership. Learn how “We can do it together”.

Agile HR: Evaluations and Performance Review

The next topic in my Agile HR series focuses on evaluations and performance reviews. Once you hire the right person to the team, it’s time to start thinking about evaluations and performance reviews. In a traditional organization, it was pretty simple. Each employee got a task assigned, each task can be evaluated and linked to particular KPI. In Agile organization, it’s not that simple as multiple people collaborate on the same task and even if you try to set some KPIs at the beginning of the year, they mostly become irrelevant somewhere on the way so there is nothing to evaluate at the end of the year. 

The most simple practice used in agile environments is to set a team goal instead of an individual. There is still risk that the goal becomes obsolete during the year, but at least you support the team collaborative culture. The slightly better option is to break the year cadence and create shorter goals. After all, there is no magical on the year cadence when we deliver product regularly. A good practice is to let teams design their own goals, but you need a high level of trust in order to be able to move this direction. Some companies like OKRs, however, I see them too close to the traditional KPIs. Those were still traditional mindset practices spiced by little agility.

A good step on the way is replacing evaluation part by coaching conversation focused on employee development. As every coaching conversation, it is not about the coach but coachee (employee in this case) and is focused on raising the awareness of the person about themselves and their abilities and potentials. When done well, it can skyrocket people performance. But here is the downside – unfortunately, not many managers are good coaches which is a limit in most organizations.

Finally, if you are ready to be truly agile, how about if you do it in an agile manner and run regular frequent retrospectives instead of any form of evaluation. Together with radical transparency, it will create enough clarity about performance towards the Sprint Goal, product vision and entire organizational purpose so people can adapt in a very efficient way. Simple and powerful. Indeed we talk about not only team retrospective which brings so powerful peers feedback but also overall retrospective as it is designed for example in LeSS and organizational retrospective which can be facilitated for example in a form of world cafe or open space. All together it will engage employees in solving team, cross-team, and organizational issues, and increase their motivation to come up with creative and innovative solutions how to be better in delivering value and achieving the organizational purpose.

The frequent retrospective cadence brings regular feedback that allows fast changes and small improvements on day to day basis which as a result prevents big disappointments and surprises of traditional performance reviews which often brings demotivation and stress. Issues got solved sooner, before they are too big and poison the team or department and people get help to work on those issues early, ideally from their peers. You might not be ready for that tomorrow, as the culture of transparency and trust is not there yet, but you can go step by step until no-one misses any KPIs, performance reviews or any formal evaluations and frequent feedback, inspection, and adaptation become the regular way of work. 

At this stage, we often stop using the name of Agile HR and change it to Talent Development where the entire focus of the HR is changing to support overall employee journey and development. Supporting coaching and mentoring programs, and creating an environment for effective peer feedback are just a few ideas about where to start. 

Agile HR: Recruiting

The more organizations shift to Agile, the more they need to redesign how they work with the employees. During this series, we focus on different functions of HR in Agile organization and explain the fundamental shift HR need to do in order to support agility in the organization. 

Knowledge and skills are not anymore the key factors of what are we looking for. Agile organization builds on top of the collaboration, encourage innovations and need high flexibility. Experiences are also applicable only to a certain extent. It’s more about having an open mind, being able to learn new things, and collaborate with others to deal with complexity and unpredictability then being an expert with deep but narrow specialization. If you don’t think so, have a look at your own career. How many of you are still having in the same specialization? Most of the people changed their career more than once. And it’s getting even faster. So would you still care about hiring experts with particular specialization? Not really as they create silos and prevent your organization from changing a direction of the business. Agile organization needs people who are ready to learn, inspect and adapt. People who are not afraid to take over responsibility and run experiments. People who are not stuck with one way of working often saying “we always did it this way” and are ready to change their way of work as the business needs it. 

Skills are easier to be learned then mindset.

If you think about it, it’s very hard to create a traditional job description based on skills, and experiences as those are soon to be irrelevant. The new advertisement for an open position can say instead:

“We are looking for an enthusiastic, flexible, and open-minded person, who is ready to take over responsibility and collaborate with others on achieving the value. We are a team-oriented organization with a flat structure, which will support you in your personal growth. Join our team for a day to experience our culture. Together we can [achieve the vision].”

Quite different, right? When we tried it, no recruiting company was ready to support our needs. How many years of Java experience they need? What is the position description you are hiring for? No matter if you were looking for developers or new CEO… Quite a mismatch. Eventually, we realized that hiring new graduates is easiest for us. They were flexible, had ideas and be ready to be learned. All we had to do was to create a team learning environment based on pair and team working where they can get things fast. We realize that learning is easier than unlearning old habits, so very often, to get fresh graduates up to the speed was easier then hire Sr. Employees with individualistic habits which were creating more harm than help for the team environment. And that’s a hard message for all people who believe experience years count and shall result in a higher salary. Maybe if you are working for the government, but in Agile space, not necessarily as the recruiters may not care about your traditional company experience years at all. 

Unfortunately, a similar experience was with executive search companies, no matter how ‘big name’ of recruiting company you choose. They often had no idea about what agile is, so they are not helpful assessing the candidates, nor finding relevant people either. If you are looking for a leader with an Agile mindset, they are hard to find. Most of the executives are having bad habits acting as directive managers from hierarchical traditional organizations and again, it’s easier to grow leaders from your organization then hire externally. 

So if we can’t measure experience and skills and count working years, how shall we find out if the person is the right match? The same as in every other relationship. Let’s start ‘dating’. In this case, it’s about meeting team members at the interview. To be able to talk about the usual day, see if candidates feel attracted and also talk about candidates dreams and visions, to see if there is a match. Once they pass, they can go with the team to lunch. Informal conversation is critically important to learn about each other. And finally, it’s a good practice to offer a candidate one day at the company. To try and feel how it’s gonna look like. 

Hiring is more about creating relationship then assessing skills

If you feel uncomfortable with having interviews just like that, and feel a need for more formal assessment, you can try to role play some situations. Again, it’s not about correct answers as there are no correct answers in the complex world, but seeing the behavior and reaction when the candidate is surprised. Those situations are great to know how the candidates react when things go unpredictably. Again, it’s more about personality, approach, and mindset then skills and knowledge. 

That’s it. Forget experiences which are mostly irrelevant and skills which are soon to become irrelevant and focus on the relationship and employee experience. That’s the only way how you can be successful in finding the right employees and truly supporting the culture of the organization. 

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.

Top 10 Agile conferences to attend in 2019

I travel & speak at many conferences each year. Here is my list of TOP 10 conferences you shall attend in 2019:

  • #1: Business Agility 2019 Conference (New York, USA) March 13-14 2019. This conference has the most innovative format of all Agile conferences – three short industry experts’ talks are followed by facilitated conversation around tables.
  • #2: Agile Prague Conference (Prague, Czech Republic) – September 16-17, 2019. An awesome program, collaborative atmosphere of open space format, good value for money.
  • #3: Big Apple Scrum Day (New York, NY, USA) – May 10, 2019. Enthusiastic community, great space.
  • #4: Agile Austria: (Graz, Austria) June 25-26, 2019 – great place to meet Agile enthusiasts. Have fun with games and workshops.
  • #5: ACE! (Krakow, Poland) – May 23-24, 2019. Innovative form & great atmosphere. Focusing on not only Agile but good design, LeanUX, and Design Thinking.
  • #6: Agile 2019 (Washington, D.C., USA) August 5-9, 2019. Top Agile conference for the size and speaker selection. It’s a huge event which is unfortunately very expensive, but always worth the visit.
  • #7: Agile Days Istanbul (Istanbul, Turkey) April 4, 2019. Very interesting conference organized by local community focused on Organizational Agility.
  • #8: Scandinavian Agile (Helsinki, Finland) – March 13-14, 2019, Interesting speakers, inspiring content.
  • #9: Agile Tour Vilnius (Vilnius, Lithuania) October, 2019 – enjoy the day full of fun.
  • #10: Agile Testing Days (Potsdam, Germany) November 3-8, 2019. Interesting keynote speakers, deep insights in testing.

The selection is based on my personal preference and experiences from those events.

Other conferences to consider this year:

(Please share your suggestions with us and we add them to the following list.)

From Good to Great: Radical Transparency

I started the series From Good to Great by advising you to find your own way of being Agile. The next blog focuses on radical transparency. Let’s be truthful for a moment, how many organizations you worked for have real transparency, and how many are hiding information behind the teams or department walls, encourage by processes and claimed necessity of being compliant. Lack of transparency is a strong weapon which eventually can kill any Agile transformation as it makes collaboration and self-organization almost impossible. Lack of transparency is a great friend of hierarchical structures supported by fear and politics. “If I’m the only one who has the information, no one can jeopardize my position, and I’m safe being manager… All I need to do to be promoted is wait and make sure that no big mistake happens.”  Sound familiar?

Once you really mean it with your Agile journey, radical transparency is the key enabler. Together with the empowerment raising from the self-organization, it brings the energy and people start to take over the responsibility and ownership. They don’t wait until someone promote them to any function, they don’t wait for any orders. They take it over and collaborate on the solution.

Radical transparency is the key enabler of agility

Understand the Purpose

To understand the organizational vision and have a clear evolutionary purpose is crucial to successful collaboration and self-organization. In order to take over any initiative, people have to understand where are we heading, who are we, and who we don’t want to be. There is a very simple test. All you need to do is to take a random employee and ask him/her what is the vision/purpose/uniqueness of this organization. For simplicity, you can start with the executive leadership team to see if they didn’t lose the track of why they are there. 🙂 The good news is they usually know exactly what is the vision and can explain it in a very clear and engaging way. But when you do a cross-check across the organization, very likely there is a disconnect (usually several or even too many) which results in a very disruptive chaotic way of working. To fix it, storytelling is your best friend. Nothing can set up the stage better. Using serious of collaborative workshops like worldcafe, openspace, etc. involve people in co-creating the vision and help them to be part of it. Storytelling will set the directions. They need to own it, they need to believe it, they need to feel a need to be part of it. That’s the energy you need to begin. It brings innovative thinking, creativity, and empowerment, when people start offering help, ideas, and are ready to sacrifice personal goals in exchange for being part of something bigger.

Experiment, Inspect, Adapt

The next step is run experiments. At every level, you need to be transparent and openly share experiments at the early stage, and last but not least be ready to adapt through feedback. The downside is that before you learn how to collaborate and pass a test that you have the same understanding of the vision, it’s going to be very inefficient, and frustrating. “If we can just do it our way”, “they don’t understand it”, and “we know what to do so why shall we ask for feedback” people often say. But if you are strong enough and sustain the need for shortcut pre-baked solutions, very soon you see the results in higher collaboration, better understanding and some kind of harmony, which all over results in a high-performing environment.

Together with that, you need to run regular retrospectives and be transparent about the action steps. Share the backlog internally and externally. Simply there is no or very few information which needs to be hidden. If you believe you find any, try to double-check it by playing the “Five Why” and make sure you have a plan on what needs to be done so you can make it fully transparent.

Be Inclusive

The last necessary step on the radical transparency journey is to be inclusive. There is no such thing as a closed meeting. They shall be publicly visible with an open invitation so people can join if they are interested and have something to say. If there are many people, the facilitator can use some diverge and merge facilitation techniques, but no restriction shall be applied for the sake of efficiency.

It’s not about being fast without alignment, it’s about building alignment so you can be even faster.

Radical transparency is hard. You first need to have the courage to say things how they are, don’t be afraid to hear difficult feedback, have trust people will help you, and be ready to help others because after all, you all have the same vision, the same evolutionary purpose to achieve. It’s not easy but is a great investment and it will pay back in forming a highly adaptive (agile) high-performing organizations – the organizations which are formed to crack the challenges of the nowadays complex world.