How do you expand agile product development in large organizations?

To successfully bring agile product development into large organizations, you should embrace a common framework such as SAFe, LeSS, Scrum@Scale, or Nexus. This shared framework creates a common language and culture, ensuring your product strategy aligns with the organization's goals and enabling the adoption of agile practices across teams

The most important aspect of implementation agile product development is to understand the why? "Speed to value" - How can an organization continuously deliver value to customers in an iterative and meaningful way. Once the organization gets this concept the next step is to "personalize agile methodologies" to how the org is structured. The biggest reason why I see organizations failing to do this successfully is by not taking an iterative approach but attempt to make big drastic changes that cause too much chaos. Defining success of implementing this methodology is also extremely important. There is no one size fits all solution here.

I find some frameworks not good at tall but SAFe is specially extremely problematic. It professes sensible values but then paradoxically implements processes and structures that hinder true agility. Among the various 'scaling frameworks' available, SAFe stands out as the epitome of misinterpreted and incorrectly implemented Agile principles. It's important to scrutinize this framework, even if only to identify what pitfalls to steer clear of.

Don't force-fit frameworks. You should not try to force fit an agile framework into your company if it doesn't fit your culture. Instead, it would help if you started by understanding agile development principles. Once you understand agile development principles, you can adapt them to your company's specific needs. There is no one-size-fits-all approach to agile development, so you must find what works best.

One of the biggest challenges in a large organisation in terms of scaling agile methodology is actually outside of product and tech! Ensuring that decision makers and business leaders can adopt an agile mindset to enable quick decision making to enable development teams to be able to continue to focus on the right things at the right time can be a massive uphill struggle The only advise I can give is try to think ahead as much as possible - giving time for business decisions to be made rather than hoping you can expedite and rush through at the last minute.

A common misconception of empowerment is that it starts from the bottom and goes up. It's actually the other way around: the top needs to accept and enforce empowerment, so teams understand they have the permission and responsibility to own their outcomes. The currency of empowerment is communication: the more teams manage up, the more comfortable will be a management team at empowering them.

Firstly, fostering a culture of agility is paramount. This means top-down commitment, encouraging experimentation, and embracing failure as a learning opportunity. Secondly, cross-functional teams with diverse skill sets must collaborate seamlessly. Effective communication and transparency are non-negotiable. Thirdly, scaling agile requires robust tools and frameworks tailored to the organization's unique needs. Finally, continuous feedback loops and customer-centricity are vital for ensuring that agility remains at the core of product development. In a world where adaptability is key, large organizations must embrace agile methodologies to drive innovation and meet evolving customer demands.

While empowerment is crucial, we need to remember that "constraints drive creativity" - we don't just want to tell our teams to come up with the goals on their own! And, we don't want to be fully hands-off; we should be regularly providing insights & expertise where our teams need it. As leaders, it's our job to set direction and to specify which kinds of customer problems we seek to solve. But, once we've set the problem, we should let the team run with ideation ("how will we solve the problem?"), validation ("how do we know that our solution might solve the problem?"), and instrumentation ("how do we track whether our solution is making progress in solving the problem?").

To expand agile product development, it is necessary to empower the team by fostering a culture of trust and open communication. Once team members have a clear understanding of their roles and responsibilities within agile frameworks, they can be provided with the training and tools needed to excel. Experimentation, risk-taking and continuous improvement should be encouraged through regular retrospectives when identifying areas for improvement. The team should be empowered to make decisions and prioritize based on customer feedback and business value. Encouraging the team by celebrating their successes and, most importantly, leading by example and providing unwavering leadership support for agile transformation is essential.

Agile product development is all about empowering teams to get stuff done, without getting bogged down in bureaucracy or red tape. It allows them to take risks and experiment with new ideas because they know they have the support of the organization behind them. But what happens when you're working in a large company, with lots of different teams? How do you empower everyone to get things done? You have to give them the right tools.

Expanding agile product development in large organizations means committing to continuous learning and improvement. Embrace a growth mindset that encourages learning from both failures and successes. Regular retrospectives, reviews, and experiments are vital to gather insights and implement best practices organization-wide

