Sanjiv Augustine on Managing for Value Delivery (Scaling Tech Podcast Ep3)

Jul 12, 2022 | Agile, Project Management, Team Management

Sanjiv Augustine is the Founder and CEO of LitheSpeed, a world-leading agile training and consulting company; and an executive consultant and trusted advisor on business agility. He was a co-founder of the Agile Alliance’s Executive Forum and the Agile Leadership Network (ALN). He is the author of the books “Managing Agile Projects,” “Scaling Agile” and “From PMO to VMO.” In this episode, Sanjiv defines the role and benefits of a Value Management Office, and how that is different from a traditional Project Management Office. They discuss the importance of project managers, as well as the importance of staying more focused on delivery of value rather than just following a process. Along the way, Sanjiv, Arin and David also discuss many other concepts such as Portfolio Walls, Spikes, Velocity, OKRs, Adaptive Governance and more.

Listen on Spotify
Listen on Apple Podcasts

Watch the video:
Show notes with links to jump ahead are below

Show Notes from Episode 3 – Sanjiv Augustine on Managing For Value Delivery
Timestamp links will open that part of the show in YouTube in a new window

  • 00:00 Introductions by Arin and David. David notes how much he appreciates the concept of Value Management instead of Project Management, and how Sanjiv related to that to growing teams. Arin noted the importance of terminology in process, and how important Sanjiv’s reminder is not to vilify project managers. We need that role to make projects successful, and VMOs can potentially reduce that tension between management and technical delivery teams.
  • 03:54 Arin introduces Sanjiv’s background
  • 05:04 Sanjiv defines a Value Management Office and how it’s different from a traditional Project Management Office. Sanjiv notes that the pandemic has helped accelerate the demise of the project model as well as the waterfall model. Modern development drives us in the direction of small batches, and management needs to support these small agile teams. This boils down to a combination of Lean Portfolio Management and Adaptive Governance, which is the lens used to create a Value Management Office.
  • 07:30 Sanjiv gives an example of the difference between a PMO and a VMO, and talks about how a traditional project would have a Project Book of Work, but a Value Management Office will create a Portfolio Wall and prioritize those elements before funneling them to the teams.
  • 08:50 David notes the emphasis is on value, not on process for the sake of process. Sanjiv notes that there can be project police even in methods like Scrum, and we need to focus more on business outcomes instead of process outputs, and that will help us to focus on value delivery.
  • 11:27 Sanjiv talks about the other things that need to change in an organization to enable this change. “Stop beating up on your project managers” is Sanjiv’s first bit of advice, because he notes that 80% of change efforts succeed when middle management is on board – we need project managers and middle managers to enact the lean change that we want.
  • 13:30 David notes that all traditional project managers want to deliver value too, they are just hindered by the system they work in.
  • 14:45 Sanjiv talks about two groups they were addressing in the book, the middle management layer and what they need to do, as well as an executive action team, since they need to work together.
  • 15:20 What metrics are needed in a VMO? Sanjiv talks about using Key Objectives and Metrics, that are business focused and are proper Business Objectives and Key Results (OKRs). This is necessary to help focus on outcomes instead of just metric outputs. The best way to link Strategy to Execution is through OKRs.
  • 17:58 Sanjiv talks about one of the most important questions in Portfolio Management, which Johanna Rothman identified in her book on Portfolio Management. This most basic question is “Should we do this work at all?” If the answer is No, then we just saved ourselves a lot of time and money. VMO should also be looking at their OKRs to see that they line up to business objectives.
  • 19:00 Arin asks about Technical Debt, and how a VMO should address Technical Debt. Sanjiv backs up by first discussing Adaptive Governance. Sanjiv mentions the acronym CARLA, which stands for Compliance Audit Risk Legal Architecture. These are all things that need to be considered above the team level, and the VMO can help identify the things a team needs to work on in order to address those CARLA factors. Technical Debt is similar to that, and so these things all get addressed in the backlog. The VMO should be an advocate for the teams to proactively address technical debt.
  • 23:00 Sanjiv urges anyone in a VMO to become familiar with XP techniques, and in particular with the concept of a Spike. A Spike can be used (instead of the term Project) to work on paying down technical debt. We should also be more aggressive about running architectural experiments up front, before committing to that for a major release or new product.
  • 26:00 Alignment of the backlog with OKRs is key, and Sanjiv notes this means the backlog may actually shrink because in addition to adding new work we didn’t think of, we should also be discovering work that we don’t need to do. We must empower our technical teams and product owners to terminate work that is not needed.
  • 26:53 How does a VMO fit in the pantheon of scaling methodologies? Sanjiv notes that when it comes to scaling methodologies, he is “orthodox not religious”, meaning that as long as you stick the agile and lean principles, then you don’t have to be stuck with a single scaling methodology. Things like Scrum of Scrums or Scrum at Scale or others can all be used in tandem with VMO concepts.
  • 29:25 Sanjiv explains the Six Sigma Paradox, which is the idea that a VMO needs to minimize process variability, slack and redundancy, by building in process variability, slack and redundancy. Some things needs to be standardized, and we need to decide what those things are, but also leave in space for us to color outside of the lines. Standardization should not be down at too low a level because that stifles a team, but at too high a level will also create waste. We have to figure out where to draw the line, it’s not a simple answer.
  • 33:43 Sanjiv poses the question, should we standardize User Stories? This is an example of the Six Sigma Paradox. We might standardize them within a team, but should be careful about standardizing them across an entire organizations. And we must always think of that as a living standard, so it can be changed and improved over time.
  • 34:50 Sanjiv also poses a similar question, should we standardize Velocity? Arin notes you can’t standardize a single metric across teams doing disparate methodologies, and David notes you cannot compare Velocity between teams anyways. Since story points may not have the same meaning in 2 teams, then Velocity cannot be compared.
  • 35:50 Velocity is a measure of Output, which is useful to the team, but not useful to the business. OKRs are the measurement that the business needs. Velocity should never be used as a cudgel against teams, and it can be too easily gamed. Value is harder to game.
  • 37:05 Arin asks Sanjiv about the biggest challenges you see in scaling teams, where should an engineering leader begin? What mistakes should they avoid? Sanjiv notes how often agile consultants will say that you should not scale a team – but Sanjiv feels that is trite and not responsible. Sanjiv suggests instead that it’s important to scale organically, not mechanistically. Complex adaptive systems theory underlies all agile theories, and Sanjiv notes how his colleague Bob Payne has told him “Don’t look at dividing and conquering, instead, you should conquer and then divide.” The right approach to scaling organically is to bring an initial team to together to conquer a challenge, then use a few people from that team to seed other teams in the organization that will work in a similar way.
  • 41:55 David talks about how when you establish a VMO that can manage your value stream, then scaling will be much less painful no matter what method you choose. Sanjiv agrees and notes how that brings us back to the foundation of Lean organizations – it’s all about organizing our work around customer journeys and prioritizing them based on the biggest customer value.
  • 45:30 Sanjiv ends on a note of optimism about the trends in work, and lists out ways to follow their work at Lithespeed.

Links from Episode 3 – Sanjiv Augustine on Managing For Value Delivery