How do you apply Scrum to large or complex projects?

Scrum can be applied to organizations of any side. Here are few things that could help you: 1. Goals/OKRs: Define your high-level goals and break them down to work items that the teams can handle. OKR works great! 2. Feature teams: Eure that your scrum teams are feature teams for the most part - with T-shaped skill sets. There can be exceptions to deal with special needs such as data engineering. 3. Ceremonies: Make sure that the scrum teams conduct all the four required ceremonies. Yes, it includes sprint retrospective as well. 4. Scrum of Scrums: This is vital. Make sure that you have scrum of scrum meetings conducted at least once a week to manage dependencies and to escalate risks, when there are multiple scrum teams.

You should also consider whether or not Scrum is the best delivery method for the product. It's ok not to use Scrum! Scrum works best in complex environments, specifically when the team does not know how the product will be built (because technology is always changing) and the product requirements are unclear. Scrum gives plenty of opportunities for the team to gain feedback from stakeholders and make adjustments to the product as needed.

A very common situation is we force ourselves to implement agile for the sake of implementation. In the beginning, the roadmap might not be clear, but there should be a clear set of visions that will drive the whole team. This vision can be even simply written in a piece of paper, a simple document, a collaborative board and circulated within the team to align everyone with the expectations and the ultimate goal to achieve. After that implementing agile methodology gets easier, makes more sense and drives the whole team accordingly.

Before tailoring Scrum to a large or complex project, first you need to ensure that going Agile is the correct approach that best suits your project goals and desired outcomes (Waterfall isn't bad, it's just different). It's always good to pick best practices from various Agile frameworks that fit what you currently have, you don't have to stick to only one. Define your teams' structure, roles, and responsibilities. Break down the high-level features into Epics. Set your time-box, planning sessions (just enough to get you going), development, and release times. Ensure you're testing frequently. Scrum-of-Scrums, or Agile Delivery Team, both work just fine to have the flow going without interruptions.

I underscore the imperative of a well-articulated product vision. However I would also argue that it needs to be supplemented with a Product Goal that acts as an intermediate goal towards that vision. This can all be done during the first Sprint in Scrum. It acts as a North Star, aligning stakeholders and fostering a shared understanding among teams. Employing tools like vision boards or lean canvases facilitates crafting a compelling vision, thereby laying a strong foundation for value-driven, collaborative efforts throughout the Product Life cycle. Be wary of calling it a project though as project success is often defined upfront. Something that cannot be done when dealing with complex problems.

A first principle of any scaling framework is that the teams should already be practicing good Scrum before any scaling is attempted. Otherwise, this introduces a high risk of amplifying "noise" and whatever was slightly problematic within teams is now proliferated as potential bad habits across teams. To be clear, we should be focused on individuals and interactions - not simply "processes". It take time for teams to "gel". That rarely happens overnight.

In my experience, creating truly cross-functional teams can be difficult in large projects. It's tempting to create teams based on function such as hardware/software/electrical or frontend/backend/validation & verification. Ideally scrum teams are cross-functional in the sense that one team could deliver a fully functional product increment (aka a working piece of the product) at the end of the sprint. In this ideal situation, you'd want multiple teams with one team member representing hardware/software/electrical so that each team can work on a different feature of the product. Teams will still need to coordinate and collaborate in order to "glue" the different features together, however this delivers more value faster to customers.

The statement "Each team should have a product owner" doesn't apply to LeSS. In LeSS, there should be a single PO for the entire product, not a separate PO per team, which is considered an anti-pattern because in that case there is a lack of consistent vision, and inability to define priorities.

In my experience, Release Train Engineer plays a critical role in applying SAFe methodology in large and complex projects. RTE's bring together the cross-functional teams, facilitate PI planning, coach the SM, and help resolve impediments and manage risk and do much more. As RTE you are not expected to have answers but to help the teams find the answers by asking great questions.

The first question that should be asked when deciding to scale is why. Too often organisations decide to scale and use it as an excuse to constrain innovation or increase top down control. Instead, ask if small teams, working collaboratively would be a better way. Frameworks like LeSS tend towards this. As can properly managed Kanban processes. Rather than taking the safe route to Agile mediocrity.

Keep things simple. #YAGNI (You aren't gonna need it...) A simple checklist should suffice. For whatever reason, road mapping software sometimes takes on the shape of Gantt charts and creates unexpected expectations. The release criteria, quality standards, user feedback, business outcomes should already be understood and well-known from the PBIs. Leveraging a "single-source of truth" might be more advantageous than creating additional, external artifacts that must be updated and tracked separately. "Simplicity--the art of maximizing the amount of work not done--is essential." - 10th Principle, The Agile Manifesto

Or instead of going through all the Big Planning Up Front effort, focus on goal setting. Scrum introduced the concept of a Product Goal to provide the team a beacon to help them stay on course. This is broken up into smaller steps, sprint goals in an iterative manner. Don't plan too far ahead, in a Complex environment especially if you need to stay nimble, you should not tie yourself down with too many promises. promises you can't keep when a new or better opportunity comes along. Invest in Continuous Integration and Delivery to make the act of releasing actually a non-event.

After defining the release criteria, ensure that the release plan remains adaptable to accommodate any changes or feedback received during the development process. Emphasize continuous communication and collaboration between teams to ensure a seamless and successful delivery of valuable features to customers and stakeholders.

Critical Path: The product owner MUST be in tandem with the scrum team, sign off on the release schedule and attend backlog grooming meetings.

