Scaled Professional Scrum with Nexus
In Scaled Professional Scrum (SPS), participants will scale Scrum simply within the Nexus framework. I highly recommend that organizations consider taking this class as a group. It covers how teams could be structured and how to implement the Nexus framework within your teams’ structure. Executives, agile transformation leaders, Scrum Masters and Developers could attend this class together. This is an end-to-end class, from how we should be structured to how we work together. For example, we discuss the need to plan shared sprint planning across all Scrum teams.
Executives who have Scrum team members in their chain of command
Scrum team members
Scrum Masters and Developers
Agile transformation leaders and agile coaches
This class is for:
Too many organizations stifle value delivery with siloed teams. I am not exaggerating -- much -- when I say it’s tragic when an organization starts with great intentions and then hampers value delivery with unnecessary structures.
Don’t fall for the big-box consultants who sell you the idea that you can silo teams to the nth degree and expect them to work together to manage dependencies magically. It. Doesn’t. Work.
Subdividing complex work is risky… so subdivide as little as possible. Keep it simple. If you have three or more Scrum teams working together on a single Product, Nexus can help your team manage dependencies and improve communication.
If multiple products exist in your organization, do you need to scale across products? Let’s discuss it!
Why Silos Stifle Value
“Great Learning Experience! I truly enjoyed Ms. Iqbal's course. She provided valuable information from her extensive experience in the industry. She even provides opportunities for students to utilize their knowledge and real-world practice to share with future students. I look forward to taking future classes with her.” - Marcia.
Case Study: How Restructuring and Nexus Training Skyrocketed Performance by 300%
I once worked with an insurance company with about 60 developers and testers supporting a claims processing system. The teams had been organized by leadership. One team focused on claims auths matching, another on claims processing, another on invoicing, and so on. It seemed like a good idea. Each team had a specialization and a Product Owner to ensure they focused on the highest priority work.
The leaders looked at the bigger picture. They determined that their product was not claims to auth match but claims adjudication overall. They identified a single Product Owner to set the Product Vision and goal and be accountable for the Product Backlog. Then, they allowed the teams to determine how to organize themselves to deliver that product. Management asked that teams be cross-functional and able to deliver any work in the Product Backlog.
It quickly became apparent that each team needed the others to deliver value. The auths team’s changes impacted the claims processing team, and the invoicing team needed the claims processing team to implement changes so invoicing could meet its targets. Throughput slowed to a crawl as competing priorities gridlocked teams. Customer satisfaction—and employee satisfaction—plummeted.
The organization began to question whether Agile was a good fit. I was brought in to do an evaluation.
Next, I trained the teams in Nexus. Not just the Scrum Master but all team members received Nexus training to understand the purpose behind the Nexus framework. Finally, the teams selected a Sprint cadence and started Sprinting.
The result was astonishing. The value delivered by the teams soared by 300%. Lead time decreased by over 50%, and customer and employee satisfaction improved dramatically.
Why does this work?
It works because, in Nexus, all team members focus on a single Product Goal. All team members focus on resolving dependencies and working on the highest priority work. They don’t fight among themselves to get their work done first. They work together, laser-focused on customer outcomes. The Product Owner doesn’t need to negotiate dependencies with other Product Owners. All the Scrum teams work together to identify and remove dependencies by getting the right team members on each Scrum team. When that cannot be done, they determine how best to resolve and manage dependencies.
Scaling Scrum poorly can introduce several risks and challenges:
The risks of scaling poorly
Everyone loves to geek out about Scaling. Organizing other people is very satisfying (hint: letting them organize themselves is better!) But remember, scaling has its risks.
When leaders decide to scale, if they adopt a command-and-control approach, they can eliminate all the benefits of an Agile approach. Empowering the teams is the best way to deliver value, including empowering teams to select their team structure. Self-organization can lead to higher employee satisfaction and increased value delivery.
The command-and-control approach to scaling disempowers teams. This often happens when organizations silo their teams too narrowly. Teams have too many dependencies on each other; they’re internally focused rather than externally focused.
Loss of
Agility:
Siloed teams or poorly defined products lead to communication breakdowns. This reduces customer focus. A team focused on resolving internal dependencies is not focused on whether the end product provides value to the customer.
Communication Breakdowns:
When teams can’t work together well, this causes technical debt and low quality. Teams request work from each other rather than collaborating. This leads to frustration, low quality, and failing organizations.
Quality Compromises:
Sometimes, organizations trying to keep teams focused and “busy” can break down teams so small that they feel fragmented and unable to coordinate to deliver value. This leads to frustration, unnecessary wait times, and some teams working on low-priority work just to stay busy.
Resource Fragmentation:
Scaling well
Scaling well is about keeping the simplicity of Scrum while adding just enough structure to enable the teams to organize themselves around value delivery. Sign up for our next Scaling Professional Scrum class to learn how to scale well, or contact Rebel Scrum. Our Product Definition workshop is an expert-guided discussion to help your leadership team define products to deliver value.
The command-and-control approach to scaling disempowers teams. This often happens when organizations silo their teams too narrowly. Teams have too many dependencies on each other; they’re internally focused rather than externally focused.
Increased
Complexity:
Teams siloed and suffering from a command-and-control epidemic can quickly become overwhelmed by increased complexity, lack of support, and unclear direction.
Decreased Morale:
Poorly scaled Scrum can result in delayed deliveries, decreased product quality, and a failure to meet customer expectations. Customer dissatisfaction almost certainly leads to a loss of revenues and reduced customer outcomes.
Customer Dissatisfaction:
