Tag: Scrum

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.

Top 10 Agile conferences to attend in 2020

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

      • #1: Business Agility 2020 Conference (New York, USA) March 11-12 2020. Agile is not about frameworks, practices, and tools, but the mindset. This conference brings stories from executives, practitioners, and thought leaders. It has a very innovative format – three short industry experts’ talks are followed by a facilitated conversation around tables. This conference is very unique, don’t miss it.
      • #2: Agile Prague Conference (Prague, Czech Republic) – September 14-15, 2020. This year it’s the 10th anniversary of this popular conference. An awesome program, a collaborative atmosphere of open space format, good value for money. Postponed to 2021.
      • #3: Agile 2020 (Orlando, FL, USA) July 20-24, 2020. Top Agile conference for the size and speaker selection. It’s always worth the visit as you can meef there every agilist 🙂 Canceled.
      • #4: ACE! (Krakow, Poland) – May 20-22, 2020. Innovative form & great atmosphere. Focusing not only on building software better but also building better products including UX design. Rescheduled to September 16-18, 2020.
      • #5: Agile Austria (Graz, Austria) April 29-30, 2020 – a great place to meet Agile enthusiasts. Have fun with games and workshops. Postponed to 2021.
      • #6: Global Scrum Gathering NYC (New York, NY, USA) May 11-13, 2020 Scrum Gatherings are great places to talk to Scrum practitioners, join coaches clinic, get hands-on experience on your agile journey. The Gathering is not just about Scrum, it’s about sustainable agility. Canceled.
      • #7: Agile Iowa (Cedar Rapids, IA, USA) April 30, 2020 – Great local conference organized by the community, join the first year of this conference and be there from the beginning.
      • #8: Agile Testing Days (Potsdam, Germany) November 8-13, 2020. Interesting keynote speakers, deep insights in testing. And it’s always fun to be there.
      • #9: Agile Tour Vilnius (Vilnius, Lithuania) October, 2020 – enjoy the day full of fun. Great community, enthusiastic audience.
      • #10 Beyond Agile Israel 2020 – January 26, 2020, Tel Aviv, Israel. – Enjoy warm weather in the middle of winter. Great program in just one day.

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

Recommended virtual conferences this year:

    • Agile100 – May 29, June 26, and July 31, …2020, 12pm – 10pm (CET – Central European Time) / 6am – 4pm (ET – Eastern Time) … more days are coming
    • LeSS Day Europe 2020 – June 15 – 17, 2020 3pm – 7pm (CET – Central European Time) / 10am – 14pm (US Eastern Time)
    • Emerging from crisis – June 17 – 19, 2020
      • 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)

Other conferences to consider this year:

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

Update: See my Top Agile conferences list for 2021.

Great ScrumMaster is a Catalyst Leader

ScrumMaster is a Catalyst leader introduced by Bill Joiner in his book Leadership Agility. Catalyst is the third step on the leadership journey from Expert to Catalyst. In a very simple way, Expert is the person who knows better and therefore can advise and lead others by example, using his own experiences. Achiever is oriented to the results, they are very competitive, like the stretch goals, clear objectives, and believe a good challenge is the best motivator. They take people as resources towards achieving their goals. Finally the Catalysts understand agile deeper beyond practices, roles, and frameworks. Their key focus is to create a space, an environment where people can be successful. They care about the culture where many-to-many relationships emerge, focus on collaboration, transparency, and openness. They empower people around them, work with teams not just individuals. They are good at complex situations, seeking different perspectives and diversity, looking for innovative and creative solutions.

At the first place, ScrumMasters need to be Agile believers, the highest enthusiasts about agile from far around. Otherwise, there is no way they help others to embrace true agility. They need to be good at all five ScrumMaster State of Mind approaches explaining, storytelling, root cause analysis, coaching teams, not just individuals, large group facilitation, and that not all. Their knowledge goes wider than a few frameworks, practices and methods. They need to improve their leadership skills, understand organizational design, structure and culture models, overall business agility and be good at change management because agile is a huge change of the way we think and approach things.

As Expert leaders, they only drive a car on one gear – teaching. The Achievers are adding a pressure which is not really helpful if you think about ScrumMaster’s goal of achieving self-organization. So being Catalyst is the only way how to become great ScrumMaster.

5 Reasons Why to Attend AgilePrague Conference 2019

#1: World-class Program

Several years in a row we managed to achieve high-quality program while keeping it affordable to the people in the Czech Republic. This year you can be looking forward to awesome speakers, for example, Samantha Laing, Pete Behrens, Heidi Helfand, Stephen Parry, and Marsha Shenk. Register soon, the conference is always sold out.

Agile Prague Conference 2019

#2: Agile Journey Focus

The theme of this year is the Agile Journey. Agile is more than an IT process. We are going to talk about Agile transformations, leadership, scaling, the new ways of running your products and businesses, collaborative culture and great teams. See the program.

#3: Coaches Clinic

You can discuss any area you are interested in and get free help from experienced coaches at our Coaches Clinic. It is a unique and free service designed to help you with specific challenges you’ve encountered on your way to a more Agile way of working. The Coaches Clinic is prepared and organized by Certified Agile Coaches – Certified Team Coaches (CTC), Certified Enterprise Coaches (CEC), Certified Scrum Trainers (CST) and other experienced Agile coaches.

#4: Open Space

AgilePrague Conference is not just about listening. We want you to participate and come up with your own session. Every mid-day there is an open space where you have an opportunity to share ideas, discuss topics with each other and join a deep dive conversation with our speakers. Open space is an opportunity to create your own program and bring your own topics to the conference. 

#5: Visit Prague 

Prague is an awesome city, so why not combine the sightseeing & conference? Have a beer, wander through old town & narrow streets, enjoy one of the greatest historical cities 🙂 

Looking forward to seeing you on Sep 16-17, 2019 at AgilePrague Conference!

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.

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.