Scaling Agile and Scrum

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 the Agile Manifesto. The agile community mostly agrees on both. As scaling increases the complexity, there is no common agreement on how to scale agile and scrum. The good news is that there are many frameworks to choose from. A broad menu of options, and in agile we love options and there is no one way how to do things. So far so good. 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 a bad option for given circumstances. Some companies go faster, some slower on their agile journey.

To give you a few examples:

If you have a totally fixed mindset, no collaboration, hierarchical organization, even frameworks like SaFe can be useful. You might not become agile using them, but at least you start moving and changing. As any SaFe implementation didn’t create any magical success, companies keep looking and sooner or later find a better way of working and scaling.

If you have limited experience with self-organization, but like to be modern, cool, aka agile, the Spotify so-called model is a good choice for you. All that awesome terminology of tribes, squads, and guilds makes the job and at least some parts experience a certain level of agility. And step by step, as your mindset becomes more agile you can move towards a more agile way of working and implement LeSS as ING recently did.

A super-simplified tagline for each framework:

SaFe (Scaled Agile Framework) is scaling ‘fake’ Scrum with traditional mindset practices. A good start if you are stuck and need to get moving no matter in the direction, or if all you need is a stamp that you are agile without any change of mindset. It’s easy to implement, and it’s safe as most of the roles are just renamed, not really changed.

Scrum@Scale is mentally very close to SaFe, no real change will happen at the organizational level which remains very hierarchical. Scrum at the team level is rather technical (it’s all about practices), ScrumMaster somewhere between team assistant and manager. At a glance, it looks agile, but the lack of understanding of the self-organization concept will eventually kill any good intent and implementations will fail to bring any expected results.

Spotify is not really a model, but an inspirational story. Nevertheless, ING makes it so popular so every other bank is applying it. The cool terminology helps to spread the message around, and there is a chance that by applying it companies learn what is this agile really about. It’s also a good opportunity to descale your organization a bit and remove several layers of traditional management in exchange for the more flat structure of the above-mentioned tribes and squads.

LeSS (Large-Scale Scrum) is Scrum. It’s the most agile way of how to scale. Similarly to Scrum, it’s simple to understand, hard to apply as you need to have courage, be ready to collaborate, increase transparency, remove silos, and redesign the organization. Do more with less. The good news is that it works. Don’t expect it to be a one-time change. Agile is a journey, and implementing LeSS is very agile so you are going to be on your journey for a while. You can get inspired by the case-studies.

Agile is Not Another Project Management Method

Agile is not about new practices, processes, or tools. It’s a different way of thinking and approaching things. In one word it’s adaptiveness. If we go next level, it’s a customer-centric value-driven iterative team approach to deal with complex problems. You need the courage to do things differently, be open and transparent to allow collaboration, focus on customer and commitment to deliver the value, and have respect so you can learn from diverse perspectives. But I guess you know all that.

Implementing Agile at the project level is a good baby step on your journey. It gives you a limited scope for the experiment, so you experiment with agility in a limited scope. However, sooner or later if you want to achieve some real business objectives you need to move the agility to the next level and then projects become redundant. Surprised? Let’s take one step back. In traditional management, we use a project as a container to control the work delivery. And we have a project manager taking care of the project. In Scrum, we have Product Backlog to define the work to be done and Product Owner taking care of making it done in the right order. Instead of a project we simply have backlog items. You might also call them Epics, but there is no need for any project. As the work from the backlog gets done Sprint by Sprint.

As a baby step experiment, it’s OK to apply agile on an individual project, but Agile is more than that. Looking at the organizational agility worldwide, the knowledge and experience with agility at single team level reached late majority as you hardly find organization with no experience at all, the knowledge and experience at the scaled level is early majority as the big corporation are widely starting their transformations, and we are reaching an organizational level of agility with early adopters talking about business agility, agile leadership, and agile organization. The more organizations understand agility, the fewer projects and project managers you would see around. You might dislike it, argue with me, and fight with agile arguing it’s a bad idea which will never work, or jump in this already moving train and catch up better sooner than later to stay competitive and keep some relevant job as the demand for project managers is already decreasing…

We Don’t Need Another Method

Let’s start with a bit of context. We apply Agile not because it’s a new cool method 🙂 but because it’s a good answer to the complexity of the nowadays world. We change because the traditional ways of working are failing, as they expect reasonable stability and lower complexity which allow to analyze the situation, plan what needs to be done and then do it. In the nowadays world the complexity, uncertainty, volatility, and ambiguity is so high that you can’t even do that and need to fundamentally change the way you work into the more iterative feedback-driven way, simply be more change responsive, adaptive, agile. 18 years from the Agile Manifesto is a long time. Spend a minute looking back to 2001. How the business looked like, what had you been doing? In 2001 the variety of frameworks, methods, and practices was not that diverse. Agile was at the beginning.

Today, we are in a very different space. Agile is not anymore a new way of working, it’s a major trend companies are taking. What is missing in most of the organizations is not lack of practices and frameworks but a very simple thing. Mindset. Just apply them. We don’t need another method. We have plenty already. Everything was said and yet, companies are still not agile just by changing their processes and tools. There are so many practices yet people are still looking for best practices and easy to follow checklists. I understand that it would have been so nice, just to say the magic formula and all the issues are gone. But unfortunately, there is no such thing as best practice in the complex world. All we have in a complex world are options. Some are easy to do, some harder. Some might be a good idea to do at the beginning of your journey, some are great when you are experienced already. Some are great at one context and create a disaster in another. Some are leading towards what you need to achieve, some are not. Frameworks are good as they give you enough freedom to experiment and find your own way but also some boundaries. Practices are great as they give you inspiration. And there is plenty to choose from. So just choose some to start and inspect and adapt from that. They are neither good nor bad, they are context, meaning culture and environment-specific. And if your company is not “agile enough” according to your expectations and needs, it’s not because you are missing some magical framework, method or tool. We don’t need another frameworks, method, or practice, there are plenty out there already. All we need is to start using them fully, as intended. Start being agile, stop doing agile. Experiment with different practices and stop looking for the Holy Grail method which would save us. Agile is about collaboration, early value delivery, and finding your own way through experiments and feedback, learn from failures. Simply being adaptive.

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.

