Forecast, Don’t Estimate

There is almost no class where no one would ask me about estimations. So why estimations are not part of Scrum? Let’s start with a bit of context. The whole idea of agile estimation comes from Extreme Programming and the early days of agile where tools like Story points, Velocity, Planning Poker, Burndown, T-shirt sizing, used to be very popular. However if you look at current state of the art of Agile and Scrum teams, they are not using those techniques very often anymore.

Estimations were always core part of any project management, where we believed we know what needs to be done, so the whole problem is not about WHAT but HOW FAST. Therefore tracking the velocity, showing the burndown and estimating is very useful in such predictable environments where there is only little unknown. So when people shift to their first agile project, they very often still have the same mindset – we know what needs to be done so let’s create a backlog, estimate individual backlog items, and track how fast we are delivering it. That’s the world where estimates, Story Points, Bundowns and Velocity are very useful.  

In a contrary, the Agile world is focusing on dealing with complexity and fast changes. We start realizing our plans are failing and that we are often learning too late that something else should have been done instead. In such unpredictable world, all we can do is to change our way of working and be more reactive to the changes and more responsive to the feedback. We are realizing that it’s not about plans but planning as a continuous activity. Therefore refinement in Scrum is ongoing effort and we discover and detail backlog items just in time. In such world it’s not about going fast (often to the wrong direction) but going to the right direction (even if that is slower). The fundamental difference is that we realized we don’t know what needs to be done and so any estimation of that unknown is kind of useless. We know what needs to be achieved, but without getting frequent feedback from customers we don’t know how to achieve it. Of course you can still estimate the stories that are coming to the Sprint, but you need to have a good reason for doing that (see one of my previous blogs on estimating). Estimating the whole product is not really useful either as the Product Backlog will change based on the feedback anyway. The value to be achieved (vision and product goal) is clearly defined, just the journey of how to get there is to be defined based on what we discover though short iterations.

The problem we are trying to solve in Agile environment is about how can we maximize the value, while minimizing the effort spent (see more about the mindset shift). It’s more about prioritization, where we try to identify the minimal functionality that need to be done now, and the rest later or never, noting that 80% of the business value is in 20% of functionality. Our backlog items are not functionality driven (telling you what needs to be done) but value driven (telling you what needs to be achieved) where the solution is up to the team to be discovered during the Sprint. Therefore even individual story estimation makes little sense as the implementation (how) will be designed and updated during the Sprint. Scrum is not fixing the scope within a Sprint, as a Sprint Backlog is just a forecast on how we are most likely going to collaborate to maximize the value towards the Sprint Goal. While the Sprint Goal (value) doesn’t change during the Sprint, the Sprint Backlog can change any time, depending on the learnings, new ideas, and feedback we got from our customers and stakeholders. If Scrum team realize there is a better way to maximize the value towards the Sprint goal, they have to just inspect and adapt their forecast (Sprint backlog items) and continue collaborating on maximizing the value towards that Sprint Goal.

Traditionally teams were estimating what needs to be done and they were using those estimates on answering what can be done in a week, two or three. In Scrum, we set a Sprint Goal and then forecast what is to our current knowledge the best way how to achieve it. And what is based on our current experience feasible. We are ready to change it anytime if a new information emerge. To plan our Sprint we are using our understanding the of backlog items (stories) and our experience from the previous Sprint. We are looking at it from different perspective – how much can fit within a Sprint. And that’s not just about an effort but also skills & competences mix, risk, complexity, etc. It’s a similar type of problem as if you are packing to the weekend and measure the volume of all items you like to put in the bag. In reality it’s not just about the volume, but also about the shape and consistency. With Sprint Backlog it’s the same.

So can we tell our customers when are they going to get their product without estimating individual backlog items? Sure. We forecast how many Sprints it might take to achieve that value (Product Goal) and then prioritize so that we deliver the most important features first, which the rest later or never. 80% of the business value is in 20% of functionality so if your Product Owner can do the proiritizarition well, you can ‘never’ fail to achieve it (see more about the Product Owner role). Through that process we focus on different direction each Sprint (Sprint Goal) and inspect and adapt based on the feedback.

