Stephan van Rooden

I believe there are three things you need to do regardless of the framework, methodology or program you are embracing with your organization.

Do you always hear the same people speak up when you present a new idea or when you ask for feedback? You might be dealing with an important voice here. The voice of the system! A voice any leader should (learn to) listen to. If you don’t? It will never go away!

Imagine this, you are at the weekly company meeting in a room of 60 people. All of them are co-workers who you have been working with for several years. You feel engaged and committed to the goal set by your company. 

When is a Scrum Team successful? Which criteria do you use to determine if a Scrum Team is doing a great job? From my point of view a Scrum Team is doing a great job if they deliver an increment with the highest valued features, with the best possible quality and they continuously strive for improvement. In this post, I will share my thoughts on a discussion I had with a Scrum Master recently on partnerships. I will not provide practical examples, if you are interested, take a look at Evidence Based Management and read this. The discussion started with the following question: Changing the Contract “Stephan, how do we, Scrum Master and Development Team who are hired by our client, Product Owner, change the KPI’s (Key Performance Indicators) in our contract to measure if we are doing a good job?” Without hesitation I replied something related to the statement I made above. However, the Scrum Master did not accept my answer. He said: Listen, in our current contract we get rewarded for every time we are within our initially estimated delivery schedule and if we stay within our budget. "How do we know, now we started using the Scrum Framework, we have done a good job?" Then I explained that by deciding as customer and supplier to start using Scrum, a lot more has changed then just doing some events and incrementally develop our solutions. Making this decision you have mutually agreed to move from a demand-driven approach a.k.a. doing projects. To a supply driven approach, delivering solutions. And by using Scrum, the Scrum team has a shared responsibility to deliver the best and most valuable solution to the customer. With this decision you both have committed to this goal, you both have a stake in the success of the things you do. You now are a Scrum Team and yes, each role has a different angle on how to approach this shared responsibility but you are in this together now. In this together The Scrum Master looked puzzled and replied: "But we are a pay-by-the-hour company! We just deliver highly qualified people, we cannot be held responsible for the value we deliver to the users? What kind of KPI’s do we need?" Yes, you deliver skilled people who bring in their experience and expertise to create a valuable solution. But to build the right things in the right quality in the right way they need to interact with the Product Owner (and Stakeholders) to figure out how to build the right thing? You need each other...right? "Yes!" You, as a Scrum team, can only be successful if you collaborate. So you need to figure out together if the thing the Product Owners wants is more valuable than the cost of the team. The client buys capacity from you as a supplier per sprint in the form of a Development Team. So as long as the benefits of the items delivered in a sprint exceed the costs you are on the right track. Send it back to the kitchen! I always compare a Development Team to the chefs in a top restaurant. They need the proper equipment to cook but how do you judge their performance? If the food tastes good. If it doesn’t I do not blame the waiter, I sent it back to the kitchen! The development team is responsible for delivering a high quality product.As a restaurant we are all together responsible for delivering a great experience with great food. "Quality is something we are responsible for?" Yes! Put that in your contract! But wouldn't it be great of you could create a contract that reflects the responsibilities of the entire Scrum Team? "Now you are being naive! That is never going to happen?" Why not? As long as you are only being judged by the quality delivered why should you care if it adds any value? Why do you do this job? To deliver high quality stuff that nobody ever uses? Or do you want to create something valuable that people like to use and is of good quality? And yes, that is a rhetorical question. Partnership I see a lot of client/supplier relationships using Scrum. When signing the contract they both say they engage in a partnership. But the agreements they make usually have nothing to do with being partners. A contract hardly reflects the image that we need each other to be successful and that we both care about the goal we try to achieve, if that is the case there is no shame in making money for both partners. That is why Scrum says nothing about having KPI’s between a Product Owner and Development Team since using Scrum implies a partnership where we all contribute to achieving the same goal. Soon I will elaborate more on partnerships and how I make my decisions when I am looking collaborations.

