Let’s start with ‘Myself’ dimension. Each element of this dimension represented by a dice which you can roll every day of Sprint and choose the aspect you are going to take. The first dice is for metaskills. Scrum Masters shall be able to take the metaskills of teaching, listening, curiosity, respect, playfulness, and patience.
Teaching is embracing the wisdom, ability to advise people, be a good mentor. Your knowledge and experience on different frameworks, concepts and practices are your ground here.
Listening is a critical skill to be able to learn from the feedback and choose the right approach. We as human beings are not listening enough. Too often, we jump towards the closest solution and ScrumMasters are not any different. Good listening is a prerequisite of being a great facilitator, coach, and leader.
Being curious helps you not to take sides. Be open to different situations and solutions. Find creative and innovative ways of approaching things. Working with team and organizations is a complex task. It requires different skills in order to address the complexity.
Respect will help you to build trust and create safety environment. Respect different opinions, who knows what is right and what is wrong. At the level of a complex system, it’s hard to assess. Openness and transparency are your best friends here.
It’s going to be a long journey, so make it fun. Bring the metaskill of playfulness to your day to day work. Take the same approach as if you were playing the strategic game. It is just a game, so enjoy every single day of it, don’t get frustrated when you don’t win the first day. The good game shall take some effort to play well.
You have unlimited time as ScrumMaster, there is no hurry. You are not responsible for delivery, nor the short-term goals. Your goals can only be seen long-term when the teams are getting self-organized and high-performance. Only then people can see the ScrumMasters are doing the right job. You will never be finished, as Agile is not a destination, but a star on a horizon. There is always a better way, there is always a need for great ScrumMaster to guide us on our Agile journey.
When I first time decided to write my new book The Great ScrumMaster: #ScrumMasterWay I have a clear picture in my head of what I have to write about. I wanted to share what I learned on my ScrumMaster journey, offer you hints on how to avoid problems, bottleneck, falls during the way, and give you an advice on how to become the great ScrumMaster. To make it consistent learning path, I combined all necessary elements which must be used to successfully get to the great ScrumMaster journey into the #ScrumMasterWay concept. At the beginning of my writing, I had only independent pieces. When I started to write the book, the elements clicked together and created the coherent whole of the #ScrumMasterWay concept which I’m now presenting in brief at a separate website and in the Great ScrumMaster book: #ScrumMasterWay which has been published in January by Addison Wesley.
The concept is formed from my personal hands-on field experiences as a ScrumMaster and Agile enterprise coach which I got during my 15+ IT and Agile journey.
In the following blog posts, I’m going to introduce the core elements of the #ScrumMasterWay concept. The #ScrumMasterWay concept is shaped in two dimensions: ‘Myself’ and ‘The world’. The first dimension is dedicated to your own mindset, attitude, and personal growth. They help you to develop yourself as a person and become a great ScrumMaster. They consist of four building blocks: Metaskills, Learning, State of Mind and Leadership. The second dimension is dedicated to the outer world represented by your team, broader product group or the entire organization. The great ScrumMasters shall be able to work at all three levels of the world dimension and use a mixture of all different aspects of Myself dimension elements.
I hope the #ScrumMasterWay concept will help you to start your great ScrumMaster journey and help your organization to be successful in nowadays constantly changing the world.
As one of the CSTs – Certified Scrum Trainers – I’ve got a unique opportunity to travel around the world during the last two years and teach Scrum at a variety of businesses, organizational environments, and very different cultures. I must admit that Scrum is awesome as it is universal. You can apply it to software, hardware, marketing, HR, executive teams and be rapidly successful, significantly better, change the way of work and become the best of the greatest. The flip side of the coin is, that despite the easy way how Scrum is defined, there are still companies, teams and individuals completely failing to understand what Scrum is and therefore failing to implement it.
I draw this picture to illustrate that becoming Scrum is a journey. You can’t just do Scrum, you have to embrace it. You have to become Scrum yourself first. It’s often not that straightforward as we’ve been got used to the traditional processes throughout the history, but at the same time, this is the very best strength of Scrum. Once you master it, it becomes the part of your life. It’s not just a process, it is a way of living.
First, let me say explicitly that “Technical Scrum” is not Scrum. It only pretends to be Scrum. It’s a camouflage. However, it might be the necessary first step in certain organizations to move to the real Scrum. How do you recognize Technical Scrum? People “do” Scrum. They are looking for ways how to remain the same as they used to be. They are eager to get checklists of practices which need to be done, in order to do proper Scrum. Therefore Technical Scrum is all about estimations techniques, burn-downs, measuring velocity. The very important metric would be individual utilization, so they usually insist on time task estimates, capacity calculations, and time-sheets to be filled. They have identified new roles, but in reality, they just renamed the traditional roles and didn’t change the behavior. Scrum meetings are usually long and felt redundant. Managers use Scrum to micromanage. The overall team focus is on “how”. The team is not any team but a group of individuals working on similar items. The individual accountability matters. They are looking how to split responsibilities instead of how to collaborate to achieve the goal. Product Backlog is usually a to-do list where most things have to be done.
In the real Scrum, your team understands the mindset and they are “living” Scrum. They take it as the way how to focus on customers, how to innovate, how to collaborate. The estimates, efficiency, and utilization become quite unimportant, as they focus on delivering value to the customer and overall long term results. The first step here is usually “Team Scrum” where the development team becomes a real self-organized and cross-functional team which works together. The team creation process produces a huge trust internally among the team members but also externally to the organization. It’s the first tiny ‘snowball’ which afterward starts the whole transformation and creates forces to change how we run our business and how the organization itself is structured.
The “Organizational Scrum” builds on top of the values we experienced at team level – openness, transparency, and trust which leads the organization to be more business driven, flexible, and open to innovations. The business slowly starts to be picking up and the organization has to follow the rest. At this time, the snowball is big enough to attract the rest of the organization. At that time, you are truly Agile.
Such transformation can take years. It’s not uncommon that companies are falling back and restarting the whole initiative again. It’s hard. To succeed you need a good reason for change and courage. Eventually, every company has to change as the word is getting more complex and fast. The same way as industry revolution changed the way we were hundred years ago, the complexity of our current life is changing us now. To succeed in a long term, we have to be more flexible and dynamic – more Agile.
Thanks to AgileNEXT team – Daniel Gullo and Stephen Forte – for recording a podcast with me at Scrum Gathering.
During the session we discussed the following topics:
Scrum Master as Agile Coach, Kaizen in Scrum, Agile Brands and Scaling, Community Involvement, and finally my new book The Great Scrum Master which was published by Addison-Wesley Signature Series (Cohn) in January 2017.
At the beginning of the last year I finished my new book called The Great ScrumMaster: #ScrumMasterWay. At first I self-published it and the book was available for Kindle at Amazon and as a limited series in full-color printed version. I was very happy to see that the book was selling well and also that I got an excellent feedback from readers. My excitement was even bigger when Mike Cohn, one of the Scrum legends, accepted my book into his Addison-Wesley Signature Series (Cohn) and the book was published by this excellent publishing house in January 2017. Thanks, Mike. It was a lot of work and I’m really pleased to work with so many great professionals from Addison-Wesley (editors, graphics, language corrections) to achieve such a wonderful result – the book which I have now finally in my hands.
It was a long journey for me to embrace Scrum and write this book. Ten years ago, when I joined my first Scrum team as a developer, I didn’t like it much. It was an awkward way of working, I thought. I was just as resistant as most of my current clients who are at the beginning of their Agile journeys. It was something new and different. And however hard our Agile coaches tried to explain it, I didn’t really get it. Six months later I was appointed to the ScrumMaster role. Lacking any other experience than as a team leader and developer, I ended up being a “Scrum team assistant” and a bit later a “Scrum team mom.” It took me a long time to realize why Scrum is so powerful and that it is all about the ability to enhance self-organization.
Only then did I realize that we were all missing a good explanation of the ScrumMaster role. Later I described it using the #ScrumMasterWay concept that I’m going to share with you in this book and which finally gave ScrumMasters the answer to their most common question: “What will the ScrumMaster do once the team is self-organized?”
After coaching many ScrumMasters at companies and teaching a lot of CSM and CSPO classes, I can say that an answer like “Move to another team,” “Do nothing,” or “There will always be some work needed” is not good enough. ScrumMasters are lost in the same way I was lost at that time.
It has never been so easy to become a great ScrumMaster, so let me invite you on the journey and you can learn from my experience and mistakes. This book is the best starting point to embrace the ScrumMaster role. I hope you will enjoy reading it and will find it useful and easy to apply in your work and that you will become a great ScrumMaster too.
Finally, I would like to use this opportunity to thank Linda Rising for her nice words in foreword. Does that all makes you curious? You can find more details at dedicated book pages greatscrummaster.com. The book is now available at Amazon, InformIT, and Barnes & Noble Bookstore to name at least the few most famous sites. I hope that you would like it. I appreciate your comments and reviews and if you like it, please help me to make other ScrumMasters great by recommending it to your friends and colleagues!
As the world is getting more complex, organizations has to change to keep competitive. They must become more flexible, team oriented, self-organized. And as a consequence, the leaders shall adopt another approach to motivate people and lead the organizations to keep up the speed. Agile Leadership concept was created to help the leaders to understand the nature of the change which is happening in the business right now, and be able to react to the challenges which modern organizations brought in its all complexity. Agile Leadership concept is not about how to implement Agile, Scrum, Kanban, Extreme Programming, or Lean. You have people in your organization who can do that. The Leadership model is here for leaders, managers, directors, entrepreneurs, and owners to help them to sustain the change and be able to create Agile organization or become effective in it.
Organization is a complex system by itself as it deals with people and their behavior. There is no clear link between cause and effect. It’s a network of interdependent elements. It’s not predictable so the traditional approaches which expect predictability and consistency fail. It all worked until about 1970 as the world had been only complicated at that time. Nonetheless, a lot changed from that time. Globalization and Internet allows businesses to grow fast so the density of nowadays businesses is so huge and communication so fast that they involve each other all the time and cause doesn’t link to any predictable effect anymore.
The first step of the Agile Leadership model is “Get Awareness”. Awareness of the current reality, understanding of what’s happening around us, be mindful about the surrounding. Organization is a system which constantly sends signals. All we have to do is to be aware of them, notice them, and listen to them. The second step is “Embrace It”. It helps us to accept whatever is happening in the system without the urge to evaluate. Who knows what is good and what is bad. Our self-power is coming from our ability to gain enough clarity so it builds trust in the whole system. The third step is “Act Upon”. It uses the power gained in the previous step to influence things and change the system behavior.
To make it simple, in our Agile Leadership Program we guide you through those steps. Every change is difficult, and the change of ourselves is usually the toughest. However, the result will definitely pay off.
User Story is one of the most common formats how to write Product Backlog Item. It has specific format which forces people to focus on business value.
As a [user | role| persona] I want to get [functionality] So that I get [business value]
As an example of such User Story for my online beer store called “Berrer” we can write the following:
As Jon (busy manager with no time) I want to get beers selected by “Beerer” So that I can impress my friends by variety of rare brands.
It shall give us three different information – Who, What, and Why – which must fit together and once you read it to someone it shall create consistent story together. As you may have noticed the User Story looks at the functionality from the business perspective and is customer centric (note that customers are all user, stakeholders, other teams, … ). We never define how exactly it shall be solved, but describe the business impact we want to achieve.
Write Acceptance criteria was never good idea
Having that definition, companies are often missing the place where to write the exact specification. But there is none. It’s all about conversation. It should fit a small index card. Having said that, teams are still fighting and try to keep it as close as possible to the traditional detailed specification. One way how keep it close is to add detail as Acceptance criteria. It usually looks as checklist of all possible details you shall/shall not implement. It seems to be useful for teams who have limited understanding of business and product but it’s not. To give you an example of such Acceptance Criteria for the above defined User Story, it can look like this:
Beers from all continents
At least one beer from Belgium
Several small local breweries
One light, dark, Ale, Pils
As a result of it development team is not involved in the story definition anymore. They just take those points one by one and implement it. If it’s not working as we missed something, it’s not their fault but the Product Owners’. He shall have made the missing piece part of the Acceptance criteria. So let’s have a look to better solution.
Define Conditions of Satisfaction instead
As we said before, User Story is about conversation. It shall be simple, clear, and easy to remember. If you write well so it is small enough, there is no need for any additional information at the back side of the card. However sometimes you might find it useful to stress certain expected behavior / impact. In such case we turn the User Story card and write the Conditions of satisfaction. For the above defined story it might be:
Jon can impress his friends by selection of all different tastes of beer selected from micro-breweries across the world.
As a result of this the team is focusing on solving user problem instead of implementing what was defined before. The implementation usually starts with conversation. How can we deliver the more value with less effort? What is the minimal functionality we have to deliver? How can we address his needs? We need everyone involved, everyone interested, and everyone understand the overall business, personas, their needs and their dreams.
It may take bit longer at the beginning, but it’s worth investing the effort as the committed team which is living by the product can always come up with better solution then one Product Owner.
Writing Acceptance criteria is our legacy from traditional world, while defining Conditions of satisfaction is very Agile. Agile and Scrum is mindset. If you have it, it doesn’t matter how you write your User Stories because you already understand the fundamental difference. It’s about value to be delivered to the customer, instead effort, items delivery, and velocity. If you don’t, changing only the label won’t help. You would have to significantly change the way you think about Backlog items and that might be very painful and long process where User Story format with Conditions of satisfaction will help. I went through that change with several companies during Agile Coaching and it was always worth of the effort. If you want to get bit more practice, I also teach it at CSPO – Certified Scrum Product Owner class.
Agile Prague Conference, which I organize in Prague every year, has already been here for 6 years. We are sold-out again (the only way how to get to Agile Prague 2016 is to attend LeSS workshop). This time we were already sold-out one month before the event, which is going to be 12-13 Sep 2016 this year. But don’t worry. We don’t want to make it bigger next year. Our mission is to offer the best of the best speakers with hands on experience on Agile, Scrum, Kanban, XP practices, but also share experiences from leaders of Agile organizations with their transformation, Scaling, etc. We don’t want to grow, as the biggest part of the conference learning is hidden in conversation you can have with other participants and our creative thinkers – the speakers. In order to make it possible, we can’t be too big. I’m attending several huge events every year (Agile 20xx with over 2500 participants and Global Scrum Gatherings with over 1200) and compare the learning and experience I got there with small local events I’ve been speaking at (Big Apple Scrum Day (NYC), Scan-Agile, AgileSlovenia, ACE, … ). I like the smaller events better. It’s compact, easier to approach speakers, easier to reach into people again and build on top of the conversation we started before we all run to another session.
Every year we try to attract the best international speakers and bring their ideas and experiences to the Czech Republic. We are small country so it is very unique opportunity for our local Agile community to look at Agile in wider context. As the program is high quality and our conference is getting great references from past year audience and speakers, we attract more and more participants from Europe and other countries.
So if you’ve never been to Prague you can already mark the next year date into your calendars – it’s going to be Sep 11-12, 2017. We do our best to attract wonderful speakers for you again. If you are a speaker and you or your family never got a time to go for holiday to Prague, submit your talk next year and we give you awesome opportunity to combine conference and sightseeing all together. We offer a private guide to our speakers and their families (so they have a program with us while you are at the conference). You will not only have an opportunity to speak at one of the best Central European events but also can enjoy history, and local atmosphere with us.
Organizations are constantly evolving. In the 1970’s the most common organizational structure was the pyramid structure. It was deep, hierarchical, and full of power. Companies got strong bosses who lead such structure. Internally their approach was full of command and control, bureaucracy, and standardization.
Those pyramid hierarchical structures were not wrong in any way. They were the perfect solution to world industrialization and to the dynamics of business at that time. Most of the companies followed the best practices for a simple world, where problems can be classified as obvious, and applied a simple structure to address it. And it worked. Bosses got results. Companies started growing and became more successful.
The most common management tool was a carrot and a stick, because organizations believed that their employees are lazy slackers who can’t work without it. Most of the people were in a mood of tribal leadership 2 where the motto is “my life sucks”. Complaining all the time. Not happy, not motivated. Their only motivation to do something was driven by getting some bonus – a carrot, or because they were forced to – a stick.
Twenty years later, Organization 2.0 was here addressing the difficulty of the business world focusing on specialization, processes, and structure. Companies realized that the world is not simple any more, and the majority of problems can be classified as complicated.
As a result, they adopted complicated processes, focused on deep analysis, and invested in experts.
The belief in Organization 2.0 is that complicated problems need experienced individuals and detailed analysis. As a result, companies invested in learning and specialization. They began to grow. The work which used to be done by one person, now needed specific and dedicated positions. We’ve got a specialized department to deal with java, database, testing, architecture, analysis, documentation, customers, accounts, plans, and chair purchases.
Organizations are trying to create a process to describe everything, to have every possibility thought over. Companies create career paths and talk about motivation. They have spent months describing KPIs, but the more processes and specializations they had, the less responsibility and goal driven individuals they had. They were starving. They tried to cut on expenses, but that did not bring any long term success either.
So they dream about the previous stage, where it was much easier to manage resources. At that time, managers had real power. They could make decisions. They could force people to work. They could use the carrot and the stick. It was so simple – no need for committees, no need to call a meeting for every single detail. At that time, allocation of individual resources did not cost most of their time.
The pressure on individuals to make themselves more successful, better, and smarter than others was huge. “What if my colleague is be better in the performance review?” “What if I am not promoted in two years?” It leads to a culture that emphasizes own goals over the organizational ones. Most of the managers and experts live in the third level of the tribal leadership model, where they believe that “I’m great, but you are not.” So they treat their employees and colleagues with little respect or trust. This leads to the leadership style of “leader-follower”, where the managers decide, and the people below them just do the job. No initiative is expected. People just follow the process and do what is ordered.
Nowadays, when the world is not complicated anymore, neither Organization 1.0 nor Organization 2.0 can address its full complexity. We have realized that such complexity needs a very different approach that can keep up with business dynamics. The Agile environment brings Organization, 3.0 which builds on teams instead of individuals, on different styles of leadership, and on intensive collaboration through the dynamic network structure. We need to completely change the leadership style, create partnerships, enforce self-organization, enforce real responsibility and ownership, enforce trust and transparency, and build the organization as a network structure which is flexible enough so that it can effectively respond to change. Decentralization is taking over, and is bringing a certain level of autonomy to self-organized systems.
Instead of being a huge tanker, you can imagine the Organization 3.0 as a flotilla of smaller boats, going into the same direction, living in the same context, having the same values, but making some decisions differently based on the situation.
The Organization 3.0 is a true Agile organization. In order to build it, you need to apply a different leadership style of “leader-leader”, which supports growth of people, instead of “leader-follower” which is so common in Organization 1.0 and Organization 2.0. Hand in hand with this new leadership style, you need to create a culture of tribal leadership “We are great!” where the focus is not on the individuals but on the systems and teams.
Organizations are complex, as they have to deal with people’s behavior. People are not predictable. Every time we tried to make them behave in a predictable way, we failed. A modern Agile organization is built from people. It is a collaborative, creative, and adaptive network. It’s a sphere built from autonomous systems which are connected to each other, so they influence themselves but still keep consistent. Such a change of mindset is a huge mental challenge for most organizations.
So how to start?
– Help all people to become better leaders by applying the “leader-leader” leadership style, and build a culture of tribal leadership: “We are great!”
– Decentralize, build networks and communities.
– Allow autonomy in a well-defined context.
– Read my book The Great ScrumMaster, which is a guidebook not only for ScrumMasters, but also for leaders of any organization who want to become an Organization 3.0.
You can see my talk Agile Organization – Organization 3.0 at AGILEEE Conference 2016: