Tag Archives: English Post

Review: Team Topologies

515ymmKuFqL._SX332_BO1,204,203,200_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 to 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.

QRC (Team topologies, 200525) v1.0To download: QRC (Team Topologies, 200525) v1.0

The book explains the seven core ideas behind team topologies:

  1. 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
  2. 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. 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.
  1. 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.
  1. 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
  1. Organizational sensing. Expect to adapt and evolve your organization structure.
  2. 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
  3. 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

The Digital Fluency Model

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.

Digital Fluency ModelThe 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:

  1. Awareness (something needs to change in order to be successful)
  2. Focusing (Agree, plan and set up your change)
  3. Executing (Mastery of practices)
  4. Optimizing (Remove constraints)
  5. 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.Grasp session (Scaling Agile bron, 200414) v1.1

Review Rethinking agile

51nTAg-en9LRethinking agile – Why agile teams have nothing to do with business agility written by Klaus Leopold is great book to cope with agile transformations and what you have to do to increase the chance of success. It definitely busted the myth that having agile teams makes you agile.

The book is divided into four parts: the problem, the causes, the first solution, and the result.

The book starts with a case study of an organization that wants to optimize their time-to-market. They want to reorganize their teams. All teams should be cross-functional and organized according to the premise: One team, one product. Teams could choose the agile method they wanted to use, and the following requirements needed to be fulfilled: work should be visually managed, hold daily stand-ups, retrospectives, throughput and cycle time must be measured. All 600 IT employees followed a one-day agile mindset basis training. Management realigned the teams according the product structure and the reorganization took place through self-organization (marketplace). External support in the form of 16 coaches helped the teams to run system design workshops and create Kanban systems to visualize and manage their workflows. As a result, all teams were fully transformed and fulfilled the stipulated agile framework conditions. But the ability of the teams to deliver had not changed much! Projects are not being completed more quickly!

The author describes four causes why their projects were not completed more quickly.

Cause #1: The pitfall of simplistic inference in the change process

    • Implementing agile is a means – not a purpose – for achieving business agility
    • The change process as a project (pull versus push principle)
    • Change is a new organigram – mixing up cause and effect.

Cause#2: Dealing with dependencies between teams and products. They forget to consider:

    • One product, many teams
    • Dependencies between products
    • Peculiarities in knowledge work.

Cause #3: An incomplete value stream

    • What is happening downstream? Integration? testing? release? …?
    • What is happening upstream? Idea pool? Triage? Business case, decision making. …?
    • End-to-end management of the value stream was missing.

Cause#4: WIP limits at the wrong place

    • Reducing WIP: Park the work in front of the system (option pool)
    • Limit the initiatives, the number of projects in the system (strategic portfolio management).

As a solution the author discusses the added value of the flight level model as a communication instrument to identify the effect of specific improvements at operational level (team), coordination (value stream) and at strategic portfolio management (company) and to discover where within the organization it makes sense and/or is possible to leverage improvements (visualizing the work, setting WIP limits, establishing feedbackand determining and implementing improvements). On top of that he sees three areas of improvement: make dependencies visible (product boards), integrating the upstream (be aware of traps: too much, too exact, too unnecessary) and strategic portfolio management (strategy board).

The book ends with a summary to make your business agile:

  • Start at the top (the first agile team)
  • Agility begins with the change process
  • Focus on the goal not on the method
  • Agility is not a team affair
  • Identify the flight levels (operational level, coordination and at strategic portfolio management)
  • Manage and eliminate dependencies
  • Incorporate the drivers for lean business agility at every flight level (visualize, manage WIP, feedback loops, improve).

Conclusion. Great book and nice illustrations (by Matthias Seifert). A must read for those who are starting or in the middle of a business agility transformation to learn what others did wrong and what you can do to increase your chance of success. A next print could benefit when a contents paragraph and chapter and paragraph numbers are added.

To order (Amazon): Rethinking agile

To order (bol.com): Rethinking agile

Review: DevOps for the modern enterprise

devopsDevOps for the modern enterprise – winning practices to transform legacy IT organizations is a practical book based on the experience of the author Mirco Hering.

The book is divided into three parts. The first part explains how to create the right ecosystem for success. The second part puts the people and organizational dimension in the spotlights and the last part emphasizes on technology and architecture aspects. Every part contains four chapters and at the end of each chapter you get some steps to exercise to make it more practical.