Agile HR: Leadership, System Coaching, and Large Groups Facilitation

Finally, as the last blog about the Agile HR in this series or talent management if you like, is focusing on the skills and experiences of good HR. Primarily it’s about the understanding of Agile mindset and ability to create an environment where Agile culture can flourish. Environments supporting collaboration, transparency, open peer feedback, trust, team spirit, ownership, empowerment, and responsibility. The more Agile your organization is, the higher the need for coaching and facilitation skills it creates. The role of HR is critically important to grow coaching and facilitation skills in the organization and support individuals and teams with education on coaching, facilitation and guide them on their journey.

Another fundamental shift is from management which is based on decision making and delegation into leadership which is not given by any position but is a state of the mind. Anyone can become a leader. It’s only your decision if you are ready to take over the ownership and responsibility and lead an initiative, team, or product. The peer feedback will take care of enough self-awareness so leaders can emerge through the organization. Very often we speak about emergent leadership as one person can act as a leader of one initiative while at the same time being a team member of another one. As the evaluations transform into regular peer feedback and coaching for development, the key goal of the leaders is to help other leaders to grow where again, the need for good coaching and facilitation skills is inevitable. 

The fact that HR changes the focus in Agile organization to the overall employee experience is only the beginning. So let me suggest another idea. The good HR shall act as an organizational ScrumMaster or agile coach if you like, operating at the third level of the #ScrumMasterWay concept, focusing on the overall system. At this level it’s not that much about coaching individuals but coaching teams and organizations as a system, leveraging tools from system coaching like ORSC. It’s not that much about team facilitation but the ability to facilitate large groups with 100’s people, leveraging tools like world-cafe and Open Space. It’s about being a model of an Agile leader growing the ‘we-culture’ and mentoring other leaders to grow to Agile leaders. In short, Agile HR is Agile leadership, system coaching, and large groups facilitation. 

Agile HR = Agile leadership + system coaching + large groups facilitation.

Agile HR: Career Path and Salaries

The third blog from this Agile HR series focuses on positions, career paths, and salaries. As I already mentioned in the first Agile HR blog about hiring, positions are not that important in agile organizations as people collaborate, take over responsibility and become leaders as needed, not because they have it in the job description. In traditional organizations, it’s all about the position. We hire to fill the empty position, it designs what people do and don’t do, it shows the potential of who employees might become if they got a good evaluation and are promoted. And last but not least the position defines a rank of the salary.

The whole concept breaks once you stop treat people like individuals and create a team environment where people self organize their work and collaborate based on their skills and abilities. Such shift quite naturally creates a need for fewer positions as for example in one Scrum Development team there are no roles, just team members. So your positions can follow the Scrum organizational design and instead of having the SW developer, SW tester, and analyst, maybe you can just have one position of SW Engineer. Or simply a team member. Every position potentially creates silos and gaps, dependencies, and the need for synchronization and hand-over. Nothing which would help you create high-performing teams. 

In more agile environments… 

If reading the previous paragraph hasn’t created too big shock in your mind, you are ready for step two. Teams members have the same goals they contribute to, they do frequent peer reviews and hold each other accountable to improve their skills. In such environments, the only reason for positions and career paths is the direct correlation with the salary. The solution is obvious – decouple salaries and positions. In such case, you don’t need any positions at all, as the team roles are emergent, same as leadership. Salary can be linked to the peer feedback and individual value to the organization as a team member. It’s a startup mindset. Imagine for a while that you are not an employee but entrepreneur and every day you need to prove that you bring enough value to get paid. Stressful? Maybe. So be aware that every practice like this needs certain culture and organizational agility. I would not start with it the Agile journey. However, you can take it as a next step and be ready to move there when your organization is ready. On the other hand, if you feel you are ready, there are two tips on how to start. First is a hard choice of two options to the employees: stay because they believe in the change and are ready to take over the ownership and responsibility to succeed and achieve the organizational purpose or take a leaving package of x salaries and go. The people who stay are those with the right mindset and any transformation will be so much easier. Second is gradual. Start with decoupling the salaries from the positions. Sooner or later the positions become irrelevant so no one would miss them anymore if you remove them. You must have the courage to choose the first way. On the other hand, the second way only make your journey long and painful. But it all depends on what you want and where you are. Agile is not about practices, it’s about mindset. And this is very true for Agile HR or talent management as well. 

In agile organizations…

The more agile you become at the organizational level, the more flexible and dynamic is the team structure and the more difficult is to say what is the position or role. The more agile becomes the way you work, the higher need for transparency is created at every level. We can see what every person is doing and can challenge them and give feedback. Any employee can join any initiative but with all responsibility towards the organizational purpose. As nothing is hidden, it’s in a way controlled by everyone. Emergent servant leadership is the key part which links everything together and makes sure it creates harmony instead of chaos. Such environments are ready to make all salaries transparent and let employees be part of the decision. To be fair, not many companies got there, so you don’t have to do it all tomorrow. But you can still bet inspired 🙂

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.

Do we need CEO in Agile Organization?

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

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

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

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

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

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