April 2015 Archives

Specialization vs. Responsibility

Specialization is about being good at something, while responsibility is about having a duty to deal with something. While they are related, it may not be good idea to couple them together.

Component specialization and Feature responsibility

Conway's law states, "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"

Once you setup team with certain component responsibility, they specialize on the component naturally. Then, this becomes the source of inflexibility, when specialization is used to justify tying those teams with those components. Evolving architecture becomes harder when it is coupled with organizational structure.

The solution is feature teams with collective code ownership. The responsibility is on feature, while component responsibility is shared, do we still have component specialization? Most likely yes, at least at individual level. Some people are more knowledgable thus better at doing certain component work. Generalizing specialists starts with some speciality, then expands to other specialities. For example, you are the main developer on component A, and you expand to work on component B and develop specialty there over time. This may apply to team level too, since some features may touch certain part of system and the related components more often than other features. Specialization just happens. Since the responsibility is on feature, thus, the component specialization does not limit us from picking the most valuable feature items.

In short, have feature responsibility, and let feature guide component specialization.

Feature specialization and Product responsibility

The same dynamic happens with feature specialization. When the team has feature responsibility, e.g. it is a "Payment" team, the team specializes on the relevant domain. Then, this becomes the source of inflexibility, when specialization is used to justify tying those teams with those features. Evolving product becomes harder when it is coupled with organizational structure.

The solution is feature teams with common product backlog. Those teams have product responsibility, and they don't have special feature area responsibility such as "Payment". Do they still have feature specialization? Most likely yes. Given the team developed features in this area, when another high-value feature comes to same area, the team likely picks this one. Over time, they specialize on this feature area. This is even a good thing since it helps develop the deep knowledge and skills, but we don't want to label them as "payment" team and define their responsibility around this feature area. When that happens, we start to select features because we have suitable team available, rather than customer value driven. Therefore, every team is product team without having name tied to feature area. Instead of having "Payment" team, we have "Gryffindor" team. For specialization, we may even want to track and take advantage of it when possible.

In short, have product responsibility, and let product guide feature specialization.

Requirement area

If you work on large-scale development and adopt LeSS, you should have heard of Requirement area. Do we want to introduce areas with clear responsibility on product domains, or areas simply as groups of teams and let specialization on product domains happen and evolve? There is no simple answer. The bottom line is, Requirement area is dynamic. When you give Requirement area clear responsibility and associate it with meaningful area name (e.g. Security), it may help build the identity thus accelerate the specialization. On the other hand, this may also lead to Requirement areas standing still forever.


Specialization and Responsibility are two different things, and we shall not confuse them. Specialization happens, and you may want to track and take advantage of it, while narrow responsibility, defined around specialization and often labelled in name, decreases flexibility and leads to local optimization.

Back to fixed scope

I'd like to revisit the rationale behind moving fixed scope to fixed time in Agile development. By understanding what is essential, we may get back to the thinking of fixed scope.

Fixed scope in traditional development

fixed scope.jpg

In traditional development, we often start by fixing the scope (of the release), then work on how much time and how many people we need. The number of people is the main cost driver in software product development.

Fixed time in Agile development

fixed time.jpg

In Agile development, we often start with fixed time and fixed cost, then work on how much scope we can deliver within those constraints. Fixed time is implemented as iteration and is also called timebox. When the team is stable, we have pretty much fixed cost. Release consists of multiple iterations, and the number of iterations may or may not be fixed.

The rationale behind moving from fixed scope to fixed time:

  • Scope often has the most flexibility, particularly when you look into details. For complex product development, we learn the right scope over time, while fixed scope reduces flexibility and makes it difficult to respond to change.
  • Increasing the number of people, although increasing cost, may not increase the speed. This is best illustrated by Brooks's law - adding manpower to a late software project makes it later.
  • Time has less flexibility due to the growing need for short time to market and even occasions when the time delay is impossible (e.g. Christmas). Timebox helps prioritize and focus, as well as build development discipline.

Back to fixed scope

If you look at the rationale, it assumes that the fixed scope is big. When it is small and minimum, the problems with fixed scope disappear. Therefore, the key problem is big fixed scope. Timebox is one approach to reduce fixed scope. Another approach is to limit WIP directly as done in Kanban. Limiting WIP helps prioritize and focus too. The remaining advantage from timebox may be the support for building development discipline.

With further scope optimization, our focus moves towards identifying the meaningful minimum. It is MMF (Minimum Marketable Feature). In terms of story mapping, it is the minimum slice rather than a single story. The time to deliver MMF is not fixed, but usually short due to the minimum scope. Once we identify MMF, we develop it and release it, with the discipline of continuous delivery. We are back to the thinking of fixed scope, but small fixed scope.


The thinking of fixed scope is not the problem. The problem is that fixed scope is too big. We solve it by reducing it. We may apply timebox, which is the way behind moving fixed scope to fixed time. We may also limit WIP directly, which is the Kanban way. Eventually, if we identify one MMF each time and make continuous delivery, we are back to fixed scope, but very small.

About this Archive

This page is an archive of entries from April 2015 listed from newest to oldest.

March 2015 is the previous archive.

June 2015 is the next archive.

Find recent content on the main index or look in the archives to find all content.