Top 10 Agile conferences to attend in 2021

Every year I speak at many conferences and based on my experience I recommend some places to go for inspiration. 2020 was a weird year with almost every conference canceled or transferred to virtual space and there is a risk 2021 might be the same. But no matter if you are virtual or not, we still need to get some inspiration and interaction from similarly minded people. So here is my list of Top 10 Agile conferences to attend in 2021. It’s not my intention to cover them all, I’m sharing places where I like to return. Inspiring places with interaction, high energy, and great speakers.

  1. Agile 100 is one of the most interesting virtual events bringing a series of talks from agile space focusing on a mix of innovations, products, teams, organizations, and culture topics. It’s a monthly event combining 30 min talks and 20min interview with the speakers. Even if you can’t join all the events in a series, join at least a few at agile100.com. The 2021 series starts on Friday, Feb 12, 2021
  2. Business Agility Institute organizes several high-quality content conferences every year focusing on stories from executives, thought leaders, and practitioners on their agile journey. TED-style talks are followed by facilitated deep-dive conversations where participants can digest the experience and learn from each other. This year I would recommend you to join the virtual Business Agility Global Summit on Mar, 22-26, 2021.
  3. ICR Agile is a great event organized by the local Iowa community, I really loved the first year, so I recommend you to join the second year of ICR Agile Conference (Cedar Rapids, IA, USA) on February 25, 2021
  4. LeSS Conference is this time planned in Prague (nice city 🙂 ) and the organizers are still hoping they can organize this gathering of LeSS practitioners face-to-face. Reserve 16-17 September 2021 for LeSS in Prague.
  5. Another tip is a 12-hour virtual conference with active networking, great vibes, small groups, and international Agile leaders talks called Beyond Agile Israel on January 31, 2021.
  6. XPDays Benelux has a date for 25-26th November 2021, Parc Alvisse in Luxembourg. Let’s see if they are able to organize this highly collaborative event. Don’t expect any talks, this conference is more about workshops and interaction.
  7. Agile Coaching Retreat is not a typical conference, but it’s a great place to network and get inspiration from other agile coaches and practitioners. The 2021 Agile Coaching Retreat is planned for Lisbon/Sintra, Portugal on June 17-19,2021.
  8. AgileTestingDays is another great event happening for many years in Potsdam, Germany. Join Europe’s greaTEST Agile Testing Festival on Nov 15-18, 2021. There are always great speakers and a friendly atmosphere.
  9. Agile Manifesto 20th Anniversary is calling all agilists to celebrate the 20th Anniversary of the Agile Manifesto streaming live from Snowbird, Utah from the Aspen Room where it all happened. You can’t miss this event.
  10. Finally, if you want to experience something different, join Regional Scrum Gathering Tokyo. It’s organized by an enthusiastic agile community in Japan. The purpose is to provide a “Ba” (place) where practitioners share ideas among Scrum practitioners having a great diversity. Regional Gatherings provides a unique experience and even if you don’t speak Japanese, there are some talks in English and other translated. Join the local community on January 6-8, 2021.

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

Other conferences to consider this year:

There are many great events that didn’t make it to this list, so please share your suggestions with us and we add them to the following list.

Appreciation

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

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

Failing Fast

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

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

New Scrum Guide

There was a new version of ScrumGuide published last week. And I have to say that I mostly like it. It’s lighter, less prescriptive, and simple. Here are a few differences.

#1 – Scrum Guide 2020 is Simple and Clear

Scrum Guide 2020 is clearer. Finally, there is a sentence that is easy to read, and that describes what Scrum is:

Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

  1. A Product Owner orders the work for a complex problem into a Product Backlog.
  2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
  3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
  4. Repeat

Scrum is simple.

Yes, Scrum is simple and so the Scum Guide. It’s easy to read and understand. With this version, we got rid of many long and complicated phrases full of details. For example, one of my favorite changes in this space is that daily Scrum finally not suggesting the three questions but recommend that people “can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal…” Isn’t that awesome? After all those years of individual status meetings where people were reporting to someone what they did. It’s finally gone!

