Bob's Blog
Bob is a prolific blogger who simply enjoys sharing his experiences with colleagues in the Agile Community. Topics revolve around Scrum, XP, Kanban, Project Management, Business Analysis, Testing, Leadership and General Musings.
Check back often as we've always got something to say...
My partner Josh Anderson and I just finished a Meta-Cast on the topic of self-directed teams. One of our listeners asked us to share our thoughts on handling agile team members who simply wanted to be “told what to do”.
On the surface, this doesn’t seem like such a bad thing. In fact, I’ll bet these folks are bright, capable and work very hard. They’re also probably “good people”. So if there is an issue with this in agile teams, what is it? And why would it be a problem?
As a coach, I’m getting truly tired of talking to managers and leaders who’s sole drive to adopt agile methods is for…
More, increased capacity, to go Faster!
For example, I ran into a few leaders of one company at a conference. They came to the conference to learn a little bit more about “Agile”, but they’d already made the decision to adopt it within one of their key divisions.
Not only had they decided to adopt it, but they’d already decided that agile would give them an increase in capacity, so they reduced the development teams in the division by 50%. The thought was—agile will give us a force multiplier of at least 2x our capacity, so we can redirect those resources (people) to other initiatives.
I remember over 25 years ago when I learned about developer to tester ratios. It was my first experience at management and we were planning our hiring for a 2-year forecast. We were expecting to grow by roughly 25 staff in our software engineering group and the question was posed to me regarding developers vs. testers in our hiring plan.
To be honest, I didn’t have a clue. My boss stepped in to help me out and he spoke about a 5:1 ratio as being industry standard at the time, so I took him on his word and used it for my forecast projections. Heck, I didn’t know any better. It seemed to work, but that was a long time ago.
The Agile Austin conference was held on March 21 in Austin Texas. It's been held since 2012, so this was the third annual conference.
I'd submitted a couple of talks and was lucky enough to be selected to present. Most of the presenters were from the local area and Texas, but a few "out of town" folks participated. Since this was my first Agile Austin conference, I didn't really know what to expect.
Well, it was a blast. 500 raging agilistas showed up. They apparently sold out the event with about 100 on the waiting list. Imagine that? I was talking to one of the organizers and he said people in his company were asking him to "get them in" and he had to turn them down.
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.
Nick Zdunic wrote a nice review of Scrum Product Ownership, the 2'nd Ed.
It's been about a year since I release the new edition and it's influencing Product Owners around the world. I'm quite pleased with the interest and the results.
You can get a free PDF of the book by simply joining our mailing list...
I was working with a colleague the other day and we were talking about speakers for a possible local agile conference.
I brought up a few people that I respected in the national agile community and, almost to a person, they discounted them as being “the same old…same old” presenters. From their perspective, they were looking for more:
And I think I understood the point. We can certainly get repetitious in our industry. Following the same old pundits with the same old messages. But at the same time, something bothered me and for quite awhile…and I couldn’t put my finger on it.
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:
One of the greatest gifts the agile movement has given us is to quantify something we’ve been ignoring in software development for the last 50 years. That is, the notion that software degrades over time, it ages, and it needs ongoing maintenance to keep it viable. That idea is Technical Debt.
Most developers have known that for that same number of years. That no matter how well something is designed, it won’t stand up to real-world usage for 2-5-10+ years without a significant investment in rework and redesign. The agile community has coined a term for that as well—refactoring.
I just registered for the Scaled Agile Framework, SAFe Program Consultant (SPC) class.
I’ll be taking the course April 22-25 in Boulder. One of the reasons I picked this class is that Dean Leffingwell, the creator and prime instigator of SAFe, is teaching it. Much as I did in 2004 when I took my CSM certification with Ken Schwaber, I want to get it “from the horses mouth” so to speak.
I’ve been sitting around far too long observing it from the sidelines or peripherally and feeling quite apprehensive about the implications that SAFe has across a variety of agile principles.
Another driver is that many of my coaching colleagues have taken this course and are recommending & leading SAFe initiatives. I respect them and their balanced judgment, so I want to approach the class with as few preconceptions as I can. I’ve long respected Dean for his work in RUP and software requirements, so I want to give it (and him) a fair shot.