The Daily Scrum, or most of the time referred to as the "stand up." Probably the most well-known event when we talk about Scrum. An event that lasts no longer than 15 minutes and where the Development Team inspects the plan for the sprint and see whether this plan is still valid. That is it! Nothing more, nothing less. Nevertheless, there many thing that go wrong during this 15-minute event. In this post you’ll find, the most common problems during a Daily Scrum and how to solve this. The 'status update' consultation This is, unfortunately, the number one issue in most of the teams! Often it is the (project) manager, Product Owner or Scrum Master, to whom the team answers what the team has been doing and what they are going to do the upcoming day. Strange! Especially for these roles, because none of whom have an active role during a Daily Scrum. The purpose of the Daily Scrum is for the Development Team to inspect jointly whether the plan they have made in the Sprint planning is still valid. By sharing relevant information that may be of impact to the schedule the team determines the need to adjust their plan. It is up to the ScrumMaster to learn the Development Team how to do this. If there should be re-planned, only then it is useful to involve Product Owner in the discussion (in the case the scope is affected). These are some of the causes of this behaviour. 3 questions To get the information shared, many teams use the following three questions: What did I do yesterday that helped the Development Team meet the Sprint Goal? What will I do today to help the Development Team meet the Sprint Goal? Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal? The purpose of these three questions is to share the information that is relevant to inspect the sprint backlog and validate whether we as a team are still on the right track. Nothing more, nothing less. These three questions are not mandatory and what I often see after everyone has answered these three questions, is the team ends the Daily Scrum. But then you're not done yet! In fact, has just started! Now you have shared the information on which you can see, as a team, if you have to adjust. It is not about answering the three questions. It's what you do with the information shared! If there is nothing special to report, and it all goes smoothly then a Daily Scrum is done in just a few minutes! The Scrum Master that works too hard If as a Scrum Master you do your job well, you have not much to do. However, Scrum Master prove are not properly trained are very busy. During the Daily Scrum you as ScrumMaster have no active role. So, if you as a Scrum Master acts as moderator, the who’s-turn-is -it-to-speak-now-coordinator and tickets mover. Then, you are not doing a good job! People can organize those things themselves. As a Scrum Master you have to teach the team to understand the purpose of the Daily Scrum (inspect if rescheduling is necessary) and how they can do this no more than 15 minutes. Hardworking Scrum Masters are often cause more problems some of which pass in this post. So, Scrum Master, grab a cup of coffee and let the team organize themselves in these 15 minutes. So you have your hands free and you can keep busy with those things that are said (or not said!). Unanswered requests for help When a team is suffering from an overactive Scrum Master, questions with the (unspoken) request for help is most overlooked by both the Scrum Master and the Development Team. A small example of what I have experienced recently during a Daily Scrum when a new team member was speaking. This is what happened: Team member: "Today I want to work on this task (points to task), but I'm not sure how to approach it." Rest of the team, including the Scrum Master: "..." Team member: "I immersed myself in the subject but I doubt about whether this is the right approach." Rest of the team, including the Scrum Master "................" Team member: "It would be nice if someone could look at this with me." Rest of the team, including the Scrum Master "........................." Then the Scrum Master "That was it? Okay, next, eh Pete you? " At that point I confronted the team with what happened. Someone asks three times a request for help. It wasn’t formulated a question but it is indeed a request for help and no one responded. This was a hard lesson for the team, that does not help one another and the Scrum Master who was too busy to manage the 15 minutes to hang notes instead of listening what happened here. This is where a Scrum Master focus should be and what a Scrum Master must teach the team to recognize themselves. Lack of transparency Many teams use a physical board but what is often missing is inspecting the burn down chart. A practice which helps the team to monitor how much work is remaining and how the team is progressing to finish their work. Teams that use a tool like JIRA or TFS have this functionality at their disposal, but this is rarely inspected. What these teams often do, in addition to treating only 3 questions for the status update. is to individually inspect work instead of the feature that the team is trying to deliver. Both JIRA and TFS have filters that can sort a Sprint Backlog per team member and the tasks this person is planned to work on. If the team loses focus on finishing features and one is mainly concerned with optimal use of the available capacity, please watch this short movie. This also means less interesting discussions during a Daily Scrum. Because they are concerned with individual focus. Also it is easier for the team not to be transparent about the work you contribute to the Sprint Goal. Again, it is up to the ScrumMaster to confront the team with this behavior. By simply adapting the way we present information in such a way to provoke a different discussion. Day off/ Working from home Finally, the situation that a colleague has a day off or works from home. This often creates unnecessary problems in a team. Let me first state: working part-time or working from home is possible when working in a Scrum Team. However, a team must makes agreements on how to deal with it. I regularly see teams during a Daily Scrum that find out that the colleague has a day off. Or he/she works at home without sharing this information. Then they try to figure out how far the colleague has progressed and two colleagues need this work to continue. Incomprehensible that a team does not know how to overcome this while the solution is simple. Situation 1: Colleagues works from home. Great, so they probably call in using Skype or just by phone. Thus, there is still information to be shared and to move tasks on their Scrum board can probably be done by someone else from the team. Situation 2: Colleagues has a day off. The team in such a case, determine together that in case someone has a day off does not pick up a crucial task without being sure that it can be completed. Or colleague makes sure that at the end of the day, at least one person from the team knows what has been done. In this way, the information is always known in the team and the colleague does not have to be disturbed during the day. This has nothing to do with the role of ScrumMaster or good use of Scrum. This is just purely being a professional! A long post about a seemingly simple and quick event when working with Scrum. Do you recognize this struggle? Of do you want to avoid such situations before you are going to start with Scrum? Then the Professional Scrum Master training is a must! Please subscribe now!