Governance and oversight increase should correlate with team size, communication axis and range of topics. Small teams, with direct communication in an MVP, early traction environment require little oversight. This allows them to operate quickly with flexibility. Large teams, where communication breaks and might lead to wrong decisions, require more complex oversight and governance. Making this explicit, as well as the inputs and outputs of decision-making is key.

Keep in mind that stakeholders are not "monolithic" - they have unique preferences, and a one-size-fits-all governance model across all stakeholders tends to create pain! Instead, treat your stakeholders as customers. Interview them. How often would they prefer to be kept in the loop? What kinds of info do they absolutely need to know? Which kinds of info is a distraction to them? I've personally found that big room "status update" meetings with 20+ people tend not to drive meaningful action. Instead, we can work in concentric circles. The most critical partners should probably sync weekly. Executive leaders should probably get info every 2-3 weeks. Cross-functional partners should probably receive info every 2-3 months.

Traditional, top-heavy governance structures can stifle agility, so a shift towards a more adaptive, decentralized approach is crucial. This involves clear roles and responsibilities, empowering cross-functional teams, and emphasizing self-regulation. Additionally, regular audits and compliance checks should be integrated into the agile process to ensure alignment with organizational standards. Striking the right balance between flexibility and governance is challenging, but it's necessary to achieve sustainable innovation and efficient product development in large, complex organizations.

Governance is an issue at all large companies and probably always will be. In order to not get bogged down by governance, it is essential to make sure all stakeholders are kept informed throughout the process. If all stakeholders are on-board as you move through product development or other phase, there is less likelihood that someone will have an issue with your product or that you missed an important piece and have to rework something.

A “customer-centric” feedback structure that involves those closest to the customer and those closest to the product capabilities is critical for rapid learning. No one wants to build something customers don’t care about and every customer despises a product packed with features they will never use. A thoughtful Feedback Program will aid in this every time.

Especially in large organizations, integrating customer feedback not only optimizes the product but also fosters trust and long-term relationships. By aligning our agile processes with real-time customer insights, we achieve faster time-to-market and products that resonate deeply with our target market. For organizations looking to enhance this engagement, I recommend establishing a dedicated feedback channel where customers can directly communicate with product teams, streamlining the feedback process.

To involve our customers we are using Grabee to get feedback from them, to make sure the product we're creating is actually what they want and need. This also helps us understand their pain points, which helps us focus on specific features that might not have been obvious before. Give them a voice and they will love your product.

In agile product development, involving customers is akin to crafting a pizza together. Like a pizza chef who invited customers into the kitchen to choose toppings, taste ingredients, and toss dough, agile teams engage customers to understand their needs, gather feedback, and adapt swiftly. This collaboration results in a "customer-approved" product recipe, ensuring a tastier and more successful outcome! ????

The important principle of involving customers is understanding why doing this will be net positive to your decision-making process. Often teams think they know enough, and they can move faster if they just focus on building, but often this isn't true. You might be building quickly, but in the wrong direction. Turning around might be slower than the time you invest getting to know the right direction to take. Make your process of involving customers lightweight, build quickly, test against them, and course-correct often.

I found learning and improving continuously to be one of the most crucial parts of agile product development. Other than regular retrospective sessions, 1-on-1 sessions with key representatives of the team from designers to engineers can work wonders. Focus on listening to them first before discussing solutions that can help both stakeholders be more effective and efficient together. This approach helps build trust, give a sense of ownership, and encourage them to give more contributions during bigger retrospective sessions.

"Learn and improve" doesn't only apply to expanding agile product development! It applies to every initiative & process within any org, big or small. And, it applies to every working relationship we have, whether it's with our managers, our direct reports, our technical partners, or our customer-facing partners. In my coaching practice, I generally see that product managers tend to approach "learn and improve" from an individual perspective - it's a good start, but we're not just responsible for our own development! As product managers, we're responsible for our teams & processes, not just ourselves. Running team retrospectives, gathering group feedback, and driving team action items is what differentiates great PMs from good PMs.

Having done agile in a few places, key lessons is that any framework needs to localized to the organisation in a way that helps the organisation move faster and more effectively rather than adopting new processes just because it's in a framework they read somewhere.

The most important part of Learning and Improving is on retrospectives, where Product Managers are running customer discovery on the clients of their processes: the team. Use this time to understand how to make the machine that builds the machine better. PMs need to be pro-active at owning the improvements, accepting the feedback, and celebrating the changes. Engineering and Design need to contribute with clear process reviews, and a goal to make the team performing even better. It's a joint effort.

