Stephan van Rooden

The product professional pyramid illustrates the need for a greater emphasis on strategic and tactical decision-making, leave operational details to the processes designed to handle them.

Why does a SaaS company send you invites to their product launch events? But why don’t we treat our colleagues with the same level of attention and service that we expect from external providers?

Effective stakeholder management is crucial for a successful product. By understanding their perspective, focusing on their success, and slowing down to bring them along, you’ll significantly improve your communication and collaboration. Remember, it’s about creating a shared vision and journey, not just pushing your agenda.

Product Managers and Product Owners often find themselves caught in the delivery drain, where their time and energy are consumed by the operational aspects of getting a product out the door. This focus on delivery not only drains their resources. But also forces them to operate on an operational level, leaving little room for the strategic and tactical thinking that drives real product innovation. To truly excel, product teams must shift their attention to product discovery. A critical yet frequently overlooked aspect of product management.

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.