This summer, during the Olympics, the Euro Soccer Championships and the Tour the France, while cheering in front of the tv, I noticed something in the way teams perform. And it worried me. Even more because I see the same thing happening in organizations. Why did the English soccer team fail against Iceland? How come the Dutch field hockey team didn’t win a medal? And what does this have anything to do with Agile Coaches? In this post, I will explain what to look for in an Agile Coach and why not to hire them full-time. A system or framework will not make you a winner! Everybody has heard about it, many you have seen it. The Icelandic team beat the English soccer team. Were they better soccer players? No, they were not, and they knew that. However, they did operate as a team and were not bounded by an elaborate and complicated system. The systems and plays are taking over the creativity and craftsmanship of any team. When things turn sour, many teams that rely on a system are unable to break away from it. They have been brainwashed and probably punished by the coach not to break away from the system. Take a look at this scene from Dutch professional basketball coach, Ton Boot. During practice they have a limited amount of passes to get to the other side of the field and score. Everybody needs to have touched the ball and the amount of passes leaves no room for error. Listen to what he says when they fail! [embed]https://www.youtube.com/watch?v=vdtEw_4byPg[/embed] Why do they do this exercise? This has nothing to do with using a certain offensive play. It has to do with the ability to operate as a unit and dealing with the situation (which is always different). How do you, or your Agile Coach, deal with the Scrum Framework? Do you treat is as a system? Just an implementation of some rules and followed up by punishing any deviation from these rules? This works fine up to a certain point! As soon as you run into problems or your organization is under great pressure to deliver, people need to be able break away from these rules. Teams need to understand the values beneath the rules to get things done. The ability to let go of the rules and teaching teams to act from values is important for an Agile coach to understand and act upon. Deal with Super Chickens! In a highly competitive and complex environment we can no longer rely on a single superhero. One person cannot carry the entire team. You need a great balance in a team. Why? Take a look at this interesting TED talk by Margaret Heffernan: [embed]https://youtu.be/Vyn_xLrtZaY[/embed] So, what do you do as an Agile Coach when you run into a Super Chicken? Again, Ton Boot is showing a great example of on boarding a new team member, a Super Chicken. [embed]https://www.youtube.com/watch?v=UjQfhpNzvT0[/embed] (Some parts are in Dutch but I am assuming you’ll get the point) What would you do in this situation? We all have been in such a situation throughout our professional life but how often have we dealt with it? Most organizations are too afraid to face this super chicken since they are too happy they finally have a talented superstar. But if you do not have this super chicken put his interests in line with that of your company they will destroy your company. An Agile coach should be able to identify super chickens and be able to confront them with their behavior (or even better, teach others how to do this). Need some inspiration? Read these books ‘ 5 dysfunctions of a team’ and ‘ The Phoenix Project’ A coach should not be in the spotlight I truly believe in this statement. A coach should not be the most famous person of the team. If this is the case, something is probably wrong. A great coach should not have to teach players or individuals on how to do their job. They know how to hit a ball or how to write code. Otherwise you need a trainer. A coach teaches people to work together, to give feedback to each other and to operate as a unit. In my training courses, I often use the movie below. I love it, it shows the behavior I expect from Scrum Masters and Agile Coaches. [embed]https://www.youtube.com/watch?v=3Tv2iHlMhmM[/embed] As a coach you teach people to work together, to think for themselves and from time to time ‘punish’ bad behavior. Don't hire an Agile Coach full-time! Being an Agile Coach is not a full-time assignment! Whenever, I get requests to help an organization as Agile Coach, I never take a full-time job. I don’t see the added value and neither should you! Being an Agile Coach comes with a great risk of overdoing your job. You are hired to make the organization more Agile so you will probably try to coach the sh*t out of the teams. Literally! However, you don’t have to intervene continuously to make an organization improve continuously. As a child my parents had this nice fireplace in the middle of the room with a cast iron chimney. As a kid I was drawn to the fire and wobbling towards to fireplace to put my hand on the chimney. My parents prevented it every time (thankfully). However, I did not seem to learn from it, so one day they decided, when the fire already was out and the chimney wasn’t that hot anymore to just let it happen. It hurt, but I wasn’t injured but I never ever again walked toward the fireplace ever again! So sometimes you need to step away, not be there to maximize the impact of learning. For how long do you need to employ a coach? On average this is around three years for a sports coach. Ton Boot works for 3 years with a team followed by a sabbatical year to recover, improve and learn. The Agile coach also has an expiration date. From my experience, the effect of a single takes wears out after 6 months. After this the assignments needs to change significantly or the agile coach will have to move on. Yes, there are exceptions, even in sports as there are in Agile Coaching but like I already said, these are exceptions. So what to look for in an Agile Coach? A person who: Knows the systems but does not cling to it Knows how to identify and deal with Super Chickens Understands you do not want to hire them for more than 3 days a week for the next 6 months Want to know more or do you share a different opinion please comment.

