I’m working on a few “Internet of Things” (IoT) projects for a fairly big manufacturing company right now. Yadda yadda nondisclosure, that’s all I’m going to say about that. Continue reading Latest buzzword, deconstructed: “Internet of Things.”
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.
Someone asked this recently on LinkedIn:
What are some good ways in which to most quickly transition from a waterfall environment to an agile environment in such a way that (most) everyone gets on board with the transition?
My response went something like this.
By far the most common reason why development teams don’t get “on board” with Agile, in my experience, is that management isn’t on board either.
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.
At one recent gig, I was a bit confused as to why the team manager kept imposing a list of tasks—excuse me, stories—for every sprint. I said, “We’re supposed to meet with the customer, share story sizes, listen to their priorities, and then see what will fit into the sprint, right?” The manager said no, his manager already told him what the “phase one” features and stories were… and furthermore, that we had to finish them all in the next three sprints.
Sprint planning meetings became a formality, because the results were dictated by a person who wasn’t even there to argue with. Sprint demos didn’t even have a customer. And worst of all–here’s where the mistrust comes in–all the individual team members were evaluated based on whether they hit deadlines, er, I mean, on how well their story completion matched those (coerced) predictions.
The key here is accountability. When the team doesn’t own the scope of work, then they can’t own the result. Further, we can’t possibly fulfill customer requirements when we’re not anywhere near the customer.
This is an incredibly common scenario.
Each of those dozen shops has been organized in a similar way. The details are different:
- In one place, the manager simply insisted on adding work during the sprint by creating “bucket” tasks in advance. You can’t own the result of a “to be determined” work item. But it did help the customer fit things in when there was time.
- Another manager required everyone to “burn down” exactly eight hours per day, even if that meant distorting the burn chart by burning on tasks that we hadn’t touched to leave times for the ones we hadn’t finished yet. If we can’t give real feedback during the sprint, we can’t adjust expectations. But it did reassure upper management that we weren’t slacking.
- And in one organization, aborting a failed sprint wasn’t even possible because all the teams shared a Jira site on which sprint durations were set throughout the enterprise. It literally wasn’t possible not to be in lock step, even if (for example) an unexpected production disaster pulled us all off sprint tasks and forced us to start over. If declaring “failure” isn’t an option, we don’t have a way to recover from it. But it does avoid the stigma of reporting that we missed a target.
I think I’ve seen one time a development team that was allowed to self-organize within a sprint. Once since about 2006. It’s not terribly common.
So why don’t I trust development managers?
Because their sense of responsibility is one way. They’re still committed (upward) to hitting imposed deadlines, and that’s what they get evaluated on. So they evaluate us in turn in the same fashion.
Agile isn’t about hitting deadlines. It’s about early and continuous delivery of valuable software! If your shop is deadline driven, and if you’re evaluating developers based on making those deadlines, then Agile artifacts (such as burn charts) and methodologies (such as Scrum) are illusory… and we don’t trust you with them.
Do you want trust and commitment from your team? Then understand that accountability has to work both upward and downward. Most of all, and first, stop evaluating team members by external deadlines and start evaluating based on contributions to the team.
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.