Scaling Up: Why Organizational Alignment is Critical and Tips for Achieving It

In this webinar, founder and CEO of Net Objectives, Al Shalloway, addresses the cost of misaligned teams for large and growing organizations. Al discusses how to make iterative improvements to your organizational structure, resulting in easier management of complex enterprise processes and helping you deliver faster.

This session provides a deep dive into:

Achieving agreement on the priority of portfolio-level initiatives
Aligning technology with portfolio plans
Getting to business value faster by managing work-in-process (WIP)
Shifting from a project mentality to a product mentality

WATCH THE RECORDING

For continued conversation with Al, please join and post questions to the Agile Product Management group on LinkedIn.

Q&A WITH AL SHALLOWAY

Thank you for asking great questions during the live session! Here are Al’s responses to several that we weren’t able to address.

Q: Our company recently posted a job opening and describes our culture as “…Fast-paced, ever-changing, and collaborative.” I had to stop and think – How does culture cause teams to be aligned or misaligned within an organization?

A: Culture can have a big impact on whether or not the company rewards individuals and/or heroes. If it does, it will tend to hurt alignment. But one must first understand what culture is – a reflection of the management policies of the organization. If you are interested in this topic, you should read Why Not To Focus on a Company’s Culture.

Q: How can I create buy-in for a tool to help us align on, prioritize and manage work throughout my organization?

A: Before talking about any tool, one must understand the relationship between improving an organization and its use of tools. Many companies jump into using a tool to fix their problem. Their logic is that if they can set up the tool properly, people will then follow an effective, well-defined process. Unfortunately, this assumes the tool is doing the right thing. The reality is that companies need to first figure out what is needed, and then have the tool fill that need. To get buy-in for a tool, you need to show people how it will create visibility to lower the waste your current process is creating.

Q: Should team members be able to see what’s lined up at the Portfolio level?

A: This is actually a very important thing to do. It’s possible with a tool like Planview AgilePlace, but most tools aren’t set up this way.

Q: How do we align on WIP (work-in-process) limits?

A: Decide on WIP limits through experimentation. First, create a board in a tool like Planview AgilePlace that shows the workflow – so you can see where things are backing up. Then, set your WIP limit at those points – being a little smaller than where they are now. If you end up having “bubbles” in your workflow (that is, people being ready but nothing in their queue), then your WIP limit is too low. You may be interested in this Planview AgilePlace webinar on setting and managing WIP.

Q: My C-levels are stifling us with Command-and-Control leadership, but I think they’d be more effective at scaling Agile if they followed a Servant leadership approach. How can I get them there?

A: Servant leadership should be about looking to see what is needed and providing support for people. It does not mean taking orders from the teams. Leadership needs to create the environment within which the people who report to them can work more effectively. If you start to talking about servant leadership to folks who have historically done command-and-control, they will likely feel they no longer have a place and even if they did, do not know what to do. You might find this blog interesting: The Importance of Leadership and Management In Agile.

Q: What is your take on SAFe (Scaled Agile Framework) for growing Agile organizationally?

A: We are gold partners, a contributor to SAFe and I’m a former SPC Trainer. So, of the defined methods, we like it the best. That being said, we don’t use it out of the box, so to speak. We consider the use of MVPs/MBIs to be essential, and their importance is not explicitly called out in SAFe. Furthermore, the decomposition we discussed in the webinar is different than the epic -> features -> stories of SAFe. So, when we do SAFe, we tend to overlap the product management concepts discussed in the webinar on top of the methodology.

As the contributors 4 years ago to SAFe in the areas of ATDD, TDD, and Kanban at shared services, we tend to be a bit ahead of their annual releases. My point here is that one should truly use SAFe as a framework, adding and extending as needed. The key aspects of SAFe that we like are that it takes an holistic view, appreciates Lean, appreciates management, and has a solid planning event that is needed for large organizations. You can learn more about tuning and extending SAFe to meet your needs here.

We have an alternative approach to SAFe where we start with a framework tailored to our client’s needs that incorporates the good things in SAFe, but focuses on business value delivery and agile product management. In doing that, we find it is easier to adopt for an organization that wants to change. In some organizations, only a pre-packaged approach will work, and then we like to use SAFe.

Q: You mentioned numerous ways you’ve approached iterative development, such as Scrum, XP, Lean, SAFe, TDD, ATDD, and emergent design. Can you elaborate?

A: This could take a book to answer, but let me talk about what I consider each of these tools to be for, and how I like to think of them.

Scrum and XP: I consider Scrum to be a very good team approach that has been oversold as a framework that is capable of working beyond the team. Scrum and XP are mostly different from each other in that XP incorporates technical practices (such as TDD, ATDD and emergent design) and Scrum does not. Scrum and XP both use iterations to build in stages.
TDD and ATDD: TDD provides better design, code quality and automated testing of the code from a functional perspective. ATDD provides clarity on requirements and enables defining the desired behavior at a high level and refining it over time. For more information on ATDD/TDD, check out Built-In Quality with Test-First. Although part of the Tuning SAFe webinar series, it is pretty much independent of SAFe itself.
Our own approach is what we call “team-agility.” Although we have been using this for years, we are just now writing up a more formal definition. You can see the start of that here.

Lean is pretty much the foundation for what we do at Net Objectives. I discuss SAFe in the answer to another question in this blog. You can get more information on both SAFe and emergent design at our webinar resource page.