Tag Archives: agility

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 10X Growth Machine

9789462763142-480x600The 10X Growth Machine – How companies can innovate, scale and win, written by Misha de Sterke, is a book to build your own growth machine by using innovation as a means. It offers a very detailed description of a battle-tested methodology with a framework, a canvas, seven models and eleven tools.

Creative destruction is accelerating. The average life expectancy for European and Japanese companies is 12.5 years and around 10% of all companies disappear each year. Companies with a clear focus on organic growth outperform the competition and those who let costs cutting dominates their agenda, sucks the oxygen out of their growth ambitions.

In the book we get an integrated set of building blocks, principles and tools to create different (disruptive, sustaining and efficiency) innovations as a structural way of working. The big idea is to build a second operating system (the Growth Machine) besides the “mothership”, facilitating a discovery-driven entrepreneurial way of working embedded in a system of processes, metrics and the leadership that nourishes it (note reviewer: compare Kotter’s Dual Operating System). The Growth Machine is a separate system (like an innovation lab, or independent business unit) that co-exists with the mothership and is managed by members of the executive board in the form of a venture board. The purpose of the Growth Machine is to ideate, validate and scale disruptive ventures.10x growth machineIn the attached figure (can be downloaded at www.10Xgrowthmachine.com) we see the framework to build and develop growth. To scale corporate startups successfully and develop an entrepreneurial culture the following building blocks need to be implemented:

  • Growth Strategy: Growth strategy and Portfolio management (optimize the core, review the core, future growth innovation initiatives and the graveyard), C-level alignment.
  • Growth governance: Lean innovation process and venture boards, growth policy playbook, and growth accounting. Venture board maturity phases are – we need to try something new, let’s give this a shot, we’re starting to get it, tackling build vs buy vs partner, returns are coming home, and capability installed. The point of growth accounting is to identify and track leading indicators for future growth. A metric board for growth accounting to show activity and actionable metrics at strategic, tactical and operational level gives valuable insights. Measure to improve, not to judge! In the book you get many pitfalls and common mistakes when measuring innovation.
  • Corporate venture building: Implementation of growth strategies and a lean startup way of working (small ninja teams). Steps in the innovation process are ideation sprint (1 – 3 weeks), customer discovery (10 – 13 weeks), growth MVP phase (12 – 15 weeks) and launch program (13 – 26 weeks). The intrapreneurship function can be implemented in four different or combined ways: producer model, enabler model, opportunist model and advocate model.
  • Growth culture: Awareness and training in a new set of principles (think bigger and bolder, customer obsession, scarcity mindset, relentless learning &relentless high standards, skeptic of proxies, adopting external trends, fast decision-making and ownership). A separate chapter is dedicated to innovation management. How to deal with the tension between the modus operandi (processes, metrics, etc.) of the big company and the small corporate startup.
  • Scaling growth: How to scale the startup to a scaleup? Independent business unit (separate)? Ambidextrous set-up (separate and integrate Spin out?

In the last chapter the author elaborates on the change management pathways to become a systematic growth machine. We get several tips related to the three phases to provide some guidance:

  • Phase 1: Art of the start – build first success, learn how it works and create allies: the art of the start, don’t create blueprints, develop a growth mindset, executive sponsorship, determine the corporate entrepreneurship model, create ambassadors and neutralize the naysayers and quick wins, and speed of learning and kill-rates.
  • Phase 2: Governance – implement system building blocks, engage the organization: communicate success, executive focus and define business metrics that matter, create scarcity, first identify champions on all levels, involve staff & build a playbook of different rules and policies, and act as an investor, identify portfolio gaps.
  • Phase 3: Scale – perfect the practice, build A-teams within the organization: perfecting the daily practice, hire the best and build great teams and foster ownership in the line organization.

Throughout the book several tools (canvas, checklist) are explained and available at www.10Xgrowthmachine.com. E.g. the 10X Growth Machine canvas is a visual tool that executives can use to build their roadmap of implementation. Another one is the disruptive analysis checklist with ‘early warning signals’ to understand where small opportunities arise.

Conclusion A must read for senior managers and innovation officers who want to get insights and support how to turn their organization into a growth machine. This book offers a very detailed description of a battle-tested methodology with a framework, a canvas, seven models and eleven tools. All models and tools are explained in great detail. In-depth interviews with senior managers help to understand specific topics (e.g. FrieslandCampina, RABO Ventures, Startupbootcamp, Athlon, Unit4) as well as several cases. The accompaning website offers access to all mentioned models and tools.

To order (managementbook): 10X Growth Machine

To order (Amazon): 10X Growth Machine

Too many rules makes agility impossible

PP rulesOne of the principles of the Agile Manifesto is “Simplicity—the art of maximizing the amount of work not done—is essential”. Studies from the Standish Group and recorded in one of their Chaos reports shows that 60% of developed features are not or rarely used. If you only deliver the right features your customer will get the product much faster and cheaper.

Looking at the features of the product you are developing is one way to take this principle into account. You could also apply this principle to the process you are using to develop your product. How many rules do you have to follow?

Have you ever played a game of go? Go is an abstract 2500 years old strategy board game for two players, in which the aim is to surround more territory than the opponent. Despite its relatively simple rules, Go is already very complex. Or think about Conway’s life cellular automation. Just a few very simple rules and awesome results. Adding more rules will result in chaos.

I read a story about day care centers in Israel. They were facing the issue that some parents picked up their child too late. As a solution the implemented a new rule that if you pick up your child too late you have to pay a fine. As a result of this rule even more parents picked up their child too late. What used to be a moral trade-off (I can’t be too late) now became a business trade off: I buy off my debt. Rules are not necessarily sacred, principles are.

If you look at some agile frameworks or ways of working, you can ask yourself if the rule makers force you to be rule taker or rule breaker. Many of these are there to help you when building teams of teams who develop one product or service but here too, if you can manage to ‘simplify’ your architecture towards micro services you don’t need those scaling frameworks. If we compare the number of rules of Scrum with SAFe you could ask yourself if you are successful and using agile release trains, if this is due to SAFe’s rules or despite?

Agile framework or way of working rules
Agile manifesto 4 values, 12 principles
Scrum 3 roles, 5 events, 3 artifacts, 5 values
Nexus 6 roles, 5 events (team), 6 events (Nexus), 7 artifacts, 5 values
LeSS 5 roles, 5 events (team), 3 events (team of teams), 4 artifacts, 28 rules (LeSS), 12 rules (LeSS huge)
AgilePM 13 roles, 6 processes, 15 products, 8 principles
PRINCE2 Agile 9 roles, 7 processes, 7 themes, 7 principles, 5 behaviors, 26 products
Disciplined Agile Delivery 11 roles, 3 phases, 6 delivery cycles, 7 principles
SAFe 12 roles, 6 events (team), 7 events (program), 2 events (large solutions), 7 artifacts, 4 values, 10 principles

If you want to set up an innovation or growth lab, make sure you stay away from bureaucracy. To reduce obstacles, exempt the lab from corporate rules, procedures, manuals, guidelines, principles and formats. Innovative plays can do without!

Jim Johnson dreamer and chairman of the Standish Group stated in an interview for a Dutch PM magazine: “Analyzes of the project data have yielded standards, frameworks and structures, although I am actually quite hesitant about standards, because they limit growth. All things considered, the reflex to build structures increases the chance that an IT project will fail. Structures in the form of complicated management tools, too many rules in the field of governance, too narrowly defined professional requirements, you name it. Structures are built with the best intentions that make projects especially slower, slower, more expensive and more time-consuming. Structures in which no one dares to make any decisions.”

If you are striving for agility think about a quote from Pablo Picasso “Learn the rules like a pro so you can break them like an artist”. Or with my own words use common sense when applying agile frameworks or way of workings and show the right agile mindset by understanding the logic over following the rules.