The first part – creating the right ecosystem – starts with the usage of value stream maps to visualize your IT delivery process and a jump-start of the transformation with an initial roadmap and governance approach. As a next step you have to analyze your application portfolio (criticality of application, level of investment in application, preferred frequency of change, technology stack). Based on this analysis you should focus on a minimum valuable cluster (MVC) to speed up the complete cluster by uplifting the MVC. The following chapter discusses the added value of guidelines for selecting new applications and the strengthening of your architecture by creating and empowering ecosystem. The following aspects can be used to start the assessment of architecture maturity: auto scaling, self-healing, monitoring and capability for change. When looking at your packages, in case you can’t or don’t want to replace, the following approaches are explained: leverage your system integrator, leverage user groups, strangle the application and/or incentivize the vendor to improve their product. In line with the types of applications (differentiator applications, workhorses and true legacy) you have to find the right partner that fits your ambition and culture.

As stated, the second part put the people central. How can you provide your people with the right context for their decisions, what team structure you should choose to enable autonomy and purpose, how to shift from legacy thinking that has caused many test automations projects to fail, and how to manage your people better? Based on the “burger organizational chart” the author discusses delivery governance (with an agile governance function, DevOps governance function and quality assurance),  the test automation center of excellence, agile teams (maybe clustered in an agile release train, team by location, team by function and team by technology) and the platform team (test automation, automated app release and environment provisioning). A separate chapter is dedicated to testers and the importance of quality. The last part gives more generic people-oriented techniques and ways of working like one-on-ones, feedback, delegation, creating a blameless culture and measuring your organizational culture.

The last part looks at the right way to choose DevOps tooling, what makes a good DevOps architecture, how to evolve your application architecture, how to leverage the relationship between DevOps and cloud computing, what each delivery model looks like, and how these models impact your organization.

The delivery models are:

  • Continuous delivery model deploys applications automatically into persistent environments (either cloud or on premises)
  • Cloud-enabled delivery model deploys applications automatically after provisioning a new environment from the cloud or data center. Main difference compared to continuous delivery model is the maturing of the infrastructure practices – infrastructure as a code.
  • Container-enabled delivery model deploys applications as a set of containers into one or more hosts that are dynamically created. Main difference compared to cloud-enabled delivery model is the maturity of the container practices and the more modular application architecture.
  • Serverless delivery model (potential future model) where you don’t run services as such but rather write a function to perform some business logic. When the function is called, an instance is created just for the duration of the function call (e.g. Amazon Lambda).

To evolve your architecture over time you can use the strategies decoupling (two speed delivery model), going on a diet (paying down the technical debt and making the core more agile), let’s try it on the side (green field setting) and erode the core with microservices (a service that serves one purpose; it is self-contained and independent; it has a clearly defined interface and isolated persistence). The book ends with different aspects of levering cloud-based services. Benefits of the cloud are cost benefits, ease of setting up redundancy for resilience, the scalability of resources, and the strong ecosystem of related services that you would otherwise have to build yourself. on the risk side we see the dependency on a third-party provider, the challenges with data sovereignty, and the risk of being attacked because you are on a popular platform.

Conclusion. Reading this book and execute one or more of the exercises gives you one of the reasons why so many agile transitions fail. It’s not only about creating, sometimes only renaming teams into agile teams but you have to look at the complete ecosystem, your application landscape, the application architecture and your delivery models. A must read for those who are transforming their IT organization towards a more agile organization.

To order: DevOps for the modern enterprise


Business Agility model

eyeMy quest continues. The Business Agility model is the next one to add to my Bird’s eye view on the agile forest.

The Business Agility Model (developed by the Business Agility Institute) consisting of twelve interacting domains across four dimensions to take into account when transforming your organization. These are the essential building blocks for an agile organization.

At the center of the model we see the customer domain. The first ring, surrounding the customer domain is the relationship dimension with the domain’s partners, board and workforce. In the outer ring we find the three dimensions Leadership (how to shape an agile organization with domains people management, one team and strategic agility), individuals (how an agile organization delivers value with domains growth mindset, ownership & accountability and craft excellence) and operations (how an agile organization works with domains enterprise agility, process agility and structural agility). All domains are complementary and mutually necessary to business agility.