“Fail Fast, Learn Faster” When failures occur, view them not as setbacks but as opportunities for learning and growth. Share stories of how they led to important insights and improvements. Document lessons learned, best practices, and successful case studies. Create/maintain a central repository of knowledge where teams can access and contribute to this collective wisdom. This knowledge hub serves as a valuable resource for continuous improvement.

To lead by example, I keep the following quote in mind: "it's easier to ask for forgiveness than to get permission." It's our duty as product managers to be proactive! Wherever we find the opportunity to be more customer-centric, and wherever we find the opportunity to empower our teams to drive autonomous decisions, we should act on those opportunities even if it's not yet "cleared" by leadership. Even if these opportunities are small, it's better to secure small wins now than to wait on big overhauls later. By taking action now to solve pain, we can quickly rack up small wins that demonstrate the power of agile. That way, we're armed with compelling narratives when sharing about agile product development with other team and functions!

I agree with Clement Kao below and adding on here. Celebrating the wins, regardless of their size, helps call out the incremental value part of the process. It's also an opportunity to "Lead/Manage Up" with senior sponsor to advocate with other senior stakeholders. They can use these outcomes and be an advocate by educating others about the incremental/continual value additions.

One of the most important aspects in the role of the Product Manager is that of educator. A significant part of your role is to communicate change, show a better world, explain what good looks like, and act accordingly. Culture is what everyone does when nobody is looking, and building a strong product development culture is about empowering everyone to be a Product Owner, not just what their official title says.

It is of utmost importance, regardless of your position in the company hierarchy, to always lead by example as a Product Manager. I once worked at a company that urgently needed to accelerate its product development due to intensifying competition. The adoption of agile was pivotal, yet the teams resisted as they were accustomed to traditional methods. To alter this culture, I began by wholeheartedly embracing agile principles - yes, principles, not frameworks! These include customer focus, collaboration, transparency, and feedback - emphasizing feedback, in particular, fostered open communication and bolstered collaboration.

As one who is enlightened you need to be able educate your team about agile principles, you play the role of inspiring and guiding the team, advocating for Agile's benefits,how it can lead to a more adaptive, customer-centric, and innovative culture.

In my opinion, one must adopt a common framework that defines the artifacts, roles of agile. On top of that, a common framework can help you establish a shared vision, culture and language among cross-functional teams and stakeholders. One must try below mentioned: - Actively Support Training Courses and Certifications. - Lay Out Agile Processes in simplified manner - Develop a Working Product Backlog and Ensure Refinement at Regular Intervals - Develop a Collaborative Culture that Promotes Self Organization. - Minimize Iteration Duration from 4 Weeks to 1 Week - Implement Scaled Agile Framework (SAFe), ART (Agile Release Train) and work in Cadence. - Adopt Large-Scale Scrum (LeSS)

Teach everyone what Agole is. Make it fun. Do an offsite, so everyone understands the bones of the system. Then check in quarterly to stay on track… Especially the first year!

Any time we want to drive change within an organization, we have two levers that we should pull: 1) Demonstrate the benefits of this change 2) Reduce the pain & costs of this change To expand agile product development, we should first identify a couple of internal wins and compile a handful of external case studies to demonstrate the benefits of agility. Then, we should share the specific narratives that are most likely to convince each stakeholder group, whether that's engineering, design, sales, marketing, etc. Afterwards, we should actively work towards minimizing pain. What are the key concerns that people have when moving to agile? What are some ways that we can incorporate their concerns into our change management plan?

Many people view Agile as merely a process, but it's more than that. Agile is a mindset, and we've got to start there.?? Why Mindset Matters ?? An organization with hundreds of employees cannot flip a switch and instantly become agile. People across different levels need to adapt and shift their thinking. Agile is about responsiveness, adaptability, and delivering the most valuable product possible. This philosophy must be integrated into the organizational culture to succeed.

Aside from adopting a common framework, knowledge exchange about best practices when putting those frameworks into practice between teams/departments is essential. In addition, to scale agile product development, it is crucial to involve business stakeholders in the process/steps, for example you can invite them to customer workshops or share insights from the user testing sessions and how those insights shape the thinking behind the product decisions made.