Showing posts with label productivity. Show all posts
Showing posts with label productivity. Show all posts

Saturday, May 16, 2009

Throughtput: Changing the people

First, I just want to mention that I haven't posted anything for a month because I've been really distracted with my current assignment, which is three months in India (Bangalore) to be a trainer for ThoughtWorks University -- an intensive six week introduction to consulting and software development the TW way for entry-level new hires. I'll start blogging about that in my next post. But now, more about throughput:

In my previous post on this topic, I said that if you felt you weren't getting sufficient business value in each release, or it took too long between releases, then you had a process and/or people problem. I wrote that people problems required changing the people.

I want to clarify that. Superficially, it would seem that I am recommending getting rid of staff. That's one solution but not necessarily the right solution. Changing people may also mean making changes to people's job descriptions and assignments. Remix the people who make decisions about new features and enhancements. Add some new faces or switch/promote people into different roles.

It may also mean changing how you relate to your staff so that people understand you expect them to be creative and innovative about the software and the decision process. Let them know they'll score more points with you by taking chances, and you will support them, even when some of their ideas don't pan out as well as others.

Chapter 7 of Scott Berkun's new book, "The Myths of Innovation", does a very good job of explaining the tension between innovating and managing. On page 96, he writes: "... few managers recognize that their training and experience, designed to protect what exists, work against the forces needed for innovation ..."

On page 98, he quotes from Peter Drucker, "... management tends to believe that anything that has lasted for a fair amount of time must be normal and go on forever. Anything that contradicts what we have come to consider a law of nature is then rejected as unsound."

Finally, on page 100, Berkun writes, "... most management, most of the time, is sensibly directed at maintaining good business.... However, when managers raise the flag of innovation, the goals change, and the methods must follow. Many depend solely on Taylorism-inspired behavior .... as a rule ... they avoid all risks, never yield creative authority and operate with self-centric hierarchical control over the flow of ideas."

That's thing that has to change, the behavior, not necessarily the staff composition.

Tuesday, April 7, 2009

Throughput: How can I get more of it?

A while ago, a friend and I were comparing experiences on our projects. She talked a little about one of her key stakeholders and said, "He asked me how could he get more throughput out of his team. I didn't know exactly what to say."

Throughput, eh? The word calls to mind network traffic and bits and bytes of data streaming over cables or fiber optics. It's not too far of a jump to extrapolate that to manufacturing or industrial processes like gallons of oil pumped through pipelines or numbers of cargo containers moving through shipping terminals. You could imagine the term applied to fungible goods or relatively interchangeable units of stuff moving on assembly lines. But we were talking about software so what was interchangeable or fungible about that? Lines of code? Nope. Function points? Features? Well, maybe those things are countable. But to what end?

"So, what was he really thinking about?" I asked my friend. "Is he saying that it's taking too long to get a release delivered or is he saying that he's not seeing many significant changes in the releases?"

"Well, both," she said.

"Ahh. I see. What you have there is either a process problem or a people problem or both. And whichever it is, you have the wrong thing and probably too much of it."

If it takes too long between releases, you have a process problem and you probably have too much process -- too many steps, checkpoints, sign-offs, etc.

If you don't get much value out of a release, you have a people problem. The wrong people are making decisions or you are not talking to the right people to get ideas.

Change the process, change the people and throughput should improve.