Finally there is the last question, can you estimate backlog items in Scrum? Sure. Same as you can drink coffee which is not part of any Scrum either. But I guess the downside is, that if you focus too much on estimates, it guides you from focusing on business value. And there is no correlation between the two. Bigger doesn’t mean better.

Agile Journey

Agile is a journey. In the beginning, people think it’s about different tools, new processes, new names. They keep comparing it to what they know and they are frustrated that the new way of working doesn’t fit the world they know. They still try to analyze, plan, estimate, and track delivery. The problem with that is that they are changing to agile not because there is a new improved method, but because their current way of working is not as successful as it used to be. There is a strong need for significant change. The traditional way of working was effective in solving predictable problems, not in dealing with complexity. In the current world, organizations need to be more flexible, innovative, and creative to address VUCA challenges. Agile brings new paradigms, a new mindset, a new way of working. It’s not comparable anyhow to the traditional ways of managing and delivering work.

Once they pass the initial phase, stop comparing and start looking for understanding, people often fall into a trap of taking all agile as a ‘religion’. Just follow the process, implement tools, do scrum according to the Scrum Guide! This phase is not much fun either. But they are on a journey, not fighting with any strong resistance anymore, and deepening their knowledge about various practices. People are interested, they want to understand it, do it well, however they are usually asking fundamentally wrong questions, looking for the best practices, believing they can copy & paste practices.

When they experiment, fail, and learn from failures enough, they start realizing the real agility, which is not in practices and tools, but in a different culture, mindset, and approach to things. They start realizing the organization and leadership need to change in order to finish the transformation and allow the agility to be successful. Agile becomes the way you not only organize the work but the way you live. It will bring different values and different perspectives.

 

Agile Transformation Metrics

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

Team Measures

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

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

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

Journal of Business Agility – Emergence

Recently I received a nice magazine in my mailbox, the Journal of Business Agility – Emergence. If you are looking for stories from different organizations, inspiration from agile leaders, I would recommend you to subscribe to it. Businesses Agility Institute is known for high-quality content conferences, and the Emergence magazine is a good example of very good curated content. So what caught my attention from this first issue of the magazine?

Budget planning: Prioritization – Capacity – Funding

I start with the first article where Jardena London shares her insights about Budget planning. It’s so much close to what I experienced as a Director running a software organization. “Stop talking about budget and capacity until you prioritize the outcomes you want across the organization. Even the high-level strategic goals need to be put in order.” So many organizations are unable to focus and try to push more things without a conversation about priorities. Once ordering is done “Start by planning capacity by teams, it’s way easier than planning for individuals. You may find that your current team structure no longer serves the needs of your portfolio, so you’ll have to tweak it, maybe add/ remove team.” On my journey, I learned that working with teams is so much easier than trying to plan everything with individuals. From the organizational perspective, working with individuals is too detailed and all different irregularities made it too fuzzy and unpredictable. I can also relate to this note: “Don’t plan out the year, plan the now.” In the current VUCA world, the yearly planning cycles feels outdated and unrealistic. I still remember when we went away from estimations and how enlightening it was. However, when I speak about it now, many people are almost freaking out. How can you plan your capacity without it, they ask. “When we estimate hours, we miss all kinds of variables like task switching cost, administrative time, and buffer time. We spend energy trying to get more precision in the output than we have accuracy for in the input.” Instead, in an agile environment, we focus on forecasting how much teams can produce in a short iteration. “With the same number of people, capacity can change over time. Improvements to capability and technology can impact capacity. Capacity is great for forecasting and planning.” But it’s still a concept very hard to accept not only by finance departments but also by the teams. Finally, “Once you have prioritized and planned capacity, and you’re ready to go, allocate funding. This is the very last thing we do, allowing money to be free and flexible as long as possible.” Agile is about flexibility and the ability to be change responsive. “Decoupling prioritization, capacity and funding can breathe new life into budget planning, alleviating the difficulty for employees and improving outcomes for the organization.”

Fact Sheet: The State of Business Agility in 2020

For those who like facts, numbers, and charts, there is a summary of the State of Business Agility report. “In 2020 we saw a significant increase in business agility globally. Compared to last year, we have seen more organizations commencing their business agility journey, and those on the journey report greater progress.” It’s no surprise for me, as I’m getting the same message from organizations, but it’s still good to have it confirmed with data. And it’s also no surprise that “Leadership continues to be the common theme amongst all transformational challenges.” I can see that in most of the organizations. Boards and executives are struggling with a core understanding of agility beyond practices, processes, and frameworks. Their experience with business agility is still very limited. The good news is, that there are many inspirational stories and use-cases covering every spectrum of organizational function, but still looking for an agile organization is a tough job. When I was writing my new book The Agile Leader: Leveraging the Power of Influence I was bringing in some of those pioneers to share their insights in a short story. We need more stories about the successful agile. We need more insights from their journeys. That’s the only way how to make business agility more accessible for leaders and organizations. If you are looking for three tips where to start, the report brings you three tips: “Organizations who reported higher ratings in these three characteristics also report higher overall business agility and associated benefits: 1. Encouraging a culture of learning and experimentation, 2. funding business outcomes rather than specific work outputs or projects, and 3. aligning work to customer-centric value streams.” Very true. Experiment, learn from feedback and deliver value. Looks very simple, but it’s unfortunately very hard to do in some organizations.

The agile journey of Scrum Alliance

I was watching the Scrum Alliance journey for several years, and I’m very proud of how they changed and the experiments they were courageous to take. Living the Scrum values is never simple, and being agile is a journey. “The Scrum Alliance revolution – beginning with reflection, continuing through a complete rebuild of the organization’s working methods, and ending in a revitalization of public perception.” That’s easy to be said, but hard to be done. “Before the self-organization process, Scrum Alliance had multiple departments with multiple part-time scrum teams. Afterward, the structure had been simplified to six cross-functional and cross-departmental scrum teams.” Once the change was implemented as a trainer I could see immediate value to be created every sprint. How interesting change from all the years before, where value delivery was much slower. “By changing the internal structures of Scrum Alliance, Melissa and Howard had also changed attitudes, operational standards, and revitalized the ethos of the entire organization.” It’s great to read about successes but equally important is to read about things that didn’t go so smoothly. Being agile is a journey and this article is showing the journey with all the transparency and honesty. “Most importantly, Melissa and Howard have built an organization that strives every day to practice what it preaches and embody the values and principles of Business Agility” and that’s something you don’t see every day.

And there is more…

Stories from leaders, experiences shared by practitioners. That’s all that we currently need on our agile journey as a society. Agile is not anymore a different project management method. For long ago it left the basement where the IT department was closed. It’s changing the way how organizations operate, and how they do their business. The topics of Agile Organization, Agile Leadership, Agile HR, Agile Finance, and Business Agility are everywhere. There are schools applying agile values and principles, there are governments changing their way of working. Agile is everywhere. The new generation is different, they don’t want to be told what to do, they are asking for higher flexibility and autonomy, they require freedom to choose from where they are going to work and how they deliver the value. Some organizations already figured it out and started accommodating the change. Others are picking up. “The intention of business agility is to create an organization best able to serve its customer, no matter what the future brings.” That last part – no matter what the future brings – is in my mind the most important. Imagine an organization that is flexible and fast responsive, so it is ready for any situation. What else could you wish for succeeding in the VUCA world, right?

Subscribe for Emergence Journal and get a 10% discount using “agileprague” promo code.

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.

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.

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.

Top virtual conferences to join in 2020

The world recently changed into a very unpredictable stage. No one expected it, no one was ready for it, and not many people like it either. However, every crisis is good for something, and this one brought new ways of doing things. While most of the traditional conferences from my recommendation from January are canceled or postponed, the new virtual events emerged from the crises and bring unique value in this difficult time. The first time ever there can be one event for everyone in any place in the world – no travel, no jetlag. If some talks are late at night or too early in the morning for you, don’t worry. There is going to be recording. And just be honest, how many of you attended all sessions at the face to face event? I didn’t. So there is no difference really 🙂

