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.
I’m a Certified Scrum Coach and I know quite a few CST’s. Many of them offer training and coaching as part of their services. However, the typical client interaction, either with public classes or private training engagements, for many of them is as follows:
- Deliver a 2-day CSM class to a group of mostly client team members
- Rarely deliver a “talk to leadership” as part of the engagement, as theirs is more of a team-centric play…
Then they move off on their merry way. One of the “tag lines” of the Scrum Alliance is “Transforming the world of work”; so many CST’s get a sense of accomplishment at this point—feeling that the world of work has been, well…transformed.
There are two questions that I get more than any others as I travel around sharing on agile topics:
- How does agile work with distributed teams?
- How can agile deal with fixed price, fixed scope contracts?
And these questions are usually not simply questions. They’re thrown down as “gauntlets” that defy agilities promises. Often they are prefaced with – “Hey Bob, but in the real world…”
In our latest Meta-Cast, Josh and I went through a couple of questions from the audience. One of the questions surrounded what to measure for individual developers. To be honest, I was taken aback by the question.
You see, I’ve been preaching for years that when you move to agile metrics, you want to do four things:
(One) Move from individual team member metrics to a more holistic, whole-team view.
(Two) Move from measuring functional teams, for example test team progress, again towards holistic, executing agile team view.
If you’ve followed my blogging at all, you know that I’ve worked for several companies in the last 6-8 years that have colored my thinking as an agile coach. Sure, I’ve coached a wide variety of other organizations, but there’s nothing like being an employee of a company and assuming the role of technical leader and agile coach to get your attention each day.
One of those companies was iContact (now Vocus), which develops an email marketing SaaS platform. This story comes from my time spent there working with some wonderful development teams.
A rather long time ago I was in a meeting with a fairly senior development director and we were talking about annual roadmap planning. He was complaining about things. One of the things he brought up several times was race horses. He kept saying –
Bob, we simply don’t have enough race horses.
I became confused and a bit frustrated and I sort of lashed out saying –
What do race horses have to do with us meeting our software product goals for next year?
He said – no Bob, I’m talking about resources, not race horses.
After all these years, I still find this story both amusing and troubling at the same time. I think we often overuse the term resources as leaders, managers and project managers in software discussions.
Mike Cottmeyer is one of my favorite agile coaches and leaders within our community. When he worked for VersionOne years ago, I used to read his blogs fairly often. Now that he’s been out on his own with LeadingAgile, I don’t get the chance as often to experience his thoughts.
So I was pleased when I ran into a recent post by Mike that had the same title as this post. I read it with anticipation, and as with all of his writing, Mike made me stop and think a bit. Here’s a context snippet from Mike’s post:
I was talking to an experienced Scrum Master and Agile Coach the other day about agile in general and the topic of stand-ups came up. It seems he’d had an “experience” at one of our local agile group meetings where Daily Standup dynamics were being discussed.
Here’s a link to the session. It’s a meeting from our local Raleigh, NC AgileRTP group. The topic was entitled: Do You Stand Up? I missed the meeting, but he recounted the general discussion and flow for me.
The group consensus was that: 'Chickens' (interested bystanders, stakeholders, leadership folks, etc.) should not talk during the Daily Scrum. The rational mostly surrounded that at it would interrupt the teams conversations and flow.
The Scrum Master disagreed with this view and he (jokingly) said that—when he brought up his perspective, the crowd summarily dismissed him as being wrong.
The other evening I attended a presentation on agile metrics by Larry Maccherone of Rally Software. It was a great presentation. But he said something along the way that has been bothering me since. Let me try to get you in the right place by setting the stage a bit.
He started off by saying the agile metrics in general are “Context Based”. That is, your business space, problem domain, company maturity, technology stack, size and maturity of your team, etc; ALL come into play when determining your metrics. I guess this implies a one-size-fits-all approach doesn’t work and, in fact, that there is a unique size per agile context.
He had me at hello with this one.
