Viewing entries tagged

Software Teams: Throughput is ALL that matters!


Software Teams: Throughput is ALL that matters!

In the late 1970’s I worked on an assembly line at Burnham Corporation in Lancaster, PA. This was after I separated from a stint in the US Army and during my tenure pursuing a BS degree in Computer Science.

Believe it or not, I was a “Boiler Maker” at Burnham. I was a member of an assembly line that assembled boilers from parts manufactured in the plant.

I know what you’re thinking. At last, Bob has “lost it”. He’s regressed back to the early roots of his working career, which has nothing to do with his focus today. He’s now become an “old man” telling “old man stories”.

Well I will admit that I’m not as young as I used to be, but I’ve been thinking a lot about this job recently and the similarities or lessons there from an agile perspective. I hope I can connect the dots sufficiently for it to make sense to you too.


The Agile PM: WIPping Things Into Shape

The Agile PM: WIPping Things Into Shape

I once was leading / coaching a team that struggled mightily to work together as a team. I was the Director of R&D at an eCommerce SaaS product company. We had been leveraging Scrum for a number of years with reasonably good success and had approximately 10 Scrum teams focusing on the various aspects of our online product.

But there were a couple of teams that were really struggling, which often seems to be the nature of things. Out of ten teams, we had about three that were high performing, three that were moderately performing, and three that struggled along. Don’t get me wrong, the team members were solid people and good employees. It was just that this whole “agile collaboration thing” was hard for some of them to grasp and embrace.

The Agile Project Manager--How do you want your Software, Good or Fast?

Picture this…

You are in a software diner one evening after a long day at work. A tired and disheveled waitress walks up to you to take your order—gum smacking as she goes over the daily specials. Nothing really sounds good to you, but you are extremely hungry and short on time. She summarizes the possibilities for you to help with your decision-making.

Honey she says—

You can get mediocre to terrible food fast or slow food that tastes good. But you can’t have both—good & fast food. 

It seems as if we’re always given certain choices in our software delivery challenges similar to what our waitress has given us. We have all heard of the “iron triangle” of Project Management—defining Scope, Cost, and Time as the three critical dimensions for a project. Usually Quality is placed within the triangle as a fourth variable—totally at the mercy of the other three.

The Agile Project Manager—The ‘Essence’ of Agile Metrics

I’ve been struggling for quite some time figuring out the “essence of” agile metrics. What are good ones versus bad ones? Are there related sets that are relevant and how many are needed? And how much change do we need to make from our traditional metrics thinking towards agile metrics?

One thing I have discovered is that metrics need to be “different” in an agile organization or culture. Traditional measures don’t seem to work within agile teams—as I’ve often seen them to cause dysfunction (more on that later).

Another thought I’ve had is whether they should represent a trailing indicator or a leading indicator? Meaning should we measure the processes (at the beginning or leading edge) or should we more so focus on the results & learning (at the end or from the trailing edge)? I’ll explore this more next.

Leading vs. Trailing Indicators

I think of measuring estimate accuracy (estimate + actual) as a leading indicator. Why is that since you measure actuals at the end of your work?

The Agile Project Manager—Traditional PM Triangle be Damned, Keep Quality First!

I can’t say how many times I have heard software practitioners talk about the Triple Constraints of Scope, Time/Schedule, and Cost as a triangle and suggest mental games of adjusting one and fixing the other two. Often you see Quality as a fourth constraint that is dependent on the other three, which is very true.

In my traditional project experience, stakeholders try to fix all three constraints—dictatorially fix them. This inevitably leaves quality as the only variable and, as teams flex on quality, the trade-off is hidden from the business until after the software is deployed.