Schermafdruk 2020-04-14 16.23.33The 12 domains explained:

  • Customer: The heart of business agility is no less than the very reason we exist: Our customer.
  • Board: Business agility requires an open, 2-way, relationship between an organization’s leaders and the board of directors; built upon customer-focus and long-term success, which enables the company leaders to go after long-term bets, as opposed to short term wins.
  • Workforce: Business Agility requires a mission-aligned, passionate, empowered workforce built of individuals with a strong culture fit and potential over fit for a specific position.
  • Partners: Business Agility requires partnerships crafted with flexibility and driven by customer value so both an organization and its partners are able to adapt in a coordinated and complementary manner, rather than a series of contractual transactions.
  • People management: Business Agility requires leaders to recruit, hire, nurture, and develop people with a strong fit for future potential and mission alignment, over fit to position.
  • One team: Business Agility requires a One Team mindset of co-creative efforts to achieve shared goals that span functions, teams, and divisions within the organization.
  • Strategic Agility: Business Agility requires leaders who set, and clearly communicate, an adaptive strategy that empowers teams to identify opportunities to execute that strategy in potentially innovative and previously unforeseen ways.
  • Growth mindset: Business Agility requires that individuals are open to learning by doing, continuous learning and personal development as well as being comfortable operating and making decisions in a dynamic and ambiguous environment, free from the fear of failure.
  • Craft excellence: Business Agility requires craft excellence that continually improves over time, is the most impactful to creating value, and enables individuals to take advantage of emergent opportunities for customers.
  • Ownership & Accountability: Business Agility requires deep ownership and accountability, so individuals close to the work and customers drive timely decision making and adaptations.
  • Structural agility: Business Agility requires the ability for an organization to create coalitions or change structure as needed to embrace new opportunities with ease and without disruption.
  • Process agility: Business Agility requires operations to adapt and continuously evolve as needed in service of creating value for customers.
  • Enterprise agility: Enterprise Agility is a response to competitive pressure, to adapt fast to changes in market demands and seize opportunities while reducing costs. At the core of the Agile Enterprise are the People, knowledgeable, skilled and innovative.

See https://businessagility.institute/learn/domains-of-business-agility/ for more detailed information.

The business Agility model is not a framework in itself but it gives you a head start with the agile mindset and culture. Your teams can make use of Scrum, LeSS, SAFe or one of the others. In my bird’s eye view I positioned the Business Agility model in the culture-targeted box.Grasp session (Scaling Agile bron, 200414) v1.1Bird’s eye view on the agile forest article.

Review: The art of business value

38907639._SY475_Mark Schwartz is the author of The art of business value. You could see this book as his quest to the concept of business value.

Is business value the same as customer value? The question of business value is the question of purpose, motivation, mission, and direction. It is a question of value and values.

In the first two chapters the author examines many different ways how known (agile) experts use or describe ROI, NPV, MVA, Profitability Index, IRR and payback period. All these measures are really just proxies for what the company ultimately values, like shareholder value, and they are unlikely to be useful to a product owner making feature trade-off decisions.

The author abandoned the idea that business value is a simple formula, known ahead of time and simply applied to user stories, and accept that business value requires interpretation and asks himself whether the model of a product owner (or business representative) doing all the interpretation continues to make sense. Many Scrum teams struggle with getting the product owner to prioritize non-functional requirements, such as security stories, work that reduces technical debt, alongside functional user- facing requirements. Following Eric Ries’ lean start-up approach, the product owner is no longer the interpreter of business value. Instead, value is discovered by the team that does validated learning experiments and hypothesis testing.

In a next chapter bureaucracy is put in the spotlights. Bureaucracy is all about rules and proving that they have been followed. Bureaucracy often leads to compliance requirements. But what if those requirements actually are adding business value?

Management, just as culture and bureaucracy are often viewed as impediments. Is the CIO responsible for executing projects, or responsible for delivering business value from IT investments? The CIO’s challenge is to show that IT is adding concrete business value to the organization. The IT organization must become an interpreter of business value as well as a provider of technical skills, and its interpretation must influence not only the behavior of project teams but also the enterprise’s business strategies.

The author finally gives his definition of business value: “Business value is a hypothesis held by the organization’s leadership as to what will best be accomplish the organization’s ultimate goals or desired outcomes”. He states that the agile team will be responsible as a whole for delivering business value.

The last chapter describes thought experiments to see if they influence the way you think about business value. E.g. adopting a DevOps culture and a Continuous Delivery pipeline or six ways to think about the CIO’s role.

Conclusion: The book The art of business value is not easy to read but after you have read it and executed one or more of the experiments, you have a much better idea how to cope with business value. And it gives valuable insights in the role of the product owner and the agile team too.

To order (Amazon): The art of business value

PMWJ article: Are incremental and iterative the same phenomenon or not?

Happy to see that the Project Management World Journal (PMWJ) published my article:

Portman, H. (2020).  Are incremental and iterative the same phenomenon or not? PM World Journal, Vol. IX, Issue IV, April.

During training classes I often notice that students mix the words iterative and incremental together. After reading this article I hope you understand the relationship between incremental and iterative development. I will start with a comparison of a waterfall and an agile approach by delivering a payment app. In the second part of this article, I position waterfall and agile in an incremental versus iterative matrix and shows what happens in the other two quadrants too. As a last step I elaborate on the minimum viable product (MVP) and the minimum marketable product (MMP) and shows where these fit in the different approaches and a story map.

To download the article: pmwj92-Apr2020-Portman-are-incremental-and-iterative-the-same

To support the article, I Created two mini webinars

Mini webinar: Waterfall versus agile delivery

Mini webinar: Incremental versus iterative