#2 – Focusing on the Mindset

I like the fact that the new Scrum Guide stresses the three empirical pillars of transparency, inspection, and adaptation and explains what are they about. The five values of Commitment, Focus, Openness, Respect, and Courage are clearly defined there now as well. It focuses on people’s behavior, over the processes and practices.

I also like the new Scrum Guide to remind us about the primary need for Agile and Scrum in complex and unpredictable environments: In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.” All over, if you know what needs to be done, can plan it, then all you need to focus on is how fast are you going to deliver it. In such a world all different estimation techniques, velocity, burn-down, and burn-up charts are considered useful. Unlike Scrum, which builds on empiricism and inspects and adapts the plans on the way.

#3 – Scrum Team Focus

The biggest change seems to be that we don’t have “Development Team”, ScrumMaster, and Product Owner but “Developers”, ScrumMaster, and Product Owner forming a Scrum Team together. It looks like a big change, but it’s rather cosmetic as they all have to collaborate and self-organize (or self-manage if you like) to maximize value towards the Sprint and Product Goal. So, no real change there, we’ve just finally got rid of the very typical dysfunction where the Product Owner was like an enemy and the team was delivering to the Product Owner only. Now there is no such mentality in the Scrum team, they are in it together, responsible for all product-related activities. They are a team in the first place, a team that is cross-functional so can deliver end-to-end value together. ‘Developers’ is a poor name, as most people somehow read it as software developers but it’s more like a product workers. They are still the people who create working product increment every Sprint, while Product Owner focuses on maximizing the value and ScrumMaster on improving teams and organizations.

I also like the new Scrum Guide to make the scaling approach clearer than before: “If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.”

#4 – Product Goal, Sprint Goal, and Increment

Finally, the last change is the new language about Product Goal (new) and Sprint Goal (improved), and Increment (clarified). All over the Scrum Guide is catching up with the industry and adding a Product Goal as an artifact. It also provides a definition of a product, which is much broader than many organizations think: “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract.” Product Goal is a long-term objective for the scrum team – a vision. Sprint Goal gives meaning to each sprint and defines the value we are focusing on now. The increment is a useful output. Well done, verified, and delivering value towards the Sprint Goal. Simple and straightforward. Finally, there is a much better language about the Definition of Done: “The moment a Product Backlog item meets the Definition of Done, an Increment is born.” It’s almost like a poem.

All over, I really like the new version. It doesn’t change much from what I was teaching and using, just brings a more clear and crisp definition of Scrum as I know it.

Barriers of Agility

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

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

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

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

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

Autonomy

Autonomy is a topic that is in my mind for a while. How come that in some environments it’s so simple to let it grow and some others are so much struggling with it. The more I think about it, the more I feel it’s about trust or fear of losing position, power, or comfort. And environments with no trust are not places where agile is much successful. In order to allow autonomy in even a small group as a development team, the trust must be there. I’ve seen the companies which were struggling to allow teams to choose their own name. “What if they choose something offending?” Like really? Now if you deal with such low trust, there is no way Scrum can work. I’ve seen organizations where they track when people are in the office and have so many restrictions that their computers become useless. “What if they don’t work and play games? Or not coming to work?” Isn’t that funny? The more restrictions you create, the more time people spend on breaking them or the more demotivated they are. Neither will help you to create successful products.

“Trust is prerequisite, transparency enabler, and purpose of the driving force for autonomy.”

Building trust takes time. Start small, don’t be afraid to be vulnerable. Ask yourself what is the worth thing which can happen. Ask what are those people around you scared  and how can you help them to feel more confident. The second ingredient in the mix is transparency. Being transparent about what needs to be done, what the success looks like, and what are the things we want to avoid is crucial. People learn by doing. Be transparent with the feedback. Perfection is not useful, it’s all about learning from small failures. Finally, the third ingredient in the mix is a purpose. Autonomy without a purpose only creates chaos. The higher the autonomy, the stronger the purpose needs to be to glue it together. To give everyone the same goal, belonging, identity, the reason for why they are there.

