Following FTAM By Expanding DoD VS. Becoming A Hostage To Traditional Org Structure

 

When a team is not able to deliver a product increment (PSPI) at the end of a sprint, we should not automatically assume that its developers poorly estimated, refined or planned their work.  There could be other reasons.  In fact, there are many teams that can meet their own Definition of Done (DoD) pretty consistently, yet not able to ship, at the end of the sprint.
What could be other reasons to not being able to deliver PSPI?
The answer might be hidden in a team’s maturity of DoD. How complete is DoD? Does it include design and development only? Or does it also incorporate a peer code review, integration, packaging and staging? How about customer documentation, marketing materials? What kind testing is included in a team’s DoD: unit, integration, system, performance, stability, usability, stress, monkey, smoke…?
While some of the above listed steps could be very well within a team’s ability, some others – may not, and it could be due to organizational (NOT teams’) limitations/restrictions.  These restrictions are caused by organizational design boundaries and areas of control. For example, traditionally, some (most?) downstream activities are handled by separate teams: testing, integration and deployment have been historically handled by another department.  Similarly, all relevant operational work might be handled by another organizational structure, sometimes ironically called “DevOps team”. This makes a team’s DoD weak and low in maturity. Anything that a team cannot complete because of organizational design limitations/restrictions could be labeled as “Un-Done” work.  Historically, component teams have had much less inclusive (low maturity) DoD and pretty extensive “Un-Done” work then feature teams. It would be very difficult for a component team to deliver a PSPI by the end of the sprint, because such activities, as integration with other components, full end-to-end testing etc., would be excluded from DoD.
By design, feature teams tend to be more mature then component teams, with respect to DoD, and this could increase (not guarantee) their chances of delivering PSPI at the end of the sprint.  However, in complex organizational settings, even feature teams could have “UnDone” left-overs by sprint-end, because some activities (e.g. end-to-end testing, production deployment) are still handled by other teams due to organizational boundaries.

Even if a team’s an initial DoD is weak, it should a team’s goal to gradually (from sprint to sprint) expand DoD, while shrinking (reducing) UnDone work.  Undone work may never reach a zero mark, but making it smaller and smaller, should be every team’s aspiration.  Btw, maturity of DoD is probably one of the most useful and reliable maturity metrics that a team may use (by far, more useful that majority of vanity metrics that organizations impose upon teams).

It is important to recognize that for many organizations, difficulties with expanding DoD are caused by internal politics and contractual relationships (when different teams, departments, managers compete for control and power).

Let’s further explore how a team may gradually expand its DoD, by gradually expanding its DoD.

While making a journey, from being a single component team to a feature team, a team gradually becomes proficient and capable of more advanced work: from coding a single component,  ➡ to designing and unit testing, ➡ to architecting and testing a subsystem,  ➡ to analysis and whole system testing, … all the way to co-creation.

As per Feature Team Adoption Map (FTAM) below, while advancing in the functional dimension (X – axis), a team becomes more capable to expand its scope of work in technology dimension (Y-axis): from a single component, to sub-system, to whole product, to whole system, to problem solving and beyond – essentially, expanding it’s DoD.

As mentioned, a component team that can code only one component, will have a lower-maturity DoD and extensive UnDone work.  On contrary, a feature team can perform multiple activities (e.g. code in multiple components, design/architect, text, co-create) and work on the whole product, will have a higher-maturity DoD and less extensive UnDone work.

 

 

Many organizations have difficulty defining real products from a business/customer perspective, and here are some reasons for this:

Traditionally, this initiative has been driven by technology, because a typical agile transformation has also been driven by IT. As such, products have been frequently organized around architecture, components and technology language, instead of customer-centric requirements and customer language.

Even if/when business has been involved in product definition activities, people that are best suited for the job (e.g. head of business operations, customer-facing senior product manager, power users) would not available, e.g. for the role of Product Owner. Instead, this responsibility would be delegated to business analysts, business-side project managers, program managers, portfolio managers, and other roles that come from traditional organizational structures, where customer centricity and product focus historically had not been a priority.

As a result of the above, and because traditional business-to-technology “alignment” has been treated more as a “PR” (a nice thing to claim), rather then as a genuine bi-lateral effort, the following trend is usually observed: work done by component/shared services/platform/architecture teams gets “re-packaged” into projects, programs and portfolios, now called “tech-for-tech” products, sub-products, products families, product lines, a.k.a. FAKE PRODUCTS – to be further managed, as it is usually done, by any traditional organization.  Essentially, this makes a product definition into becoming the hostage of traditional organizational structure.

Larman’s Law #5 states: “culture follows structure“, alluding to the fact that in complex organizational settings, we should expect a cultural environment be a reflection of organizational structure.  By the same token, in product-centric/customer-focused organizations, organizational structure should follow product definition that an organization creates for customers, NOT the other way around: product definition should NOT follow a blueprint of traditional organizational design.

 

Leave a Comment

Please help us fight spam. Lets make sure you are not a robot !!!