Fredrik Wendt

A friend sent me an e-mail, asking me to summarize Nexus and the Scaled Professional Scrum class. Here's the gist of what I sent in return. Why Nexus? If you know Scrum, you already know the basic principles and most important things needed to scale Scrum: inspect and adapt cycles, and the importance of working software ("Done" Increment, at least once per Sprint). Nexus is a lightweight framework that augments Scrum so that transparency and accountability isn't muddled and remains clear in a scaled setup. What is Nexus? As many teams contribute to the same product, there's a high chance of running into integration challenges. Those consist not only of software, but also practices, tooling, infrastructure, skill set requirements and other "human-focused" integrations. On top of this, dependencies between teams and work adds to the same sort of challenges. The Nexus framework address this by adding a new role, the Nexus Integration Team (or NIT), and a new artifact, the Nexus Sprint Backlog. The NIT is accountable to make sure we always have working software, a Done, integrated Increment. They're typically a few representatives from all the Scrum teams in the Nexus, and assemble as needed to make sure things don't fall between the cracks. They also make sure all dependencies are visible and dealt with as needed. They strive to see to that all the work still happens in the regular Scrum Teams. The NIT is not an ivory tower construct, where people with their heads in the clouds tell the people on earth what to do: the NIT is constructed from the regular teams, "The NIT is simply a subset of us". The Nexus Sprint Backlog is added to make sure we manage flow of work in the Nexus, and that dependencies we could not get rid of before the Sprint are being handled. The Nexus framework makes Refinement mandatory, where it was a common, but optional, practice in one team Scrum. The reason behind this is simple: dependencies needs to be discovered early so that we can find ways to mitigate them. What does Nexus feel like? Just like when individuals move into a Scrum team, the Scrum team's goals becomes primary focus, and individuals contribute together to that goal to the best of their ability. They move from focusing on individual efficiency, to optimize the effectiveness of the team. In a Nexus, the same pattern applies. Sprint Planning in a Nexus becomes a Nexus Sprint Planning: we find the Nexus' Sprint Goal, that all teams then plan towards. It's common to use a big room planning for this, to make interaction between teams simple and easy, and help dependencies be dealt with as swiftly as possible. As all teams contribute to the same product, a shared Definition of Done guides all teams to understand what work is needed to complete Product Backlog Items. Daily Scrums are preposed with a Nexus Daily Scrum: we start by focusing on the Nexus' Sprint Goals, before we split out and plan how to best meet that goal. Same pattern as in Scrum: focus on the whole (effectiveness, value) before individual parts (efficiency). The Nexus Daily Scrum is not the only time teams meet to collaborate and work out obstacles, but it's a daily event allowing us to take a step back, look at the big picture and make sure we're doing what's most important. Refinement in Nexus is likely to happen several times, and at different levels of composition. One key aspect is to have cross-team refinement, in order to discover dependencies across team boundaries. Time is typically spent to see how we can make the dependency go away: re-architect the solution, slice differently, team up, borrow team members, ... Allowing teams to work without depending on activities or skills outside their team, is instrumental to having work flow in a Nexus. The Sprint Review, as it's centered around a product, doesn't really change. The facilitation of the event will likely be adapted to a format that enables many more people to participate, but as the Nexus only deals with one product, there is just one Sprint Review (not per team). The Nexus Sprint Retrospective is the regular retro augmented with two parts on the Nexus level: we start out by having representatives meet and share observations that they think involve or affect multiple teams. These issues are then brought back into all the teams' regular retrospectives. As all teams attack these issues, we're applying bottom-up intelligence and representatives meet back to select actions to improve our ways of working, processes, etc for the next Sprint. Is Nexus a methodology? No, just like Scrum doesn't provide all the answers to all questions, the same pattern and rule is true for Nexus: it's a lightweight framework, consisting of the minimal parts necessary to support sustainable, complex software product development endeavours. You'll likely add practices that suits your context, and the class Scaled Professional Scrum introduces 50+ such complementary practices, based on experiences from implementing Nexus around the globe.