Imagine a kid’s camp. The Red group is defending the castle, the Blues are trying the take it over. Kids are naturally forming small autonomous teams, making their own decisions on the fly. They share information as they move forward. They don’t need any detailed instructions, any KPIs, any manager to give them process. All they have is a strong purpose. Your organization is not any different. Trust is a prerequisite, transparency enabler, and purpose of the driving force for autonomy. Building such an environment requires a portion of agile leadership.

ScrumMaster Mind

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

ScrumMaster builds self-organizing teams

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

Starting the Agile Journey

Understand Scrum is simple. If you don’t know what Scrum is and is not, there is a 17-page definition called Scrum Guide. If you like to know what is agile, go to the four values and 12 principles of Agile Manifesto. The agile community mostly agrees on both. As large products increase the complexity, there is no common agreement on how to apply agile and scrum to multiple teams and organization as a whole. The good news is that there are many options to choose from and many organizations can serve as inspiration on jour journey – Menlo Innovations, Zappos, Valve, Odde, ScrumAlliance, and I can continue. The first two are even often organizing visits to see how they work.

Agile Journey

In agile we love options and know, there is no one way how to do things. Some options are easier to apply, some harder, some less agile, some more. But remember Agile is not your goal, it’s just the way how to achieve your strategic goals so at the end of the day it doesn’t matter. The less agile ways are not necessarily bad options for given circumstances. Some companies go faster, some slower on their agile journey. Your organization needs to be internally ready for the higher level of agility and without direct experience with self-organization at the team level (across the organization at product teams but also at the executive teams and boards), it’s hard to go forward towards the organizational agility, Agile HR, Agile finance, and last but not least Agile leadership. I started this article by referring to the Agile and Scrum definitions. Would the definition of an Agile Organization be useful? It may look that way however I don’t think it’s needed. The Agile organization is not about practices, processes, not frameworks. It’s about being agile. It’s about agility hardcoded in the organizational DNA and culture. It’s about living the values. Be courageous to change the status quo, be open to feedback, respect different opinions, and have focus and commitment to deliver value not only to the customers and shareholders but also employees. So if you want to check your readiness to apply agile principles at the organizational level, start with the values. Do you like them? Do you live them? Or do you think they are not important?

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/.

Great Product Owners

Great Product Owners are not only having business knowledge, authority and time, but also a few additional skills which people often don’t expect.

“Great Product Owner is a facilitator, coach, negotiator.”

You will usually hear about coaching and facilitation in the connection with the ScrumMaster role. So why do we talk about Product Owners and facilitation and coaching? Can’t they just use the service of the ScrumMaster? They can. However, in many environments Product Owners are not the ‘heroes’ who decide on everything. Quite the opposite. They are great listeners, who have respect for different customer voices, and their highest value to the system is they can find alignment through coaching and facilitation. Customers (users, stakeholders, shareholders, sponsors, …) never agree with each other, they all have their own preferences and needs. Great Product Owners can help customers to reconnect with their needs instead of pushing what they want. In order to be able to do so, they need to step back, acknowledge that their requests are representing just one way of achieving their goals, and search for other options that would satisfy the needs of more groups than before. In other words, they need to be good at integrative negotiation and finding win-win solutions.

Finally, the last skill great Product Owner needs is visual facilitation. It seems like an unimportant skill, but the good picture speaks for more than a thousand words and can create real magic in searching for alignment. Visualization creates transparency, and transparency is ground for accountability. You would be surprised how good visualization of a conversation and different perspectives can help people to change their mind and proactively help you in searching for alignment.

Maybe those skills are not on the top of the Product Owners list at the beginning, however, the same skills differentiate great Product Owner from the newbies.