The backlog is an ordered list. Ordered, not purely driven by priority. Value, potential, risk, opportunity, innovation and size all play a part in defining what should be on top of the backlog. And that's the most important thing to figure out. What should we do next?! The rest of your backlog is a list of options. The order might change, new things may be added and existing things can be removed. Advanced practitioners use Hypotheses and Experiments over Requirements. They don't pin down their solution until they've proven one works. The backlog should be short, but sufficient. Too many items makes the backlog hard to manage and time consuming.

Prioritize the backlog by collaborating with stakeholders and product owners, ensuring that the most valuable and urgent items are at the top. Regularly refine and update the backlog to keep it aligned with changing project requirements and maintain transparency by making it accessible to all involved parties throughout the development process.

Within the various scaling frameworks, each one has its own distinctives which must be understood. For instance, SAFe prescribes a more hierarchical backlog approach. They also have a unified Product Backlog but still maintain a Team Backlog. The Product Backlog is derived from the roadmap that expresses the Business Vision. The Team backlog may include items that originate from the team itself. These can be enablers and also "vitality" maintenance items that are not explicitly considered within the roadmap. This should be leveraged as a "bottom-up" feedback loop and reconciled as dependencies, risks, or NFRs that are usually coupled to initiatives in a supporting capacity. One of the benefits of PI Planning is surfacing these items.

1 / 2 In ordering the Product Backlog, priority is a factor, yet multiple items might share the same priority. Regardless, a Product Backlog has one order. Ordering techniques ought to hone in on fulfilling the Product Goal and mitigating risks. Overemphasis on ordering could detract from value delivery—a core objective. Value maximization is attained through regular delivery of Product Backlog Items (PBIs), enabling frequent releases and validation of outcomes. The compass directing Product Backlog ordering should be a balance among achieving the Product Goal, lessening risks, and propelling towards a cadence of continual delivery and validation, steering the initiative towards maximum value realization.

We should differentiate between "teams" and "team of teams" more clearly here. For instance, reading this it could be interpreted that each team inspects and adapts their work separately. While this is true, the team of teams should also review the work and have retrospective events jointly with all the teams engaged together.

I always see some AI-trouble constructing this topics. Sprints are the heartbeat of Scrum, where ideas are turned into value. So indeed summing up the events ;-). But: " The teams should inspect and adapt their work and process during and after each sprint" ??! Eeh, there is no "after each sprint", a new Sprint starts immediately after the conclusion of the previous Sprint.

Releasing product increments early and often is what sets Agile apart from traditional project management methods. Using customer feedback and data to improve the product during development directly applies to the fourth Agile Manifesto value: Responding to change over following a plan. This is a simple idea but can be difficult to practice. The future of Agility relies on individuals who can empathetically listen to customers at stressful moments, such as when their work is on display during a Sprint Review. Coming from a place of curiosity is the best place to start this practice. If you struggle with this, try using the response "that's an interesting point of view". It allows you to receive the feedback without committing to change.

I am BIG on A/B testing because you get both high quality feedback with low minimal risk thus ensuring that development efforts are aligned with user needs. By focusing on real user feedback in an efficient manner, it promotes a more customer-centric approach, enabling the delivery of features that genuinely add value. This method is generally preferred as it minimizes assumptions and guesswork, ensuring that resources are invested in creating solutions that have empirically been proven to meet customer needs

Whenever we didn’t have enough time to create prototypes, we even conducted A/B testing with UI/UX designs and those results/data have helped us avoid many blunders and disasters. There are plenty of online tools out there to carry out A/B testing effectively among variety of user groups.

In order to define what it is that you should measure to validate value delivery look to your goals and your strategy. Derive your measures from your current goals and try to find "prove" that you have achieved a goal or moved towards a goal. Having a Vision and a strategy coupled with the goals will help you to identify the right metrics. Evidence based management is a great framework to help you with applying this on team level but also on organizational level. All of the metrics mentioned and things like OKR's fit neatly in EBM so it doesn't require you to change everything. It just gives you structure.

Ensure that team roles and responsibilities are well-defined from the beginning, along with an effective method for handling inter-team dependencies. Dedicate time for cross-team dialogues and coordination, as the true value to clients and stakeholders often emerges when the collective efforts of multiple teams are seamlessly integrated.

There are many Scaling Frameworks and Practice libraries out there. Your environment will be different from someone else's and therefore the solutions you're going to pick will be different too. This is normal in a complex environment. There are "good" practices, but no "best" practices we tend to say. Cause if there was a best, everyone would eb using it. As such don't try to cling too tightly to pure Scrum, nor try to implement everything in SAFe. Identify your problems, find potential practices that could help mitigate them and apply them in your environment to see if they help. If not, rinse and repeat. I see all the major scaling framework as great libraries of potential solutions to my problem, even of the framework itself isn't.

One of the key components of success in scaling agile software delivery is automation. This includes: 1. Continous integration and deployment/delivery 2. Test automation 3. Extensive use of Infrastructure as a Code approach 4. Automated monitoring and reporting 5. Integrated automatic code quality checks

The key to success isn't just about adopting Scrum; it's about how you implement and execute your project. Do your organization and team truly embrace an Agile mindset? Are they mature enough to adapt to Scrum's principles? These are the questions we must ponder. It's not about Scrum being a universal remedy, but rather about how we wield it to navigate the complex landscape of project management.