From Good to Great: Cross-Functional Teams

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

Component teams

Business value

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

Cross-functional teams

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

Impact

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

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

From Good to Great: Agile Mindset

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

Delivery

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

Strategy

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

Impact

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

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

Deadlines in Scrum

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

Purpose driven

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

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

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

Agile Leaders are the beginning of modern management

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

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

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

Agile Leader-Wheel

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

Review bazaar

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

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

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

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

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

How to make great Sprint Review

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

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

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

Your Sprint review is great if you …

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