Welcome to the Home of Scrum!

What’s up awesome people. I hope you had a great week and ready for the weekend. Starting from today, I am going to start a new series on my channel which I will call the 2 minutes FAQ series. In this series, I will answer the frequently asked questions that I have received whether in my Scrum.org Professional Scrum trainings or when I am engaged in the community meetups in just two minutes. The first question that I will answer in this series is: Can one person be both the Scrum Master and the Product Owner? Do you have any question that I most likely can answer in 2 minutes for this series? Just leave a comment down below and let’s see if your suggestion can make it to the next video. See you until my next video. Stay safe and Scrum On. {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/Lq8AAqRLEb4.jpg?itok=dKwXJ4Re","video_url":"https://www.youtube.com/watch?v=Lq8AAqRLEb4","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]}

These Sirens take advantage of the lack of understanding of what business agility is trying to change and lures unsuspecting C-suite executives into parting with their cash for what is effectively someone else’s business process. They are changing their entire organisation, not because of a business challenge, but because they are told to. The Siren song of SAFe The lure is strong! They can spend a few million dollars and pow, their organisation is agile, and our business is saved. They make sweeping changes to their lexicon and organisations of their business. We have installed agility! SAFe is a fictitious beast that looks cute, but is really dangerous and deadly. I’m not saying that SAFe did not work, or that some organisations don’t get value from it. Just like traditional tayloristic practices, many organisations were able to thrive in spite of the choices that they made. Even the US Airforce thinks of SAFE as rigid and prescriptive framework Many large organisations are waking up to this reality and are evolving instead of transforming. Transformation implies an end, a final stage, and the reality of today’s businesses is that nothing stays still for long. Organisations have a lot in common with the animal kingdom. Animals evolve to fill a niche and thrive until that niche changes and they can either evolve again or die. In the past evolution of companies and the changing ecosystem of niches were slow, giving even the largest organisations time to adapt. However, those days are gone now. The world is changing faster and faster and your organisation needs to embrace evolution. You need to be able to change to take advantage of new business opportunities as they arise and to do that you need a level of business agility that may astound you. Fundamentally, the main “goal” of Software development is NOT to be « SAFE », it is to INNOVATE and CREATE. You do not create by not taking risks… Scaled Agile Framework is just Taylorism with an Agile lexicon I talk often of the tyranny of Taylorism and the rigidity that it has instilled over many generations and constant bombardment of this is the way this should be done. This rigidity of the “best practice” or “we always do it that way”, or “we can’t do that here” is a symptom of that old thinking that was designed to manage disengaged factory workers. SAFe® for Lean Enterprises 5.0 SAFe does not change the thinking in the organisation, in fact, it solidifies rigidity by saying “this is how you do agile”. Thats the very antithesis of the intent behind the agile movement. You cant take someone else’s framework that worked in their organisation, like SAFe or Spotify, and install it in your organisation. You end up with fake agile, false security that you are embracing change while enshrining in the bureaucracy of the “way that we do things here”. Scaled Agile Framework is just replacing one bureaucracy with another. Meet the new boss, same as the old boss. Originally posted as Many organisations are lured to SAFe by the song of the Sirens on naked Agility with Martin Hinshewlood.

What does Scrum Product Ownership have to do with Dinosaurs? We typically say that Scrum Masters get to herd cats. But Scrum Product Owners actually need to learn how to ride a Dinosaur! With the click-bate established, what does that even mean? I've been using a visualization that people find useful for understanding the relationship between the various Lean/Agile requirement containers. Some people call the full model a dinosaur. Others are reminded of the snake who ate an elephant from "The Little Prince". (I'm sure there is a good connection to elephant carpaccio somewhere in here ...). In this article I'll explore this model and connect it to the stances of the Scrum Product Owner. Identifying a Unique Value Proposition A lot of teams and organizations expect their Product Owners to be a mix of the Story Writer, a Backlog Manager, Project Manager, Subject Matter Expert or a Gate Keeper. Sometimes they're even asked to be a requirements Clerk. These stances can be easier and familiar but when these are the expectations and when this is the stance that the Product Owner assumes, It's hard to deliver value with Scrum. In the PSPO-Advanced one of the first preferred stances we talk about is the Visionary. The Product Owner as an entrepeneur. This vision will be based on customer and market insights. As a Customer Representative you'll use techniques such as Design Thinking, Empathy maps, Value Proposition Canvases and Jobs to be Done to create a vision that's grounded in understanding the customers. You'll identify a Unique Value Proposition - the area where your product/service will be unique. The Minimum Viable Product (MVP) Very quickly even while assuming the stance of the Visionary, you need to also wear the Experimenter hat and that's because this Unique Value Proposition is just an hypothesis that needs to be validated. So the next step is creating a Minimum Viable Product (MVP) to test your hypothesis. This is focused on your unique value proposition but typically also provides a little bit of "Table stakes" features just to make sure it is "Viable" as a product. Evaluating your MVP Hypothesis Your MVP is also a hypothesis. It might be good enough to find Product-Market Fit or not. The case where each potential customer you engage tells you "This is great but in order for me to use it I need X" and X is different for each customer/user is shown below. This shows you are not in a Product Market Fit yet. At this point you'll need to be very careful not to fall for the trap of mistaking the Customer Representative for the Customer Order-Taker. The fact that potential customers are asking for something doesn't NECESSARILY mean your product should include it. It's ok to evolve your vision for the product based on validation but saying YES to everything even if it's all over the place is probably not gonna create a great product. These will be tough decisions but an effective Product Owner is also a Decision Maker (also known as the Tough Decisions Maker...) Pivot? If on the other hand, you are seeing more and more requests for the same capability you didn't include in your MVP then it makes sense to revise your Customer/Problem/Solution Hypothesis. You essentially are executing a Pivot. You are building MVP2 focused on the new hypothesis based on recent Customer Development learning generated by the previous MVP. Growth Stage Let's say MVP2 is successful and you are seeing real traction of early adopters. You want to increase growth and are looking for deeper penetration of your early adopters as well as bringing on new clients some of them beyond the early adopter's crowd. Based on feedback you've been collecting and your product management research you have a couple of areas that can potentially bring this growth. Some of them, by the way, extend your unique value proposition and some of them make your current product more robust. As your product grows, your team and ecosystem will grow. You'll need to assume the Product Owner as Collaborator and Influencer stances as well - working with new stakeholders, partners, a larger team and maybe multiple teams working with you on the same Product via the same Product Backlog. Steady Growth with Minimally Marketable Features In the case of areas with a strong indication of value, you might go straight for Minimally Marketable Features (MMF). Finding the minimum piece that can start bringing in growth. The aim of the MMF is to bring in value. It assumes high certainty that there is value in this area and that we know what the product needs to be to provide this value. The reason to break a big feature into smaller MMFs is mainly time to market and the ability to bring in value in many areas, always keeping your option to move to another area and provide value in it rather than focusing for too long on a single direction. An indication that you are working on MMFs is that when one is being shipped you feel comfortable working on the next MMF in that area. As the Visionary Product Owner You'll continue to provide and communicate an updated Value north star for the Product. You'll be a Customer Representative who is also a Decision Maker for which direction it makes sense to focus on and when does it make sense to move on rather than continue to invest in an area where you're seeing diminishing returns. Experiment using MVFs Even with an established product sometimes you remember that a Product Owner is an Experimenter. Sometimes its not clear whether a feature really is marketable and valuable. In these situations your hypothesis is centered on a feature rather than your product. You have an area with high potential but also high uncertainty. The way to deal with it is to build a "pioneering" feature - the Minimum Viable Feature. The minimum feature that can still be viable for real use and learning from real customers. If you learn that the MVF has hit gold you can develop more MMFs in that area to take advantage (if that makes sense). If not, you can pivot to another approach towards that feature area, or at some point look for alternative growth path. Essentially the MVF is a mini-me version of the MVP. Voila - The Scrum Product Ownership Dinosaur! There you have it. The full model. Essentially my point is that you grow a product in uncertain markets by attempting various MVPs. Then once you achieve Product-Market Fit you mix MMFs and MVFs depending on the level of Business/Requirements uncertainty in the areas you are focusing on. While MVPs/MMFs/MVPs are atomic from a business perspective (you cannot deploy and learn from something smaller) they might be quite big from an implementation perspective. If your organization positions you to be a Clerk, Story Writer, Manager, Project Manager, SME or Gate Keeper you won't get far trying to rider this dinosaur. You'll have a much better chance is you can switch between being Visionary, Collaborator, Customer Representative, Decision Maker, Experimenter and Influencer - the effective stances of the Scrum Product Owner (Which we cover in the PSPO-Advanced workshop) Authoe's Note: This blog post is an update of an article I wrote ages ago - weaving in the Product Owner stances which are a perfect fit in my opinion. Yuval

