Expectations are everything. If you set a goal, communicate it and then meet it, your team is thrilled and so are your stakeholders.
In the previous post, we outlined the Agile Resource Allocation Dilemma and recognized that this is a pervasive issue and a tough one to solve.
Congratulations! You have now convinced your management team to adopt agile. Everyone (or at least most) in your leadership team have extended their support toward this initiative. Everyone believes that this transformation will be excellent for your organization as 1) you are adopting agile 2) claim that your organization is challenging the status quo and 3) you will be able to do product delivery faster.
This article is about the third and final alternative to the Ideal Team Structure – feature teams with mixed-composite skill teams.
Pulling all the ideas together from this article series, I want to leave you with a couple of key thoughts when you are trying to design your agile organization:
In the last article, I outlined the Large Feature Team pattern as a first alternative to the Ideal Team Structure (ITS) if your organization cannot make the immediate leap to the ITS when transitioning to agile solution delivery. In another article, I provided an overview of the concepts of feature teams and components teams. In this article, I will discuss the second alternative using a combination of feature teams and component teams.
In previous articles, I outlined the guiding principles for organizing agile teams (start here if you haven't started the article series yet) and described the Ideal Team Structure (ITS). This is the first in a series of articles to describe various organizational design patterns to start the journey to the ITS given the real possibility that your large organization cannot switch to the ITS immediately upon starting the transition to agile software delivery.
I spent time outlining the guiding principles for organizing agile teams in my last article. With the challenge of delivering business intent where changes to 10’s of platforms / components are needed and we only have developers and testers who specialize in singular platforms / components - how do you organize? There have been many books, whitepapers, and blogs (see here, here, here, and here). talking about the tradeoffs of feature teams (which can also be referred to as business vertical teams or product-aligned teams) and component teams. A feature team spends their days delivering user stories that are highly reflective of needed business intent whereas component teams spend their time delivering user stories that are generated by the feature teams because they need components outside of their scope of knowledge or responsibility modified to deliver the overall solution.
Much of the writing on feature and component teams puts feature teams in the “good” camp and component teams in the “bad” (and sometimes “evil”) camp. With the challenges outlined above, to some degree, component teams might be a necessary evil. The key is that your initial organizational design has feature teams as well and that you are creating an obvious maturity path towards possibly eliminating the component teams by pushing that component skill and knowledge towards the feature teams through knowledge sharing and architectural simplification. Ultimately, the goal is to create feature teams of generalizing specialists, living and collaborating right with the BIG’s (Business Intent Generators), and able to create and modify 100% the system components needed to delivery that business intent – the Ideal Team Structure (ITS).
Before I get on with describing the less-than-ideal organizational models, I thought it would be useful to spend some time describing what the Ideal Team Structure looks like to paint the picture of the target. And what better way to paint the picture than with a picture…
Transforming to an agile software delivery model is filled with lots of challenges, especially when you are talking about solutions delivered in an organization of a large scale. In these large organizations, one of the most common practices to achieve perceived efficiency is to build an organization of specialists. Every specialist knows how to get their specific tasks done very efficiently. Additionally, large companies typically have very large and complex software architectures for their systems. Between the specialists and the complex architectures, the job of getting the entire solution delivered is actually very inefficient since it “takes a village” (often a very big village) to get anything delivered. The most intrusive inefficiency with these organizational models is that they are not designed with support for natural delivery flow.