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:
- Fresh meat or new blood
- Novel or breakthrough ideas
- Something “different”
- Out of the Box thinkers
- More modern and energetic
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.
I don’t know what it is lately, but I’m encountering way too many agile teams with challenging work environments. Ones where the dynamics the team are trying to deliver software in are, in a word, crazy. For example:
- Teams are knowingly committing to more work in each sprint than they have capacity for;
- Teams are knowingly committing to specific date targets without having clear velocity data and/or without doing a modicum of agile release planning;
- Teams are ignoring the reality of their environment in (interruptions, multi-tasking, fire-fighting, knowledge & skill level gaps, etc.) and are pretending it won’t happen;
- Teams have shared team members or team members with limited capacity, but they’re ignoring this in their commitments.
This would be like your home builder knowing that it’s going to take them 5 months to build your house because of their teams’ capacity constraints, the complexity of the home, and the seasonal weather constraints, BUT they commit to 2 months anyway.
My reaction to all of these is the same: Are you crazy? And more importantly, how is this approach working out for you?
My wife and I saw two movies over the holidays. One was The Hobbit: The Desolation of Smaug and the second was The Hunger Games: Catching Fire. Both were the second episodes in a three part series. I suspect both were shot at the same time as their concluding episodes as well.
No, this is not a movie review, although both of them were “reasonable” follow-ups to their opening episodes. But both also had a similarity—one that bugged both my wife and I very much.
Both of them left you (the audience, the customer) hanging at the end. And I’m not talking about a subtle ending that hinted at a future plot direction. I’m talking about an abrupt, no warning at all, CUT off of the movie in lieu of the next (and hopefully final) installment.
I want to share a story from a Galaxy Far, Far Away.
It’s been on my mind quite a bit of late, as I tell it in some of my agile classes. However, I’m unsure whether the students believe me or they glean the significance of the story. I usually share it to illustrate a key point around software requirements. I usually get LOTS of pushback in my classes surrounding the “goodness and need” for fully documented requirements in software projects.
And as I unfold the agile approach to requirements (user story based, conversational, acceptance-driven, intentionally incomplete, and did I say collaborative?) the class starts turning ashen-faced in disbelief. Particularly attendees who are Business Analysts, Project Managers, and Testers struggle with the essence of agile requirements.
So that being said, I thought I’d try telling it here by writing it down.
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.