In light of the new normal and the last 20 years of technological progress, we need to re-define co-location as we no longer need to be in the same room as each other to get the 80% of communication that is non-verbal. If we are participating in an online event, we should try our best to keep our cameras on so that we can all read those non-verbal queues. 49 People in Microsoft Teams TLDR; If you are participating in an online event you should be transparent and commit to being open & respectful by having your camera on and engaging the topics and outcomes at hand as best as you are able. While we show commitment to our fellow participants by keeping our camera on, we should in turn respect a participants need to sometimes turn their camera off. Just as you would not take a phone call in a meeting and disrupt everyone, the same social conventions for meetings should be respected. Let folks know in the chat, turn your camera and mic off, return when you can focus again. If you are unable to use the camera due to bandwidth it may be better to attend an in-person event. Note: Rules are for the guidance of wise people and the obedience of fools. Co-location defined The idea behind co-location is that with 80% of communication being non-verbal we need to be able to be in the same room, space, to be able to read each others body language and facial expressions. Physical Team Room Have you ever been able to tell exactly what the car in front of you will do next when you are driving? When I was a teenager I was in the car with my grandfather and he said: “You need to keep your eyes on all of the cars so that you know what they are going to do”. I scoffed at that idea, but then he said: “See that car, it’s going to change lane”. I scoffed again, but then looked on in incredulous wonder as the car moved. I could not understand how my grandfather knew, but now that I am a drive I do the same all of the time. -Jessica Baez Calderin, Strategic Director, naked Agility with Martin Hinshelwood When we are driving we have a learned understanding of driver intent that is built over years of driving experience so that we know when the car in front is going to change lane even before the signal, and especially when they don’t. Car visual indications We look for micro-changes in the driver’s seated position, the road position of their car, and the other cars around them. Maybe we also get some official and standard notifications thorough the brake lights and indicators; if they work. You unconsciously take no account the apparent age of the driver and the age and condition of the car. We process all of this together and as an individual driver, we partake in an intricate non-verbal dance of lane, signals, and speed that take us safely to our destination. Another example is my wife’s family is in Cancun, Mexico City, and Puerto Rico, as well as elsewhere. Every Sunday they have a family video-conference with between 20 and 35 people participating all with video and chatting away. Technology is awesome. This is like a physical team room, except we can also add the other 20% with verbal-communication as we engage in our activities. Awesome! Right. Well, it would be if many agile practitioners were not suffering from cognitive bias and stuck in the thinking that co-location means in-person. Yes, the Irony is not lost on me! This definition of co-location is over 20 years old and technology has changed a lot in that time. Co-location re-defined Its been 25 (1995) years since the first Scrum project and the average internet speed was 56kbps! Here is a list of the important dates since then and the average internet speed in brackets: 1995 – First Scrum project (56kbps) 2000 – First video Conferencing (280kbps) 2001 – Agile manifesto signed (280kbps) 2005 – First HD video (980kbps) 2020 – COVID (26Mbps) Today I, along with most folks in the technology industry, have internet speed in excess of 200Mbs. Today it is generally no problem to have both kids on Netflix/Xbox, and both parents in full HD video conferencing at the same time. What a world we live in. While we need to re-define co-located for the general usage of the word I have always used the following: Co-Location: Co-location is a complimentary agile practice where all members of the same Scrum Team work daily in the same room, within visual sight of each other. –Martin Hinshelwood: What is your perspective on collocation? This definition encompasses both in-person and virtual events as long as we can see everyone. We need to see folks express and posture to in order to gain a greater degree of transparency over what they are thinking, how they are absorbing the information and how we need to adapt the material to increase understanding. How do you expect the facilitator to understand what you as a participant get or don’t without being able to see you? 9 people in the same room who can all see each other in Microsoft Teams For 2020 I would like to update my own definition of co-location to be more inclusive of the virtual world that is part of the new normal. Co-Location: Every member of the team can see every other member of the team’s posture and expression. -Martin Hinshelwood, 2020 Participation requires Presence For any online event you should be just as present as you would be in-person, and to do that you should have your camera on as much as possible. This provides feedback for both other participants and the speaker. Online Event with only the presenter with Camera Do you believe that this group is focused? How would you know? As a participant do you feel empowered to call upon ML? Will they reply? Are they even there? These are all questions that can be easily answered by enabling the visual presence that is your camera. If you are uncomfortable with your camera then there are options available. I have used FaceRig which gives at least some of the 80% that is non-verbal while hiding your bad hair. £6 for FaceRig used to hide my home and bad hair If you are going to be participating in an organized event that will be held online then you should consider being somewhere with good bandwidth, with a usable background. Presence can also be fun! Conclusion With the advancement in video-conferencing, camera quality, and internet speed over the last 20 years since agility became a named thing, there is very little excuse for not having video-enabled, and to participate with your team, or any other group. Having your camera on enables as much as 80% more knowledge transfer between you and the other participants. Having it off inhibits high bandwidth communication. So if you are participating in a video-conference: Be respectful, and open with other participants, and use your camera. Give the event your full focus and commitment and pay attention or leave. Have the courage to participate and speak up. All of this together will create the transparency required by your host and co-participants to see your participation, how you are reacting, and modify the event to make it better. If you don’t want or can’t have your camera on it would be better for you and the facilitator that you attend an in an in-person event.