Rudyard Kipling wrote an often quoted poem called the six honest serving men, which contains the lines:
“I keep six honest serving-men (They taught me all I knew);
Their names are What and Why and When And How and Where and Who.”
Can the design principles of coupling and cohesion be applied to organisation design in the same way they are applied to software design?
The amount of communication paths / dialogues people have to maintain with each other to share the context of what they are working on in a team is, I believe, critical to delivering quality software at pace, here are some of my thoughts….
I’ve been wondering recently if mentoring from a distance (as in not the same office) is possible. If mentoring is a long term investment in creating a working (in this example) relationship where things are shared very openly, then what are the challenges of doing that remotely?
“In quantum mechanics, the uncertainty principle, also known as Heisenberg’s uncertainty principle, is any of a variety of mathematical inequalities asserting a fundamental limit to the precision with which certain pairs of physical properties of a particle, known as complementary variables, such as position x and momentum p, can be known simultaneously.”(Uncertainty Principle, 2015/09/30)
Hopefully that wasn’t too scary any opening gambit! My point is that I’ve seen some managers and leaders try to govern complex problems by measuring a small number of critical parameters. I think that data driven delivery is great, but I caution anything which could discourage thinking about the broadest problem to be solved.
After a small stint working for a media company I’ve seen a little of editorial independence in action, I think it has benefits for freedom of press. I mention this by way of analogy as I think there is also a benefit to separating out ‘what’ you want to achieve the product goal, and ‘how’ you want to achieve it and having the best possible ‘how’, the architectural approach, at least initially not constrained by the pressure of also defining how and when it will be delivered.
I’d like to start by saying my problem isn’t with project management, it is with a large number of people who are project managers of software delivery…..
In my opinion there are many ways to manage delivery, and when the delivery involves knowledge work (as software development clearly does) a focus on one blunt instrument is not useful or successful. That blunt instrument is the date of delivery, hence the date stamp image!!
Applying a consistent measurement approach to teams can be a contentious issue, I believe the foundation of any attempt to measure a set of teams in the same manner is to use this as a tool for the teams to reflect on how they are working and discuss with other teams, rather than any sort of ranking or absolute value comparison. So as a senior manager I might use a comparison to ask a question like “why are this team having such high variance in delivery?” or “are we taking too much risk in this area?” As opposed to team x are not as good as team y.
I blogged about a recent team celebration on Betfair’s engineering blog here: betsandbits team celebration post
Great day out and truly worthy of celebration.