What really makes a transformation of your organization successful? Which elements should be in place? Which complicated framework for scaling agile should I choose? I tend to feel disappointed when trying to think of the number of organizations which actually succeeded in such a transformation. We, the Dutch, should be absolute rock stars when it comes to scaling agility given our rich nautical heritage. Let me explain. Oil tanker In the past couple of years I have heard the following statement a lot:” We want our organization to transform from a big oil tanker to a fleet of small sailing boats.” And yes, that would indeed be a nice metaphor when attempting to describe a typical large-scale introduction of Agility. These statements are always made by management teams. Let me be clear, there is nothing wrong with this statement, I like it actually quite a bit. But I could never think of a clear recipe for making it work. While contemplating about this my thoughts brought me back to one of the best summers of my life. And there might lie some insights. Sailing Camp When I was in high school we went sailing for a week during our summer holiday. This camp was a self-sustaining camp, we cooked our own meals, had a schedule for cleaning and we trained our own ‘skippers’. At the end of the week we closed off by demonstrating our skills with a parade called ‘Admiraalzeilen’ which can best be described as synchronized sailing. This parade works as follows. All boats sail equally fast, make the same manoeuvre at the same time, all under the direction of one skipper called the ‘ admiral’. It looks something like this: [embed]https://youtu.be/kcZhKyv1fGg[/embed] As you might imagine this is extremely difficult to master and has some prerequisites to make it work. First, let’s dive a little into the history. Admiraalzeilen Already in the 12th century merchant boats have used this technique to better withstand attacks from pirates or warships. In the 17th century, ‘ Admiraalzeilen’ became an extremely popular in transportation and warfare. Because of ‘ technological’ innovation, boats became larger, heavier and received more firepower. This made strategic maneuvering more complex, but to outmaneuver the enemy this became necessary. The ability to be able to manoeuvre fast and flexible led to a new way of controlling the fleet, called ‘ Admiraalzeilen.’ A fleet would be divided into smaller squadron with boats of the same type. This would make sure that differences in speed would prevent a squadron from breaking up. Each squadron was appointed an admiral, typically the first boat, which would decide the course and the maneuvers to be taken. Even today, large aircraft carriers, operate in a way with seem similar to this approach. How to successfully S(c)ail Each boat needs to be roughly the same size and type In order to make this work the entire squadron needs to be the same size and probably the same type. If you create a squadron consisting of one large boat and multiple smaller ones. Making a turn at the same time is impossible. Try turning around 180 a smart and a limousine at the same time, they will never be done at the same time and will definitely not be in the same place. Also controlling the speed of different boats is difficult, even if you have the same type of boats speeds differ but the difference would be controllable. So looking into your own team, please make sure they are roughly the same size and operate in the same value chain. This would make maneuvering and managing speed more easy. Each boat needs to know how to sail Obviously, having a squadron with an Admiral being the only one who knows how to sail will never work. So training is of the essence here. This is why Scrum is a great way to teach people how to ‘sail’. It is the common language that everyone understands like in sailing. Everybody on a boat should know what ‘Starboard’ means, what a ‘ Mainsail’ or ‘Jib’ is etc. For a small boat it’s easier to learn, imagine if you want everybody to know how a frigate works. Good luck! Each squadron needs an admiral Each boat has a captain (product owner) deciding on the direction. But a squadron needs an Admiral, responsible for deciding the direction of the squadron, come up with a strategic battle plan. A responsible job since the Admiral needs to take into account the capabilities of the Squadron, the surroundings of each boats etc. When does it fail? Change course at the time As you can see in the movie above the boats manoeuvre slowly, it takes time to execute a change of direction, it will slow the boats down. If you change direction too often each boat will end up just floating and no boat has any control anymore leaving them vulnerable to the tide of wind. And when these elements take control of your squadron you will end up stranded or on the bottom of the ocean. Maneuvering should be thought of carefully and after each maneuver boats needs time to regain their velocity. Ignoring the environment of the entire squadron Nothing is more frustrating that having an Admiral deciding on a manure that is only considered to work for the first (few) boats. During our sailing camp we numerously ended with a couple of boats in shallow water because the admiral forgot that making a turn will not have the boats end up in the same position, but each in a different position. That is also why you needs skippers on a boat to keep thinking for themselves. In such cases it would be better to break away from the line then to ‘lose’ a boat. Expecting it to work at the first try This one is too obvious but I see it go wrong many times. You will fail, a lot! So can have meetings until you drop but you only learn when you actually start doing it. As long as you make sure everybody knows how to sail you will be fine. I see organizations create comprehensive Powerpoint presentation. Being the result of a trillion meetings with expensive people to get it right the first time. Yes, there are tricks! There are good practices! But you should only apply them if you need them. having 15 boats do the same manoeuvre at the same time is difficult enough. Why bother them with all kinds of scenarios that will never become a real life situation. The wind, tides, currents and even people are different and act different every time! Are we Scaled Agile rock stars? No, we are not, apart from our nautical heritage, we, the Dutch are also famous for something else. ' Polderen', we tend to lose ourselves in trying to have everybody involved in agreement with the direction we are going. So we end up in countless meetings where we talk a lot but hardly every decide. That is the primary reason we, the Dutch, are still struggling with scaling Agile. But we do have to potential to be rock stars! Check out Nexus and find out it's impressive that a technique already proven in the 12th century still works!

