Scrum Transformation Journey

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.

Scrum Transformation

 

Technical Scrum

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.

Scrum Mindset

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.

APPENDIX: Top Agile Experts

(as many people ask about who to hire for agile transformation and the quality of Agile Coaches, here is a short paragraph about this)

There are generally two groups of experts in the Agile world. Trainers and Coaches. Each group focus on the same field but from a different angle. The most recognized are Certified Scrum Trainers® (CST) and Certified Enterprise Coaches (CEC) both linked with Scrum Alliance. Both groups represented top world experts which are proved by highly prestige certifications issued by Scrum Alliance.

The CST – Certified Scrum Trainers deliver the certification training such as CSM – Certified ScrumMaster, CSPO – Certified Scrum Product Owners to name at least two most well-known certifications. They are experts on agile transformation, and very often they are experienced coaches.

If you are looking for a Certified Agile Coach (CAC), make sure you are looking at the Scrum Alliance CEC and CTC’s which are the second group of agile experts. Together with CSTs mentioned before, Certified Enterprise Coaches – CECs are a great help for your organization on your Agile transformation journey while the CTCs – Certified Team Coaches are a great help at the team level. They are all top-notch experts with deep Agile and coaching experience. The ScrumAllinace’s key mission is sustainable agility and keeping the quality bar high is one of the most important aspects they take care about. Any of the above certifications (CST, CEC, CTC) are the great choice for your agile transformation.

AgileNEXT podcast

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.

Enjoy the listening.

My new book: The Great ScrumMaster: #ScrumMasterWay has been published by Addison-Wesley

The Great ScrumMaster: #ScrumMasterWayAt 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.

The Great ScrumMaster: #ScrumMasterWay by Zuzana 'Zuzi' SochovaIt 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!

Agile Leadership

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.

Modern world is complex

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.

Cynefin framework - Complexity

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.

Agile Leadership Model

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

User Story as a Card

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.

Product Backlog Example

When I teach Agile and Scrum classes, people often ask for Product Backlog Example. In order to start, you don’t need any complex tool. You can start with paper index cards and if you like simple Microsoft Excel or Google Sheet.

The minimum Product Backlog you need can be as simple as the card for each functionality (one column in the Excel):

Automatic beer selection for the party
Choose new beer to taste
Order favorite beers again
Recommend expensive beers

As I wrote in the previous blog about User Stories, the most common way how to define Backlog item is User Story. In that case you might want to add name for fast reference (however when you are using index cards you usually don’t do that and visualize by underline or color some important part), and if needed add conditions of satisfaction to the back side of the card.

Name
UserStory
Conditions of Satisfaction

Automatic selection
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.
Jon can impress his friends by selection of all different tastes of beer selected from micro-breweries across the world.

New beers to taste
As Jon I want to see beer catalog so I can choose the some new one to taste.
Jon can see different tastes directly from the catalog page and don’t have to go into beer details.

Favorite beer order
As returning customer I want to see my favorite beers, so I can order them again.
(keep empty – conditions of satisfaction are optional).

Recommend expensive beers
As Store Owner I want “Berrer” recommend expensive beers so we increase our profit.
Customers are not feeling under the pressure to spend too much.

If you like you may also add a few optional fields like ID, Estimate, Epic, and Priority(which can be used to sort your Backlog in Business priority order). They all fit the index card space, but if you like to use any tool, it may look like this:

ID PBI Estimate Epic Priority
234 Automatic beer selection for the party 20 Order 1
556 Choose new beer to taste 8 Order 15
123 Order favorite beers again 3 Order 40
89 Recommend expensive beers 5 Profit 50

That’s it. As you see you don’t need any complex tools to handle your Product Backlog. Paper index card or Excel sheet is more than enough to take care of “deep enough” Product Backlog and to define clear Product Backlog Items. So don’t make it more difficult than it is.

Only estimate when it makes sense

Many Scrum teams are asking at the classes how shall we estimate Backlog Items / User Stories? They seem not to be happy with my reply that you don’t need to estimate at all in Scrum. I try to explain. Estimates can be useful. But in that case something has to happen as a result of the estimation process. I give you few examples of such good situation:

  • Based on the estimate Product Owner decides on priorities. From the two same value stories we prioritize the smaller first as that value is cheaper.
  • Based on big effort estimation we talk about how we can split the Story so we increase the ratio (value/effort).
  • Based on the estimation Product Owner decides not to invest into that Story and remove it from the Product Backlog.
  • We had a good discussion during the estimation process which results in common understanding of the functionality (sometimes all team members feel they understand it, but once we start estimation – for example Planning Poker – we find out that we all have a different functionality in mind).
  • Learn some useful insights from other team members about it. I.e. that testing is going to be very difficult, security is a huge risky issue here, etc.

If nothing from above is applicable, and you only use it to fill estimation box in your tool, you may stop wasting your time.

Finally to estimate when the release will to be done you can better use number of stories done per Sprint than any estimates = guess.

Product Owner is an investor

Product Owner role is usually more understandable for companies that the ScrumMaster role. After all, companies have someone responsible for the product or business. So that’s the candidate. The problem starts when we deep dive into the role understanding and find out that Product owner shall not only understand the business but needs an authority to say “NO”. If you don’t, we mostly end up being late, with stress and low product quality.

How the Product Owner shall decide on priorities and how shall they know when to say “NO”? Overall it’s simple. Apply simplicity rule. It’s already in the Agile Manifesto as one of the principles. ‘We maximize the work not done.’ It has its roots in the research saying that 60% of a successfully delivered product is never or rarely used. So why do we keep investing into those features. Isn’t it waste? It is. But it’s hard to say no, so Product Owners keep prioritizing those features. Instead they shall act as investors and evaluate if the expected benefit will be paid off. If yes, do that. If not, let’s start a conversation or a negotiation with the customers about what else can we do to help them with what they need. The functionality they asked for are just one option how to achieve it.

Who is the great Product Owner?

  • The great Product Owner is an investor – imagine you would invest your own money into functionality you prioritize for the next Sprint.
  • The great Product Owner must have an authority to say NO.
  • The great Product Owner must be good at communication, always search for another option how to deliver maximum value to the customers with least possible effort.
  • The great Product Owner shall understand that your customers (internal stakeholders, users, … ) have wishes. Those wishes often contradict with each other so you can’t make them all even if you have unlimited resources. It’s up to you to decide where the highest value is, and skip the rest.
  • The great Product Owner must have business knowledge about the product and understand the customers – it’s not a technical role.
  • The great Product Owner shall have a time to spend with the team to build good relationship with them, and to make sure your team understands the purpose of the product/release/Sprint.

If you don’t have all those, don’t worry. But eventually that’s who you shall become as a Product Owner.