We just got hired as a jazz band, which is great. But there’s this one guy who insists on playing drums and only plays marching music. It’s the way he’s always played music and it’s all he knows. He is absolutely willing to play in the jazz band but will only play a marching beat. That’s okay, right?
I had a long talk with a new team last week. They’re doing a hybrid agile/waterfall approach on a project that needs tons of changes to reach viable status. My old pal Paul got in touch to ask me about some “intricate” issues.
We were stuck.
There we were, a few iterations into new product development, and there was still no deliverable.
This thing here, from veteran management guy Steve Denning–it’s Forbes, so of course there has to be an infographic that makes less sense than just explaining things.
All mockery aside, I’m seeing an important point here. The lowest-functioning corporations depend on coercion, threats, and “fiat” to get stuff done. If you’re a little more sophisticated and higher functioning, you evolve into “management tools” that aren’t so dependent on brute force to work: measurement systems, strategic planning, that sort of thing. That’s a lot better in many ways, because people respond better and feel better when they’re not being ordered around.
If you’re in that upper realm of “leadership tools,” using persuasion and role modeling to show your people the corporate goals and how to achieve them… that’s a fantastic step forward. But it only works if you discard those lower-level techniques that rely on intimidation.
Inspire all you want! But if the person at the bottom of the stack, doing the real work on the assembly line, at the customer service desk, or in a programming cubicle, is routinely coerced or punished–you have a bigger problem than can be solved with one or two workshops or planning meetings at management level.
I like this chart and plan to use it!
Read the full article though. Denning has some great insights on why Agile software development fails in organizations that don’t adapt on a larger scale. You have to cut out hierarchy and privilege, and if you’re not emotionally ready to let go of those things you are better off not pretending your development shop is “Agile.”
I’ve been doing software development professionally for the last 25 years, almost exclusively in the Cleveland-Akron area, mostly with medium-size to large companies, and over the past ten years mostly with .NET Microsoft shops. About two thirds of them are proud to proclaim they’re “Agile.”
All told, I’ve seen how about eighty different organizations approach development. Narrowing down a bit, I’d say I’ve done relatively long-term projects with about a dozen reasonably large companies with “Agile” shops (generally all Scrum-based) in the past ten years.
And you know what?
I don’t trust any of them. Neither should you.
This is another item in my ongoing series of “How to Mess Up Scrum.” This time, I turn your attention to…
Overcomplicating the Objective
Let me give you an example. A few years ago, I was on a Scrum team that was assigned to develop a “retail portal” for the services this company already sold at old-fashioned store locations. In “phase one” the goal was to put up half a dozen or so static pages, plus one “contact” page to capture basic information so our sales rep can call you soon. That’s all.
It took three developers six months.
How the hell does that happen?
Fake reporting is endemic in dysfunctional Scrum shops. Here are some examples:
- “My meeting ran late so I burned an hour off the memory pooling story.”
- “The boss didn’t want to sign off on DevOps integration. I just rolled it into the story about dropdowns on the UI because it has too many hours anyway and called it “refactoring.”
- Using “defect bucket” as a recurring Sprint Backlog story. Seriously!
- You can’t submit your time sheet to get paid without assigning all your time to an assigned task.
“I haven’t had a real job since 1996.”
That’s what I keep telling people, and that’s largely true. If by having a real job you mean a salary, a long-term connection to a single employer, and company-paid benefits, then no, I haven’t had a real job in that long.
Honestly though, a lot of what I’ve been doing at work in those 18 years has been largely indistinguishable from having a real job.
Much of the time it’s easier and more profitable for me to work with those third-party contracting firms. They take care of a tremendous amount of the work that goes into getting work, and the good ones take a fairly reasonable cut off the top. (Typically it’s 25%, which sounds like a lot but have you seen how much staffing firms in other industries take?) What’s nice about this for me is that these firms have existing staffing contracts, functioning accounts receivable and payable, and a steady flow of open work requisitions. Most of the time, when I’m nearly done with a major project at one client, the same contracting firm goes through its existing client list, finds an open requisition that matches my skills, sets up an interview with the hiring manager, and has me checking in on the very next work day.
When all I care about is remaining “billable,” this is a good system. There are a few downsides though.
Requisitions are pigeonholes.
They are looking for programmers, QA people, project managers, and system administrators. They are looking for these people in either .NET or Open Source flavors. Add one category for network administrators, who seem to be allocated on a platform-neutral basis. (I don’t really know; it’s not my area.) That makes four times two plus one equals nine actual jobs that exist in the world of third-party corporate contracting. There are no coaches, no problem solvers, no interdisciplinary people, no jacks-of-trades. If your background makes you really good at seeing why their waterfall is blocking or at picking out why QA keeps having to look at the same defects over and over again, that job description doesn’t exist to them. So you have to decide which one of those nine things is you, and go with that, even if it’s an oversimplification of what you’re capable of.
Contract-to-hire is a scam.
Another downside, to some of us, is that creepy, weird “contract-to-hire” status. A lot of companies bring on technical people, on a contract basis, with something like a “right to hire” clause in the contract. I’m not clear on what this means exactly, because I don’t even consider those things, but it sounds like they’re asking you to accept a job they haven’t even offered yet. That sounds like a terrible deal. I’m supposed to sign a contract that locks me into a salaried (implied somewhat permanent) job when I’m not clear on what the job is, what it pays, and what the benefits are? What the hell is that about?
I don’t do “contract-to-hire.” It’s designed to put the worker at a disadvantage. Why would I want that?
Yet another downside came up for me a while back, when I was about halfway through a six-month contract gig doing .NET development. It was going pretty well. I felt like I could have caught on faster to how the client’s ancient version control system worked, and it was clear that they were having some trouble allocating people to their three or four Scrum teams, but I did get to help a lot with a new product launch. My handler at the contracting company called me now and then just to say he was hearing good things about my work.
At one point though, I emailed my team manager (who supervises maybe about two dozen people) to let him know I would have to take an unknown amount of unpaid time off, specifically saying “my partner Jamie”–I used those words–was having gall bladder problems and there would be some hospital time. That week I missed a day and a half. My handler called the following Monday to ask why my timesheet read 28 hours rather than 40, and I told him. You would think that would be good enough, right?
That week I also billed 28 hours with another day and a half off of hospital time. It did turn out to be more than your typical gall bladder issue. Keep in mind that I was always keeping the team manager updated.
This place does three-week Scrum sprints, so missing three whole days is somewhat significant, and I had to scramble a great deal to come fairly close to fulfilling my share of the sprint. (That’s another issue: Scrum is a team commitment. We’re supposed to compensate when someone falters. That’s the idea.) Those three weeks were ugly. My personal burn-down chart looked like a jagged sine wave. But it did hit bottom in the end.
Speaking of hitting bottom,
after that, it wasn’t remotely the same. Even though my role going in was clearly to stick with .NET middleware development because I’m not good at front ends and browser scripting, I got handed a lot of browser scripting defects. (Again: not so great Scrum, right?) Planning meetings for the next big project were carried out in my absence. Standup meetings even got a little hostile. One of my handlers called to criticize me for having a personal life, with some reference to not deserving unpaid time off. It was weird.
What Jamie said after all this:
“Next time, just say it’s your wife.”
All I can figure…
…is that in this shop, they feel that a person who’s willing to work on a contract basis should be so grateful for the opportunity that we should drop absolutely everything else, including family and loved ones, for the opportunity to be micromanaged and disrespected. And pretend to be straight while we’re at it.
I chose to finish the six-month engagement quietly before taking a nice vacation. And if that particular staffing company ever wants that 25% of my billing rate again, we’re going to have a rather direct conversation about who gets to have an opinion about their sense of entitlement to my personal life.
So I don’t do that.
Here’s how it goes. I do a lot of straight-up freelance work–custom application development, coaching, training, and team leadership–directly for all kinds of businesses and organizations. Doing my own marketing and business development is actually a huge amount of work, and it gives me all kinds of respect for the people who do that all the time, but it’s still my job so it doesn’t feel like a distraction.
In fact, what I learned from gurus like “Original Mark” Silver and Robert Middleton is that marketing is inseparable from products and services. Part of delivering great work is letting people know it’s available. Part of publicizing what you do is the act of doing it. It’s actually not realistic to say “I only write code, I don’t do sales and marketing.” You’re doing it whether you know it or not. Whether you like it or not.
Thanks but no thanks
So when the rent-a-geek firms call, and they will, I think I’ll start referring them back to this blog post and thank them for their interest. I like having tons of billable hours handed to me, but at this point the attached strings aren’t worth it.
A while ago I posted about Baqbeat, an enterprise systems management tool being developed by my college homie Dave. A lot of things have changed since then.
For one thing, the name has been updated to the less quirky but more descriptive “Congruence.” For another thing, the code is actually getting done. And, as we were discussing the other day, the minimum usable product concept has been pretty well refined.
Why this thing even matters
In a recent Facebook chat, Dave put it this way:
That is my real, underlying motivation… cutting back on the bickering and finger-pointing! It starts with replacing “But we didn’t change anything!” with “What changed when?” and getting a computed rather than human answer.
Then I ran into John, who runs a pretty substantial outsourced data center, at my favorite coffee joint in Lakewood and talked his ear off for an hour and a half. The thing he picked up on was the distinction between change control, which everyone wants to do but nobody has figured out, and change observation, which is actually feasible. I think it was John who said that trying impose a global solution to maintain all the database structures, configuration files, source code releases, and other knicknacks in your big corporate setting is “boiling the ocean.” He’s right. Strategically, you can try to control everything–which becomes a huge top-down endeavor that depends on someone making a big decision and making scores of underlings follow through–or you can take the gentler approach of watching what does change, and correlating it when something goes wrong.
I could go on for a while about the Congruence architecture that supports all this monitoring and correlation, but the cool part for me is that it has Agents and Minions and Dave doesn’t know very much about .NET. So in a couple months you may see me coding a base Congruence Agent for .NET.
For another perspective, Dave summarized his “aha! moment” on this point about observation.
What you can (and should) do now
If you have anything to do with changing or managing stuff in a network that has more than about three computers, go to the pretty placeholder site for Congruence right now and get yourself on the email notification list.
Start thinking about things in your network that change and break stuff. Think about how much it will help to have something that just lets you know what changed.
Get ready for a fall pre-beta thing.