In my last post I talked about a tendency some organizations (and individuals) have in jumping on the latest fad in building software teams and the methods for producing value. Beyond jumping on tactical or practice bandwagon’s, there appears to be a war going on related to traditional hierarchical organizational structures and traditional line or functional managers
Now to be clear, my context is 90% from an agile adoption and transformation perspective. And this isn’t some new phenomenon, as it’s been tied almost to the inception of the agile approaches.
I remember years ago, Microsoft was considered the benchmark of all things leading edge when it came to software development. They seemed to be the “poster child” for how to build software organizations and software products.
For example, they had a multi-tiered strategy for a code freeze model and everyone seemed to be copying it. And today their Software Developer in Test (SDET) model is also incredibly popular. There were many books written about their strategies and approaches, and everyone seemed to want to “be like Microsoft”.
What’s interesting to me is my perspective. If you’ve been in technology long enough, you see recursive themes unfolding. What today is a benchmark company with everyone jumping on the bandwagon to copy them, in ten years becomes a passing thought. Microsoft is clearly an example of this curve—first being the “darling” of what to do – to falling into a category of status quo or even an anti-pattern. Sure, Microsoft is still a viable company and sometime role model, but it’s no longer seen as the one to emulate.
In my travels I spend a good deal of my time discussing Scrum Product Ownership, Product Backlogs, and inevitably User Stories. Stories are containers or artifacts, which have nearly become ubiquitous for handling software requirements within agile teams.
Most seem to be a using the standard phrasing construct for his or her stories:
As a – User
I want – Feature or Functionality
So that – Business why, What problem does it solve?
Because the “User” clause is so simple, I see many teams who fill out their user stories in a by-rote fashion. They’ll literally have hundreds and hundreds of user stories, features, themes, and epics and all of them have “User” as the user.
I often cite Salesforce in my classes as a company that has:
- gone “all in” from an Agile Transformation perspective;
- done it in an abrupt Top Down fashion;
- has gone from technology to IT to now Organization-wide in their adoption;
- but most importantly is a company who shares its lessons in the community.
I always lament the fact that too few companies that are adopting agile approaches actually share their lessons publicly. Oh sure, some small bit leak out, but most unfortunately decide to keep their practices to themselves.
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.
