Have you made a method work for you? How did you make it fit in your unique context?
I’m currently cleaning up my trusty old Mac Mini G4. I’ve been cleaning out old stuff I don’t need to save, and a few days ago I installed a cheap 1 gig of memory. That upgrade did not make the machine notably faster. Today, however, I ran a bunch of maintenance tools, which seemed to do the trick. There’s a noticeable improvement in the speed of the little things, like how long it takes to fold out a menu. There was a delay before, and now it seems to be gone. Hope it lasts.
Energized by my success in speeding up the old can, I started another round of file cleaning. I found an old NeoOffice file called “Russ Ackoff – 95 Percent”. Because NeoOffice has always been extremely slow on this old machine, I wanted to see how fast I could open it. That, and the fact that I’m always interested in Ackoff’s teachings.
NeoOffice turned out to be as slow as before, but the file contained pure gold. Not new gold, but pure gold. In it was a little piece of knowledge that I’ve been using in my scrum master classes for a few years, ever since I came across it on the web.
Here are the contents of the file, which I remember transcribing from a sound file as I listened to it:
“http://www.open2.net/systems/practice/rus12.html
1900 – 95% of the people in the US could not do the job as well as their bosses could.
If the foreman retires from a group, you pick the best man to become the new foreman.
He can thus do the job better than any of his subordinates.
He will continue to rise as long as he is the best in the group.
All managers thus rise to the level of their own incompetence.
Today, 95% of the people can do their job better than their bosses.
You cannot manage them the same way.
Don’t manage what they do – manage the way they interact.
Requires different organization, and a different type of management.”
Reading a blog post by Tripp Babbitt reminded me of Ackoffs discussion on internal market economies in Re-Creating the Corporation.
Babbitt’s blog post talks about how focusing on cost reductions often increases costs. One reason is that cost reductions are often approached by centralizing services in organizations. When this happens, a feedback loop is broken. Those who produce the services are no longer those who consume them. This means that they loose their understanding of how well the services work. When the consumer of the service sees the service degrade, they cannot easily improve the service, because they don’t control the production of it. Instead, the consumers work with what they can control, which sometimes means reproducing the service locally, thus increasing total costs.
How can we use this insight to improve software development?
In software development, we sometimes see this phenomenon with centralized platform teams. A platform team is formed to develop shared functionality, to be used by teams that develop actual product features. In reality however, platform teams often have a hard time living up to the expectations of the feature teams. Because of this, feature teams sometimes choose to locally develop functionality that was supposed to go in the shared platform.
Another example that comes to mind is when organizations set up project management offices, and these offices proceed by pushing out standardized methods of work, instead of listening to the needs of the different areas of the corporation. Again, the idea here is to save money by standardizing, but the result is often frustration, because there is no such thing as a one-size-fits-all way to manage projects.
One final example: the central database administration group. Created to gain control over database services, it soon becomes the bottleneck more than anything else, stopping projects dead in their tracks.
In Ackoff’s solution, departments within organizations should be free to procure the services they need from internal services and from anyone on the open market. If top management wants to override a department’s decision to procure externally they can do so, but will have to use their own budget to compensate for the losses the buying department suffers through this decision.
In other words, if a sales department is forced to procure their new IT support system from the internal IT department, even though they could have gotten the same solution for a cheaper price from an external provider, the overriding manager will have to compensate the sales department for the difference in cost.
Well, this is really a bit outside of my area of expertise, but interesting nonetheless. My learning goes on.
What are your experiences of centralized services? Good? Bad? Why?
Whenever something unexpected happens – such as when we make a mistake – there’s a possibility for learning to happen. For example, I just tried to add an extra branch in my mind mapping tool, but I pressed the wrong key combination. Instead of a new branch, a nice little yellow callout appeared. I immediately liked it, because it seemed like a useful thing.
What mistakes have you done recently, and what did you learn from them?
Today is the birthday of systems thinker Russell Ackoff. Happy birthday! The Ackoff Center Weblog has a picture of the official cake.
What! You say you like agile software development and still don’t know who Russell Ackoff is? Get right over to his wikipedia entry. Or listen to him – he is a great speaker.
Clarke Ching has written a nice little piece that’s available as an online read on Slideshare, and embedded below. It’s short and plain enough that it has the potential of becoming widely read. I’m predicting it will spread quite fast. Executive summary: releasing wanted software soon and frequently ties up capital for shorter durations, which is A Good Thing in cash-tight times.
Three short clips featuring systems thinker Russell Ackoff have been made available on YouTube, and embedded below. Ackoff speaks plainly about profound things, so listen closely, and don’t mistake his plain words for a lack of depth. I’m not an expert, just an interested student, but it seems to be that Ackoff’s great contribution is a clear and understandable explanation of how systems concepts can be applied in organizational thinking. Here are a few key points about the nature of systems, presented by Ackoff in these clips:
As an example, here are a few quick thoughts on how our thinking about software development teams needs might change if we look at them through the systems thinker’s eyes.
What happens when we try to break down processes that are really too complex to explain in the details, and then teach the process as if it was a stepwise instruction? We run the risk of dumbing down the process to exactly that which we can transfer explicitly, as this classic Internet meme perfectly illustrates:
I’m back from a course in Stockholm on the topic of lean software development. While it was definitely not a waste of my time, it’s lack of depth and long lectures disappointed and puzzled me. Longing to learn some new stuff, I spent some time tonight googling for articles about, or written by, systems thinker Russell Ackoff. Coincidentally, I found a good article that managed to touch both a lean concept (although the moniker “lean” had yet to be adopted when the article was written) and mention Ackoff. What I found was a funny piece on some of the practical applications of queueing theory from the September 25, 1988, edition of the New York Times.
“One way to take some of the sting out of waiting is to entertain customers. Since 1959, the Manhattan Savings Bank has offered live entertainment during the frenzied noontime hours. In 13 branches, a pianist performs and one branch has an organ player (Willard Denton, the former Chemical chairman who dreamed up the idea, liked organs, though present management thinks they are a trifle loud for a bank). Occasionally, to make line-waiting even more wonderful, Manhattan Savings has scheduled events such as a fancy-cat exhibit, a purebred dog show and a boat show.”
I also came across an elegant article about the differences between push and pull.
“Now reverse the logic. Suppose the customer pulls the product or service required through your system. Because you’re making what someone has actually ordered, you don’t have to guess or predict sales and production. You don’t have to add extra features or colours to tempt people to buy. If you’re not making things on spec, you don’t need the space, computers or people to store and track the inventory. “