4 Things You Must Do At Scale

March 28, 2017 — Posted by Al Shalloway

This blog covers some of the ideas in the first session of our upcoming webinar series on Tuning SAFe. It's actually an adaptation of our Lean-Agile experience into the SAFe model so it will be useful for anyone attempting or doing Agile at scale.

The first session, called 'Rationale of SAFe', discusses the four key elements of an Agile transformation. These four issues must be dealt with regardless of the approach you take:

  • A central product backlog that consists of chunks of consumable value
  • Teams working together in a coordinated, synchronized manner
  • An agreed upon workflow across a value stream
  • Leadership that creates the context for teams to work autonomously in an effective manner

Lean suggests that we eliminate delays in workflow across our value stream. This implies, at a minimum, that we take an holistic approach and that we work on the most important items in a manner to get them finished quickly. Bottom up approaches often don't work because sit is difficult to create a high-level view from the team level. However, this high-level product view doesn't mean the command and control we see in non-Agile companies. We still need our teams to self-organize around the needs of the organization. This is leadership's/management's role - creating an eco-system within which teams can work this way.

We have all heard the effective vs efficient story - build the right thing (effective) and build it right (efficiency). Building the right thing means we want to build only items of high value (this will be the topic of the second session in the series). And since we want to deliver it quickly, any part of the organization that is involved in building it must be able to align around these chunks of value (hence a single point for related teams/trains). Working together is required for efficiency as delays in the workflow add rework that wasn't planned for and is usually unnecessary. Being able to accomplish this, however, takes people who can see across the value streams, typically, management. This does not mean, however, that managers tell people how to build things - rather they provide the information the teams need in order to align with each other.

Another way to say this is:

  1. The entire value stream must be focused on the items of highest value
  2. Teams must work together efficiently to get these chunks built, not merely locally optimize for themselves
  3. To do this teams need to know how they are working with other teams, and
  4. Someone has to set up the systems within which these teams can work across the organization.

When trying to figure out which approach to take when adapting Agile at scale, it is worth seeing if the approaches you are considering achieve these four goals. Some approaches will inherently have difficulty providing a holistic view if it is not present already. Others may morph into a top-down control because people become confused by driving from business value (a top-down product management view) and managing in a command-and-control manner (a top-down management view).

While having goals may not present you with answers, they can often be used to see if an approach you are taking has inherent flaws, or perhaps has common ways of mis-applying it that don't work well. Blindly following any approach is never a good idea. So understanding the overall intent of any approach you are taking is always useful.

If you found this useful and are looking for an SPC class, you might consider the one we are teaching in May.

As always, please contact me if you would like to discuss your situation and how we might help you.

Al Shalloway, CEO Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban