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.