#1: Agile100

Agile100 is a series of virtual conferences that bring the world’s top 100 agile thinkers and speakers to everyone across the globe. Embracing the latest technology, the conference is not only streaming talks from great speakers but creates connections, allows participants to meet and learn from each other, offer parallel ad-hoc open-space sessions, learn from experienced Certified Agile Coaches, and much more. People with access to knowledge and information can tackle any challenge and make our world more productive, more humane, and more sustainable.

LEARN – CONNECT – GET INSPIRED

The first few dates in the 2020 series are May 29, June 26, and July 31 – 12pm – 10pm (CET – Central European Time) / 6am – 4pm (ET – Eastern Time).

#2: Emerging from the crisis

Business Agility Institute is known for the top-quality conferences across the globe. Their last face to face event in the NYC had to turn half into virtual to accommodate people with travel restriction and they did amazing job allowing online participants to join and collaborate in facilitated deep dives the same way as the face to face attendees could. The current crisis will leave an indelible mark on the world of business. What will be the impact on Leadership, HR, Strategy, Finance & Risk Management? And what role does business agility play in emerging from this crisis? This conference is not about what we need to do now to survive the crisis or adapt to remote work; we’re aiming higher. We want to learn what we need to do today in order to thrive tomorrow. Join Emerging from crisis virtual conference to be inspired through 20-minute talks and discover practical next steps through facilitated dialog with your peers, get inspiration from invited leaders and strategists who walked through crises and have come out the other side with lessons learned and best practices.

LEARN FROM THE PAST TO THRIVE IN THE FUTURE

June 17th – 19th, 2020 – two options to choose:

  • Option 1: 11am – 1:30pm (US Eastern Time) / 5pm – 7:30pm (CET – Central European Time)
  • Option 1: 6:00 pm – 8:30 pm (US Eastern Time) / 8am – 10:30am (Sydney time)

#3: LeSS Day Europe

LeSS Day Europe virtual conference takes upon a mission of bringing to you fresh, impressive and up-to-date case studies of Large-Scale Scrum (LeSS) adoptions by means of story-telling and rich knowledge exchange. Get inspired by the most recent and most insightful case studies involving hundreds of people transformation in different industries. As usually, this conference is worth joining.

LEARN FROM PROVEN CASE-STUDIES AND FIRST-HAND STORIES OF DEEP AGILE TRANSFORMATIONS

June 15 – 17, 2020 – 3pm – 7pm (CET – Central European Time) / 10am – 14pm (US Eastern Time)

 

 

Who is Driving a Change in the Organization

Managers are very often asking me who is driving the agile transformation and expecting some special position like VP of Agile or Chief Agilist. To their surprise, there is no such position needed. I already wrote here about Agile Organizations and hierarchy. Real Agile Organizations are flat and lean, so they don’t create any new position for a problem, issue or initiative. In Agile Organizations, we already have ScrumMasters to introduce change.

“If you want to drive Agile transformation, you need to become ScrumMaster.”

It’s simple and straightforward. We don’t need another role, we don’t need another layer. Referring to the #ScrumMasterWay model, ScrumMasters are not only responsible for growing great self-organizing teams (My Team level), helping the ecosystems around their team to be self-organized (Relationship level), but also helping the entire organization to be self-organized (Entire System) and embrace agility at all layers. Scrum Masters competencies cover not only agile, business, and technical practices, but are also responsible for driving a change because, at the end of the day, agile brings significant change, new culture, a new way of working.

ScrumMaster is a leadership role, so it’s a good fit for managers who want to make a difference in the organization, who care about helping others to become leaders, who are passionate about changing culture, who are Catalysts. ScrumMaster is a Servant leader. They are not having any positional power, they can’t tell people what to do. But they have an influence. They can coach and facilitate to unleash the potential, helping people to find their own way of working. That’s what self-organization is about in the first place, that’s what agile transformation is about.