I was interviewed by Matthew Skelton, co-author of the book Team Topologies about PMO, the Team Topologies book, Organization Design and Programme Management. Have a look at: Organization Design and Programme Management – interview with Henny Portman
The book Leading the transformation – Applying agile and DevOps principles at scale written by Gary Gruver and Tommy Mouser gives a refreshing look how to start your agility transformation.
While most Agile implementations start with a focus on applying Agile principles at the team level, the approach presented in this book focuses on applying the basic principles of Agile and DevOps across the organization. How teams come together to deliver value in large organizations is the first-order effect, while how individual teams work is a second-order effect. Therefore, this book primarily focusses on how to transform the way the teams come together to provide value to the business by integrating all their changes early and often in an operation-like environment.
Transforming development and delivery processes in a large, traditional organization requires a lot of technical changes that will require some work, but by far the biggest challenges are with changing the culture and how people work on a day-to-day basis.
The approach to rolling out an enterprise-level Agile transition should focus on the business breakthroughs the Agile principles are intended to achieve while taking into consideration the capacity of an organization to change.
In several chapters we follow the steps you have to take when transforming the organization.
- Business objectives and crucial first steps. Once you have a clear set of business objectives in place, the next step is determining where to start the transformation. You can’t do everything at once and this is going to be a multiyear effort, so it is important to start where you will get the biggest benefits.
- A culture of continuous improvement at the enterprise level is important for any large successful transformation (mini-milestone objectives, cascading objectives to track progress, conversations, learnings and agile adjustments).
- Agile enterprise planning. Organizations need to decide whether their primary objective is to deliver long-term accurate plans to its executives or if it is to deliver business value to its customers. Break the planning process down into different planning horizons, don’t eliminate flexibility, don’t lock in all of your capacity to long-range commitments, just-in-time creation of requirements details.
- Business objectives specific to scaling DevOps. Applying DevOps and Agile principles at scale in the enterprise requires developing processes that will enable the organization to economically release smaller batches of code on a more frequent basis. There are five main objectives: improve the quality and speed of feedback for developers, reduce the time and resources required to go from functionality complete or release branching to production, improve the repeatability of the build, deploy, and test process, develop an automated deployment process that will enable you to quickly and efficiently find any deployment or environment issues, and remove the duplication of work that comes from supporting multiple branches of similar code.
- Creating a culture of trunk development. One of the most important cultural changes for aligning the work across the organization is having all the teams continually integrating and testing their code in a production-like environment. From a technical perspective the team will have to learn development practices like versioning services, rearchitecture through abstraction, feature flags, and evolutionary database design techniques.
- ensuring a solid foundation. The first fundamental is clean architectures that enable smaller teams to work independently in an enterprise and make it possible to find defects with fast running unit or subsystem tests. The second is build and the ability to manage different artifacts as independent components. The third is test automation.
- Continuous Delivery is a fundamentally different approach to development and operations that automates as much of the configuration, deployment, and testing processes as possible and puts it all under a revision control. The core pieces of Continuous Delivery you need to know are continuous integration, scripted environments, scripted deployments, evolutionary database design, test automation, deployment pipeline, and orchestrator.
- Designing the deployment pipeline. You need to design a deployment pipeline that moves as close to that ideal state as possible but accommodates the current realities of your traditional business. Building up a stable enterprise system is a key component of the DevOps or Agile principle of enabling more frequent and smaller releases. Even if your business does not require or support more frequent releases, it helps with developer productivity and takes uncertainty out of the endgame.
- Improving stability over time by using build acceptance tests and the deployment pipeline.
- getting started. The key is starting the process of continually improving. The first step is making sure you have a clear set of business objectives that you can use to prioritize your improvements and show progress along the journey. Next is forming the team that will lead the continuous improvement process. The team should include the right leaders across Development, QA, Operations, and the business that will need to help support the priorities and lead the transformation.
Conclusion. After reading this book it becomes clear that moving towards business agility has nothing to do with the implementation of an agile way of working at team level. It’s the organization’s culture that has to change and this book is a great start to understand what that cultural change means from a developers’ perspective and which steps you need to take.
To order: Leading the transformation
Happy and proud to be one of the TOP 15 Semi-Finalists for the 2020 PMO INFLUENCER OF THE YEAR AWARD organized by PMO GLOBAL ALLIANCE. Congratulations to the other fantastic professionals for their significant history of contributions to the global PMO community.
The three finalists will be announced on July 23.
The goal of the Flow frameworktm (developed by Mike Kersten) is to bring Scrum and Agile concepts to the business while providing a higher level of abstraction than agile teams work with day to day. The framework scales the three ways of DevOps – flow, feedback, and continuous learning – to the entire business. User stories and story points are layered over by the four Flow items: features (new business value), defects (quality), risk (security, governance, compliance), and debt (removal of impediments to future delivery). Flow distribution makes priorities visible. Using the Flow Framework if a scaling framework, such as SAFe, LeSS or Nexus, is in place, could lead to greater success.
- From project & cost centers to product value streams
- From siloes & proxy services to flow metrics & business results
- From fragmented value streams to integrated value stream network
The corresponding book:
To order (managementboek.nl): From project to product
To order (amazon.com): From project to product
For more information: https://flowframework.org/
Project to Product: How Value Stream Networks Will Transform IT & Business – Mik Kersten
In my bird’s eye view I positioned the Flow framework in the product targeted box. I see the Flow framework as a sort of add on for SAFe, LeSS, Nexus, et cetera.
See my blog for the complete Bird’s eye view on the agile forest article.
The book 97 Things Every Scrum Practitioner Should Know edited by Gunther Verheyen contains the wisdom of 69 practitioners around the world and helps you to improve your understanding of Scrum (nb. Who are we missing on the cover of the book?).
Gunther organized these 97 essays around ten themes. These themes cover all aspects of Scrum and beyond. The events, the different roles, their behavior, the skills, collaboration and the artifacts. The book ends with a simple Scrum glossary. To summarize, some topics that are discussed in the ten themes:
- Start, adopt, repeat. This first theme gives you insights what it means when you start using Scrum. Use it, as it is or adapt? Why using Scrum? Are multiple Scrum teams the same as Multi-team Scrum? And many more.
- Products deliver value. What are your products? How is this reflected in your backlog? What do we mean by value? Who’s value? And what does this mean for the product owner?
- Collaboration is key. Collaboration, communication and interaction between whom? With the customer, within the team? Are you just following your job description or not? Are tools considered harmful?
- Development is multifaceted work. What are you developing? What’s on your product and sprint backlog? How to size your PBI’s? What do we mean with backlog items, user stories, abuser stories, bugs?
- Events, not meetings. Here we get several ideas how to make the events work and effective. The impact of sprint goals, who plays which role during the events and what are these events not.
- Mastery does matter. Here we get the spotlights on the Scrum master. The Scrum master as servant leader, court jester, (technical) coach, or is he just an impediment hunter?
- People, all too human. Teams are more than collections of technical skills. Are people impediments? Can Scrum masters replace team members?
- Values drive behavior. Scrum is more about behavior than it is about process. What is self-organization? How to be a more humane Scrum master and an essay on the sixth Scrum value.
- Organizational design. It’s all about agile leadership, culture, improving the organization, the importance of networks, respect and a save environment.
- Scrum off script. Probably you think you know the origins of Scrum, but it might not be what you think they are. Here we also get some examples of Scrum outside software development, e.g. at the police, in the classroom, in education.
Conclusion. This book is definitely food for thought for Scrum practitioners. Sometimes you get different views or opinions e.g. on backlog items and user stories but that’s also the beauty. It’s not carved in stone. When using Scrum, you have to think, rethink, discover and adapt. And don’t forget it’s all about people! A must read!
Throughout the book you get many references to articles, et cetera on the web. It would help the reader if small QR codes were added to the text (I often make mistakes by reading/typing a I, i, L or l).
In the book there is a reference to the Flow framework. In a next blog I will dive into this framework to see where it fits in my Bird’s eye view on the agile forest.
To order (managementboek.nl) : 97 Things Every Scrum Practitioner Should Know
To order (Amazon.com): 97 Things Every Scrum Practitioner Should Know
To order (Bol.com): 97 Things Every Scrum Practitioner Should Know
Youtube: Gunther Verheyen answers questions about “97 Things Every Scrum Practitioner Should Know”
I am pleased to inform you that my featured paper “A bird’s eye view on the agile forest” has been translated and published in Russian by the Magazine of COBHET (SOVNET), the Russian Project Management Association, with the title “ОБЩЕЕ ПРЕДСТАВЛЕНИЕ О ГИБКИХ МЕТОДОЛОГИЯХ”. To download: https://grebennikon.ru/article-nzgp.html
The original paper, which is an extract of one of the chapters of my Book “Scaling Agile in organisaties (Dutch)”, has been published by PM World Journal, and it received the “2019 PM World Journal Editor’s Choice Award”. Have a look at the latest updated version of this article.
In January 2019 I published a blog about Evidence-Based Management. When I spoke at the Agile Tour 2019 in Vilnius, Lithuania, I met, among others, Magdalena Firlit as one of the other speakers. She mentioned a card deck she developed to support her classes regarding Evidence-Based Management.
I just received some copies of that deck (really appreciated). If you look at the Evidence-Based Management quick reference card you see the four key value areas Evidence-Based management consists of (Current Value, Time to Market, Ability to Innovate and Unrealized Value).
To facilitate the discussion you could make use of this card deck. In the deck you have colored cards for each key area. Every card contains one of the Key Value Measures (KVM) and corresponding definitions. See picture for two examples of the cards (back and front).
I would say a nice example of creativity and definitely a valuable tool to facilitate discussions how to measure business value. See Magdalena Firlit’s blog too.
It looks like my forest is changing into a jungle. This time I added Agile PM2. Agile PM2 is an extension of PM2 (initiative of the European Union, see: https://www.pm2alliance.eu/forum/an-overview-of-agile-pm2/). To be honest I have some problems with this initiative. As a European citizen, I ask myself, looking at my agile forest, why do we need to spend tax money to develop a new (agile) methodology when there are already so many frameworks and methodologies available?
The Agile PM² Extension
The PM² Methodology supports the use of Agile practices in PM² projects through Agile PM² which is an extension to the core methodology that provides the necessary collaboration framework. Agile teams should be able to collaborate effectively with teams and stakeholders following alternative approaches.
The extension provides:
- Agile roles & responsibilities: The Agile Project Core Team (A-PCT) is part of the overall Project Core Team (PCT). In Agile PM, the additional agile specific roles comprising the Agile Project Core Team (A-PCT) are:
- Team Coordinator (TeCo) – equivalent to the well-known Scrum Master role
- Product Owner (PrOw)
- Architecture Owner (ArOw)
- Agile Team Member (ATeM) – equivalent to the Scrum Development Team role.
- integration with the overall PM² project lifecycle: The Agile PM² has iteration cycles at three levels – daily cycles, iterations, and releases. Regardless of their duration, these cycles follow what is termed in Agile PM² the CIR rhythm (Coordinate, Implement, Review)
- a set of suggested Agile artefacts: Agile Specific Artefacts capture information regarding the planning of specific (implementation) processes, activities, releases, iterations, and other milestones (Development Handbook, Development Work Plan, Deployment Plan, Testing Plan, Agile Logs (Testing Log, Retrospectives Log)
- A set of Agile PM² Mindsets
In my bird’s eye view I positioned Agile PM2 in the project level box.See my blog for the complete Bird’s eye view on the agile forest article.
Many organizations are struggling with their business agility transformation. One of the reasons is the way they have organized their teams. The focus was probably on efficiency and if these teams start to use agile ways of working, this doesn’t make the organization agile. The book Team Topologies – Organizing business and technology teams for fast flow, by Matthew Skelton and Manuel Pais, will help you to design a team organization structure that helps you to become more agile. Using their ideas will help to overcome some obstacles for fast flow. E.g. pushing against Conway’s law, software that is too big for teams, confusing organization design options, teams that are pulled in many directions, painful re-organizations every few years, blocked flow, too many surprises and disengaged teams.
The book is divided into three parts. Part I focusses on teams as the means of delivery. Part II explains team topologies that work for flow and part III elaborates on evolving team interactions for innovation and rapid delivery.
To download: QRC (Team Topologies, 200525) v1.0
The book explains the seven core ideas behind team topologies:
- Conway’s law. “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” Conway’s law tells us that an organization’s structure and the actual communication paths between teams persevere in the resulting architecture of the system built
- Team first. Start with the team for effective software delivery. There are multiple aspects to consider and nurture: team size, team lifespan, team relationships, and team cognition. Organizational groupings should follow Dunbar’s number, beginning with around 5-8 people, then increasing to around 15 people, then 50, then 150, then 500, and so on. Cognitive load: “The total amount of mental effort being used in the working memory.” Restrict team responsibilities to match the maximum team cognitive load. The following three different kinds of cognitive load are explained:
- Intrinsic cognitive load – relates to aspects of the task fundamental to the problem space
- Extraneous cognitive load – relates to the environment in which the task is being done
- Germane cognitive load – relates to aspects of the task that need special attention for learning or high performance.
- Four fundamental topologies. The four fundamental team topologies are explained including expected behavior and capabilities:
- Stream-Aligned Team: a team aligned to the main flow of business change, with cross-functional skills mix and the ability to deliver significant increments without waiting on another team (some would call these teams “product or feature teams” but talking about streams makes more sense)
- Platform team: a team that works on the underlying platform supporting stream-aligned teams in delivery. The platform simplifies otherwise complex technology and reduces cognitive load for teams that use it (a good platform is “just big enough”)
- Enabling team: a team that assists other teams in adopting and modifying software as part of a transition or learning period
- Complicated-Subsystem Team: a team with a special remit for a subsystem that is too complicated to be dealt with by a normal stream-aligned team or platform team. Optional and only used when really necessary.
- Team interaction modes. The primary interaction modes for the 4 fundamental team topologies are:
- Collaboration: working closely together with another team
- X-as-a Service: consuming or providing something with minimal collaboration
- Facilitating: helping (or being helped by) another team to clear impediments
- Organizational sensing. Expect to adapt and evolve your organization structure.
- Topology evolution. An organization should expect to see different kinds of interactions between different kinds of teams at any given time as the organization responds to new challenges
- Team API. A description of the entire interactions with the team: code, versioning, wiki and documentation, practices and principles, communication, work information and other.
Combine a team-first approach with Conway’s lay, the four fundamental topologies, team interaction modes, topology evolution, and organization sensing. Get started: begin with the team, identify streams, identify the thinnest viable platform, identify capability gaps, and practice team interactions.
Conclusion. I would say a great book for those who are designing their agile transition. This book will help to understand where you have to think about when creating your team topology. You get lots of case studies and industry examples.
To order (Maangementboek.nl): Team Topologies
To order (bol.com): Team Topologies
To order (Amazon.com): Team Topologies
My quest continues and continues. The Digital Fluency model is the next one to add to my Bird’s eye view on the agile forest article (thanks to Zaher Alhaj).
Digital Fluency is about achieving what is required for your specific needs and goals and recognizing the importance of continually investing and evolving with your business and customers. The Digital Fluency Model will help you map out your aspired level of fluency for each building block (frictionless operating model, platform strategy, experience design & product capability, intelligence-driven decision making and engineering culture, delivery mindset) capability and identify the sensible default set of investments required to achieve your business goals. Fluency (awareness, focusing, executing, optimizing and strengthening) will be different for each capability, for each organization and even across different parts of the same organization.
The Digital Fluency Model can be used to assess your digital (agile) transformation. According to this model, there are 5 digital capabilities:
- Frictionless OperatingModel: a smooth flow from business strategy to execution.
- Platform Strategy: exposing core business capabilities easily as consumable services, providing self-service access to data, evolutionary #architecture patterns and advanced delivery infrastructure.
- Experience Design & Product Capability: building modern digital products and experiences iteratively through experimentation
- Intelligence-Driven #DecisionMaking: leveraging all data assets
- Engineering Culture, Delivery Mindset: patterns and best practices of lean, iterative, and continuous delivery of software.
These capabilities are planned and monitored over 5-levels of fluency:
- Awareness (something needs to change in order to be successful)
- Focusing (Agree, plan and set up your change)
- Executing (Mastery of practices)
- Optimizing (Remove constraints)
- Strengthening (Reinforce across the business)
See for detailed information the corresponding website Digital Fluency Model
The digital Fluency Model makes use of the Agile Fluence Model. I position this model in the Culture-targeted box of my Bird’s eye view on the agile forest. See the corresponding article.