Scaling Agility & Product Mindset
This article is in continue of "Scaling Engineering Teams & Rise of Platform Engineering Squads", "Gamifying Engineering for Better Employee Experience" and "Practical Guide to a Better Product Management" posts.
I am in pursue of finding a scalable and practical methods into scaling agile that really works. Away from all corporate bullsh*t and theoretical world. Something that works or I see the pain in setting up structure for over 300s of engineers and product folks. It is not easy and please share your thoughts.
In today’s tumultuous markets, where established companies are furiously battling assaults from start-ups and other insurgent competitors, the prospect of a fast-moving, adaptive organization is highly appealing. But as enticing as such a vision is, turning it into a reality can be challenging. Companies often struggle to know which functions should be reorganized into multidisciplinary agile teams and which should not. And it’s not unusual to launch hundreds of new agile teams only to see them bottlenecked by slow-moving bureaucracies.
In this post:
Flow Efficiency
Flow efficiency is the ratio between value-adding time and the lead time required to complete a process. Value-adding is when a person or a machine is actively working towards the completion of a given target. Lead time is the frame between the order and delivery of the product.
Following this line of thought, the typical non-value-adding time activity and one of the seven wastes in Lean management is waiting on something. It can be separated into two categories:
Wait time?is accumulated when a task is waiting on something that doesn’t depend on the person working on it. The most typical example of generating wait time in Kanban is when a card is awaiting someone to review it before moving on to the next column of the Kanban board. On the other hand,?blocked time?is generated when an assignment gets stuck somewhere in the workflow, and there is something that’s in the way of resuming work.
Block reasons can range from waiting on personal capacity (usually because another task requires immediate attention) to waiting on a repair team to fix a hardware/software issue. The major difference between these two types of waste is whether the inactive time is expected or not. If it is expected, you should consider it a wait time. If not, then the task accumulating it is considered blocked. Knowing how much time goes to waste waiting on something gives you insights about where you need to improve your process for greater Lean efficiency.
Here an example of visualization of value vs non-value in a go-live process:
Tracking your team's workflow efficiency is crucial for optimizing the whole process. One of the tools that I used and recommend is Jira Align. You can see the following 2 figures that help you to visualize how it is working.
The Problem with Org Charts
Most organization charts are useless. Architecture approaches like Micro-Frontends, Micro-Services and DevSecOps have impacted org charts and created new paradigms. Engineering knowledge workers are in a constant state of action: creating and updating systems at an unbelievable rate, and combining different types of technology to create a compelling experience (cx, ux, ex and dx). Mobile applications; cloud-based services; web applications; and embedded, wearable, or industrial IoT devices all need to interoperate effectively to achieve the desired business outcomes. Building and running these highly complex, interconnected software systems is a team activity, requiring the combined efforts of people with different skills across different platforms.?But despite these risks and demands, many organizations are still organizing their people and teams in ways that are counterproductive to modern software development and operations.
Most organizations want or are required to have a single view of their teams and people called the “org chart.” This chart depicts the teams, departments, units, and other organizational entities, as well as how they relate to each other. It usually shows hierarchical lines of reporting, which imply lines of communication running “up and down” the organization.
The problem with taking the org chart at face value is that we end up trying to architect people as if they were software, neatly keeping their communication within the accepted lines. But people don’t restrict their communications only to those connected lines on the chart. We reach out to whomever we depend on to get work done. We bend the rules when required to achieve our goals. That's the reality and agile spirit. That’s why?actual?communication lines look quite different from the org chart (see below).
Source: https://teamtopologies.com/
In practice, people communicate laterally or “horizontally” with people from other reporting lines in order to get work done. This creativity and problem solving needs to be nurtured for the benefit of the organization, not restricted to optimize for top-down/bottom-up communication and reporting.?
Beyond the Org Chart
So if org charts are not an accurate representation of organizational structures, what is? Niels Pflaeging, author of?Organize for Complexity, identifies not one but three different organizational structures in every organization:
Pflaeging suggests that the key to successful knowledge work organizations is in the interactions between the informal structure and the value creation structure (that is, the interactions between people and teams). Other authors have proposed similar characterizations, such as Frédéric Laloux in?Reinventing Organizations?or Brian Robertson’s?Holacracy?approach (read on my experience on implementing holacracy in Vientam in here).
Spotify Org Chart with focus on what is below Chief R&D Officer:
Re-Thinking Structure and Interactions
I attempted to illustrate the need and necessity of having platform engineering squads in "Scaling Engineering Teams & Rise of Platform Engineering Squads" but in this post I will beyond of just platform squads. Developing and operating software effectively for modern, interconnected systems and services requires organizations to consider many different dimensions. Historically, most organizations have seen software development as a kind of manufacturing to be completed by separate individuals arranged into functional specialties, with large projects planned up front and with little consideration for sociotechnical dynamics.
Impediments and Problems of "Fast Flow Efficiency" are:
The following two points are my learning from amazing book of:
Four Team Types
There are four types of teams:
领英推荐
The flow of change is shown left-to-right. Stream-aligned teams own an entire slice of the business domain (or other flow) end-to-end. The Stream-aligned teams are “You Built It, You Run It” teams. There are no hand-offs to other teams for any purpose.
This diagram is a snapshot in time. The team relationships WILL change as new goals are set and the teams discover new things.
Three Interaction Modes
There are only three ways in which team should interact:
To learn more about key ideas from Team Topologies like the four types of teams, the three core interaction modes, the platform as a product approach, or how to align teams with true value streams, have a look at the self-paced Team Topologies Distilled course on the Team Topologies Academy.
Organizational groupings should follow Dunbar’s number, beginning with around five people (or eight for software teams), then increasing to around fifteen people, then fifty, then 150, then 500, and so on.?
Traditional flow of change in an organization not optimized for flow, with a series of groups owning different activities and handing over the work to the next team. No information flows back from the live systems into teams building the software.?
Organizations set up for fast flow avoid hand-offs by keeping work within the stream-aligned team, and they ensure that the rich set of operational information flows back into the team.?
The new model for support teams: aligned to the flow of change, usually paired with one or more stream-aligned Dev teams. Incidents are handled with dynamic “swarming.”?
With three very disparate technologies (mobile, cloud, and IoT), an organization must decide on an approach to fracture planes that makes sense based on the cognitive load and the change cadence in each area.?
Stream-aligned Team A collaborates with complicated-subsystem Team B (shown with cross-hatching) while also consuming the platform provided by Team C, using the X-as-a-Service mode (shown with brackets).?
Advantages and Disadvantages of Collaboration Mode:
Advantages and Disadvantages of X-as-a-Service Mode?
Advantages and Disadvantages of Facilitation Mode?
Two teams (“cloud” and “embedded”) collaborate to share practices and increase awareness. The results will include heightened awareness of the options for future team interactions: (1) treat the cloud software as a platform for the embedded team to use, (2) treat the embedded devices as a platform for the cloud team to use, or (3) continue with close collaboration.?
Increase flow predictability in higher-level business services (streams) through the use of a “platform wrapper” to “platformize” the lower-level services and APIs, allowing the streams to treat all their dependencies as a single platform with a holistic roadmap and consistent DevEx. The streams also have rich telemetry to track flow and resource usage of the platform.?
Balancing Agile Enterprise Operating Model
Product Experience Architect | Head of AI
2 年and a year later Gartner published same topic: https://www.gartner.com/document/code/772777?ref=authbody&refval=4019502
"Mind-reading" products/engineers leader, a lifelong learner and a go-giver.
3 年Indepth & insightful write up, thanks mate!
Growth Leader | Digital Experience | Financial Services | AI Practitioner
3 年This is the big challenge at the moment Chris Shayan. We have industrialised our digital-traction model to address this. in essence we don’t look at product development in terms of the functions required but instead deploy a cross-functional slice of the company into every challenge…and to your point, we stay away from endless consulting and encourage our customers to simply start, start small and focus on speed above all else… this helps develop the right culture within product and engineering teams.