Bye, teams!
My partner is an Agile software business analyst. Until I met her, if you'd asked me, I would have told you that in my experience BAs were blockers, not helpers. The BAs with whom I worked at best stayed mostly out of the way; at worst, they actively made my job as a dev more difficult with absurd metrics and processes.
T-shirt sizing? Really? I’m surprised that it’s not wet t-shirt sizing.
But my partner changed all that. Watching her work was a revelation. Not only was she not getting in the way, but she was making things hum. I had to eat a bit of crow. Luckily, it wasn't as nasty as I've been told. Tasted like chicken.
She has been sharing her knowledge, skills, and ideas via her consulting web site, jimmyco.io as well. She publishes articles monthly, and, as I am her editor and proofreader (and occasionally her muse), I get to read them—typically several times and at different stages, so I get to see her ideas emerge and evolve.
Two articles that she published recently really got me thinking. The first was about how BAs function as a sort of team infrastructure. She makes the analogy to network infrastructure, with BAs acting as cache, router, and logger while providing filtering, queueing, ordering, sorting, mapping, parsing, conversion, etc.
You get the picture.
I should repeat here that Hannah is an “Agile Software BA“. There are many different types of BAs—a big problem with the role IMO as it is too loosely defined. Maybe split it up and name the parts better? "BA as team infrastructure" applies to the Agile BA. For the rest, YMMV.
What struck me about this is that I had always focused on the analysis part of BA work: breaking things down into small parts and working with each in isolation. What I had never considered was that there was a complementary function that BAs perform: synthesis.
How Hegelian! Who knew?
Then her next article began to experiment with systems thinking and the use of Current and Future Reality Trees for BA work. And as I was proofreading, I was thinking, "How many times have I told her not to split infinitives?" Ha, ha. Joking. What I was actually thinking was, "This is fucking brilliant". But don’t tell her I said that.
Management FTL
I have written more than once about what a bad idea software teams are for business. In the process, I have probably antagonized almost everyone I know in the industry, but, hey! A boy should do what he does best, no?
It may be possible to create a worthwhile team, but why bother? What does it get you that you cannot get without it? It is an obvious failure to follow Occam's Razor: do not needlessly multiply entities. Or, as Mies van der Rohe counseled us: less is more.
Why are these simple concepts so difficult for humans to grok and apply?
What happens more often than not with teams is that they are chosen virtually arbitrarily (read: utterly capriciously). No one seems to know what the point is. It is simply assumed that we must have teams.
Sometimes they are organized by product, or by feature, or by project. Sometimes they are organized by service. But I remain unconvinced that these contexts are reason enough to force people to work together.
And there is an enormous amount of nonsense out there about "high performing teams" and how teams make everything better. I have worked on many teams and with many more, and I have yet to see a single “high performing” team. Maybe what they mean is "not totally worthless". I might have seen one of those.
It is all utter bullshit. Sorry to point out that the emperor is naked, but, well, his junk is hanging out. Look for yourself. It ain't pretty.
Besides, pointing out hypocrisy and stupidity is what I do best.
The case of the vanishing adult
The real reason businesses create software development teams is to manage the immaturity of their workers—immaturity that they nurture and perpetuate because mature workers might wake up and figure out how badly they are getting fucked by management and the company.
Then they might quit, start their own companies, organize unions, demand benefits and better wages (or control of the company), or—shudder—worse. Can't have that.
It's about the reports
Teams exist to group workers into a manageable number of "reports". Kind of a giveaway, isn't it? It’s not about getting work done or “delivering value to the customer” (ROTFL). It’s about reporting up the chain of demand.
Then we add layers of useless "management" in a pyramid shape to keep an eye on those troublesome toddlers. And toddlers to watch the toddlers. Hell, it’s toddlers all the way down!
Hmm. As ye seek, so shall ye find.
Seriously: no way that smart, mature adult devs, testers, designers, etc. could work together like, well, adults to accomplish their goals, right? We must shove managers down their throats to get in the way of everything and impose arbitrary and capricious constraints—as is their wont.
Teams actually help to justify managers because they are virtually always organized with no thought whatsoever to whether these particular humans will work well together. Or whether they have the right mix of skills needed for the job. And often, whether they have anything whatsoever to do with the product.
I have repeatedly worked on greenfield projects where I was the sole dev, only to be stuck in a convenient "team" so they could keep an eye on me. As if my product and productivity weren't readily evident.
I had to be on some team, right? The alternative was unthinkable. Rogue dev!
It pissed me off, and it antagonized my “teammates” as well. What a waste of time and effort! How remarkably disrespectful to the very people the company depended on for its success.
That meant insanely stupid and wasteful stand ups, retros, refining sessions, code reviews, and more where they didn't know what I was doing and did not give a flying fuck—and who can blame them? And I felt the same way about what they were doing.
The standup, rather than being a quick ad hoc gathering of only those currently working on a specific goal to check coordination becomes an inspection where the boss checks to see that you are working hard enough.
Kind of like how you have to drive across town, destroying the environment, to sit in an ugly office under fluorescent lights in plastic boxes just so your boss can walk by and see that you are slaving away. And they use the same “collaboration” lie to justify it. How insulting.
First, we kill all the managers ...
Sorry, managers, but I've met maybe two in my entire, decades-long career who I thought were worth a shit. And we could have made do without those two as well, much as I liked them.
There is certainly a skill to managing. And a very different skill to leading. But I have never understood why “managing” implied a hierarchy with the manager “above” those “managed”. I need testers and designers and more to do my job. That doesn’t mean that I’m above or below them.
Oh, but it’s about bossing, right? But why does anyone need to be bossed? Aren’t we all on the same side? If one of us is not pulling their weight, then the group as a whole can straighten their ass out. It is quite effective.
But being immature infants, most members of the team can't figure out how to play well together, so the BA comes in—if the BA is worth a damn—and makes it all run. See Hannah's article for the details of how.
But as I read her next article about CRTs and FRTs and applying systems thinking to BA work, I realized that this is the answer!
Fuck teams! All we need is reasonably mature workers and smart BAs to make the group work together as a whole, like a crew team racing in perfect synchronization. And the BAs aren’t above the other workers. If anything, they are below, providing a foundation—that infrastructure—on which everything else depends.
Think about it. Mature adult devs can collaborate and coordinate without help. Then the BA works to facilitate (not control) those efforts. Everything runs smoothly, and we can finally defenestrate the “managers”.
The BA should, as Hannah does, see their role as a service role, not a management role: provide the grease that makes the machinery sing.
Again, think about it. Does the BA, in making “her” team hum, work only with the members of that team? NO. She is interacting with all sorts of teams.
So then what is the point of these team boundaries so arbitrarily drawn? Other then to impose managers (product owners, what have you) on workers, what use do they serve?
We can assign work to individuals without regard for an arbitrary team. We can provide the infrastructure for those individuals to collaborate on a just-in-time ad hoc basis company wide.
The BA doesn't really give a damn who is on what team—she works with designers, scrum masters, other BAs, product owners, legal, and even upper management. She connects it all together and makes the flow flow. She simply gets shit done.
Thus the true and only reason for teams is control by management. Just admit it.
It's the synergy, stupid
Current and Future Reality Trees, systems thinking, BA as "infrastructure"—these are all just ways to work holistically. The BA is the supreme generalist-polymath-intelligencer-roadway that makes the whole thing work.
Not to say that you can't make it work without a BA, but then only if those duties have been distributed to others in the workforce. Better to collect them in one or more nodes (central locations)—the BAs—so they are more visible, comprehensible, tweakable.
And if we do away with pointless "teams", then we also do away with the stupid limitation of each BA to a specific team and we can set them loose to focus on specific outcomes without regard for arbitrary boundaries. This is what they do best.
I had a conversation a few years back with a very bright CEO who was reorganizing his business around "self-organizing teams". It was interesting and pretty revolutionary, but, I suspect, bound to fail because the point of a team is to be surveilled and controlled by a manager, not to be self-organizing or self-managing.
If you're going to be self-organizing, then why do you need teams at all? Let people self-organize on an ad hoc basis, with members of the ad hoc group coming and going as their talents are needed.
And use smart, capable BAs to provide the "infrastructure" that makes the whole thing flow smoothly. They keep that Reynolds number low.