This week, co-creators of Scrum, Ken Schwaber and Jeff Sutherland, released a new version of the Scrum Guide. At first glance, just a small paragraph on Scrum Values is added. But this addition may offer a larger impact and be an extremely useful addition for Scrum Masters. So, today during the first day of my Professional Scrum Master Training, I shared this new addition to the guide with the students. Their first response while shrugging: So what? Their second response, how is this different from the Agile values? And then they paused. This gave me the opportunity to elaborate briefly on what these values mean: Commitment - Being committed to the team and the sprint goal. So when you finished your work so check if you can help someone else in the team to help them meet the sprint goal. Focus - Eyes on the goal and not being distracted by personal favors, not even for the CEO, if it endangers the sprint goal. Openness - Being transparent on how the team is doing and being open about failure or difficulties you might run into. Respect - Sharing your knowledge within the team and embracing the professionalism from your team members. Courage - Being a professional to admit mistakes and move beyond your ego to change direction to solve complex problems. more on Scrum Values read this blog by Gunther Verheyen This resulted in an enthusiastic reaction from the group. So, the Scrum Values, in fact describe the desired behaviour of a Scrum Team? Yes, yes, YES! The new Scrum guide provides Scrum Teams some key elements of desired behaviour. This will help them to move from doing 'Mechanical Scrum'* to 'Professional Scrum'. This insight gave the students a boost of energy and looking forward to the second day of training to dive into the behaviour of a Scrum Team and how the Scrum Master can facilitate the team in showing this behaviour. Download the new Scrum Guide! *(just following the rules, and not understanding why you do things)

When do you estimate and what do you do when you need more time for discussion? In this third post of this series on Product Backlog refinement you will find some good practices on how to facilitate an effective and efficient refinement meeting.

In this blog series, you will get some good practices and guidance for having better, more effective and more vivid Product Backlog refinement