This is a list of 10 questions a Scrum Master may ask a Product Owner, in order to help coach them in their role. Of course, not all questions may apply based on your specific context. Not all Product Owners (PO) have the same definition of success, work in the same way, have identical Dev Teams, etc - you'll likely need to adjust these questions, or throw some away! Who are your product stakeholders? Who are the key stakeholders? What have you done in the past 5 sprints, to increase the chances of delivering a high-value product? How do you know if your product is successful and delivers high value? Would you be calm, letting the Dev Team(s) run the next two Sprints without talking to you? How do you know if you're doing a good job? What have you done lately to increase the value of the Development Team? Where do you want the product to be, in a year? What's your top concern that it won't be where you want it to be? What's your part in helping the Scrum Team achieve that goal? Given what you know today - if you could send a message through time, back to yourself 12 months back, what would that message be? What features should be removed from the product? How do you know they should be removed? How can you tell that you can't remove a feature? In what ways are you a bottleneck for the software development supporting this product? How can you mitigate slowing down the product's development? And now with some details added to each question. Who are your product stakeholders? Who are the key stakeholders? Not knowing who your stakeholders are severely limits your chances of knowing how to meet market demand, meet the needs of the stakeholders, and generally being able to deliver a high-value product! It may be two people the PO knows by name, or it may be a set of target audiences around the world. Whatever it is, the PO should know this. In addition, the PO should do everything in their power to involve key stakeholders in Sprint Reviews to increase feedback and chances of always working on the most valuable things. You may also ask which stakeholders the PO is targeting/focusing on right now, and how he/she came to that conclusion. What have you done in the past 5 sprints, to increase the chances of delivering a high-value product? Does the Dev Team have access to stakeholders as needed? Does the PO engage with stakeholders frequently? Does the PO act as a matchmaker between the Dev Team and stakeholders rather than a bottleneck? How are different needs from different stakeholders balanced? How does the PO track profit and loss? Does the PO ensure that user or stakeholder satisfaction is measured regularly? Does the PO keep a burn-up chart of "value points" delivered per Sprint, or is there some other way to guess or measure delivered value? How do you know if your product is successful and delivers high value? Interviews? Metrics in the product? Alexa index? More money from stakeholders? Happier employees? Satisfied customers? Competition going out of business? Would you be calm with letting the Dev Team(s) run the next two Sprints without talking to you? Does the PO clearly express their vision of the product, in a sufficient way for the Dev Team to do "the right things" themselves? Is the product backlog up to date, ordered and contains enough Ready items to have the Dev Team work on their own for two Sprints while the PO focuses on meeting clients, probing the market, etc? Would the Dev Team know which stakeholders to talk to about particular domain areas? Does the Dev Team understand the Product Backlog Items well enough to produce high-value product without constant - or even occasional - access to the PO (perhaps not forever, but at least for two Sprints)? Is the PO working reactively (short-term only) or proactively (long-term vision being played out through the ordering of the PBIs in the PBL)? Can the PO motivate short-term vs long-term focus, ie which is the right thing to aim for now? How do you know if you're doing a good job? Does the PO have any metrics to look at? How are they relevant? Money in the bank? More users? More leads? Fewer bugs (reported from in-production systems)? Only high-value features in the product? Decreasing code base? Anyone can cram things into a backlog and a product, endlessly building things that may prove useful or valuable (or not). A successful PO needs to know how to validate their business assumptions, or at least have an idea (put into practice) on how to do a quick and easy validation of business assumptions. What have you done lately to increase the value of the Development Team's work? The PO is the value maximizer - value in the product, and value from the work the Dev Team is engaging. Investing in teaching the Dev Team about the domain, the vision, clients and/or users - all of this increases the likelihood of the Dev Team building product that is "successful" and with little to no waste. Where do you want the product to be, in a year? What's your part in helping the Scrum Team achieve that goal? What's your top concern that the product won't be where you want it to be? Is the PO doing, or focusing on, the most important thing(s)? Out of all things the PO can do, are they focusing on the right things (like ordering PBIs, clarifying vision, involving the right people, making connections, learning about product perception in the market, etc). Is the Dev Team left on their own, ending up building things clients don't want? Should the PO work more or less closely with the Dev Team or stakeholders? Given what you know today - if you could send a message through time, back to yourself 12 months back, what would that message be? Another "are you improving your own work" and "doing the most important thing, helping your Dev Team and product to win" question. What features should be removed from the product? How do you know they should be removed? How can you tell that you can't remove a feature? Simplicity - the art of maximizing the amount of work not done, is essential. It is important to NOT build things which are not needed, but it's also important to remove features that have a negative ROI. Understanding what features are really needed, and how slim we can make them, is a critical skill for increasing product agility. However, understanding what features need to be removed is also a critical skill for product agility. In what ways are you a bottleneck for the software development effort supporting this product? How can you mitigate slowing down the product's development? The PO is a bottleneck position by design, at least if you interpret "being accountable for" to also mean "do the work" (which is a misconception of the PO role, by the way). What can you delegate? What can you direct? What other business side people can you get help from? Where can you get help becoming effective at X, Y or Z? Are you acting as a matchmaker between stakeholders and the Dev Team, or as a bottleneck and proxy conveying (and most likely accidentally distorting the understanding and intent of) messages going back and forth? Additional Resources If your PO is starting out from scratch, Lare Lekman's example checklist is a quick starting point to get some concrete action points from. In order to better understand the PO role, I suggest looking at Charles Bradley's The New New Product Owner article (there's also a video there where he covers most of the content, should you prefer listening instead of reading). What do you think is missing? These questions were just some that popped up during an exercise in a Scrum Master class of mine. In your context and work, what would you like to add or remove?