« Consulting from the Outside-in | Main | Too Lazy To Refactor? »

18 November 2012


Feed You can follow this conversation by subscribing to the comment feed for this post.


Nice article Rachel

Let me add to the discussion re OCP/LSP. I think an anti-pattern in organizations is treating people as plug replaceable programming units. OCP/LSP for organizations means shifting people around as if they are plug-replaceable or adding more 'resources' to late projects to extend the teams ability ability and capacity.

Dave Nicolette

Solid thinking, as usual (no pun intended).

I might quibble about the word "refactoring" in this context. If the goal is to change communication structures so as to improve the organization, then we are after behavioral changes, not only implementation changes. With that in mind, I wonder if "transformation" would be more to the point.

Regarding the apparent conflict between "agile" methods and the individual specialization implied by SRP, it seems to me that the "agile" approach treats the team, rather than the individual, as the unit of labor. (The other sections in your article also focus on the team; only the bit about SRP focuses on individuals.) In that case, a standing team whose purpose is to support a given set of technical assets satisfies both the SRP and "agile" preference for multi-skilled, cross-functional team members who freely cross traditional role boundaries. So, I think SRP can be applied to the people domain in an "agile" context with no conflict.


Classes should be open for extension but closed for modification, not the other way around.

Interesting take on teams here, thanks. Björn ACCU

Rachel Davies

Thanks, James. I agree with your comment about treating people as replaceable programmable units. The idea of applying design principles to people and organisations seems to ignore the fact that each person is unique in their experience and that their personal motivations and choices need to be factored into any decisions. However, I think attempting to streamline communication and work flows can reduce people being overwhelmed by too much work and make meetings more relevant to the work at hand.


Rachel Davies

Thanks, Dave. You're right, this is more than refactoring, it's change with the intent of improving. For the copy of this article in XPDay magazine, I've changed it to say "improving" as I tend to associate the word "transformation" with magic applied from the outside. Coaching is change applied from the inside by working directly with individuals concerned, directed by their choices.

Regarding SRP you could think of individual developers as being instances of Developer - agile approaches set up pools of autonomous individuals with clear interfaces about how they engage with the rest of the organisation.

Rachel Davies

Thanks for the correction, Björn! I've made that correction now.

Allan Kelly

Interesting idea, I think about Conway's Law a lot in my work, and Reverse Conway's Law when the org becomes a copy of the system. The homomorphic force works in both direction.

SOLID for teams is an interesting idea but I'm not sure it takes us anywhere. I'd rather think about what we want from teams and then decide what the mnemonic would be.

Continue this at XP Day

Arjen Uittenbogaard

Hi Rachel,
Nice topic! Coming from an OO background, I've been applying the OO principles quite a bit on organisational level. I wasn't aware of the SOLID acronym, but it's a nice summary of good OO principles. My two cents:
* I'm sure more can be said on each letter, but I'd like to go beyond your comment on the Open/Closed Principle. You say people cannot be extended. However, as a trainer/coach I tend to disagree - isn't learning new skills and behaviour some sort of extension? I also like to point to improvisational skills, which help 'extending' ones behaviour! The 'Closed' part of the principle, I would translate as: but stay yourself.

* Secondly, I'd like to point to remarkable (or maybe not so?) similaraties between the three principles Dave Snowden stresses for resilient organisations: distributed cognition, disintermediation and finely grained objects. A concise summary of what OO is all about, if you'd ask me :-)

Ruud Rietveld

Nice article! I think the SRP applies to teams in the way that they should be wholly devoted to their project/product, and not be distracted in their work, which is also what Scrum advocates.

Juanjo Fuchs

Great article! It's an interesting point of view, taking into account that the team is a unit and meetings are interfaces through which the team communicates with others.

As I understand this post:
* SRP: As Dave pointed out, one team, one product.
* OCP: I agree with Arjen, extend people's abilities by learning, but do not change/replace them, avoid affecting the synergy of the team.
* LSP: The way the team accepts user stories and returns deliverables should remain the same, independently of the nature of the request (i.e. feature, user manual, etc.)
* ISP: One meeting, one purpose.
* DIP: Don't quite understand the correlation yet.

It's my point of view, hope it helps. I'm exited to see how this evolves!


I recall a conversation a few years ago where enterprise architects were talking about designing the whole org around OO principles. Never saw anything come to fruition though.

I am with Dave. If you find time I'd be keen to see you do this over with your sights set directly on the team as the unit of construction. I'd also be interested in seeing your thoughts at the whole org level and not worry so much about scrum teams as a specific exampls.


"Open/Closed Principle .... We can’t really extend or modify people"

Can we not? Surely we can cross train people and we can help people get on better together and deliver a better work product through coaching and behavioural feedback.

Curtis Cooley

How about this:

The spirit of DIP stems from how those new to OO tend to create systems with a lot of concrete objects all dependent on each other. DIP says to invert those dependencies and depend on abstractions instead.

Traditional development has team members depend on architects for design and management for organization. Agile says the best designs, architectures, and requirements come from self organizing teams, so we need to invert the dependencies and allow team members to depend on each other.

Lloyd Holt

We can certainly apply Conway's law to the current state if afairs in Washington, DC.

No communication No workable systems being designed

The comments to this entry are closed.