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."”
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.
When you don’t prioritize the Product Backlog, you’re forcing everyone to think about all the backlog items at once rather than allowing them the blessed luxury of thinking about only the most important items right now.
In prior installments, I described a couple of ways to mess up Scrum: Adding work during a sprint and scheduling work for future sprints. This time, I direct your attention to another closely related way to mess up Scrum:
Failure to Prioritize
You know what? Humans aren’t that smart. We can think a lot about a given thing, but we’re not good at thinking about everything at once. Agile development recognizes that by letting us do just one, or perhaps two, things at a time and put aside the things that aren’t immediate. “Do today’s work today!” we say. “Do the simplest thing that could possibly work!” we say.
Those aren’t just cute slogans. They are reminders of how limited we are in our brilliance.
Continue reading “How to Mess Up Scrum, Part 3”
You can try to control everything on your network. Or you can be realistic and position yourself to know what changed when something fails.
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.
I saw this on LinkedIn a few years ago:
The bulk of my professional career has been spent working on software solutions for start-up companies. These projects typically (1) do not have established coding practices, (2) have tight timelines, and (3) have requirements that can change on a day-to-day basis.
With this in mind, I am always interested in learning about more effective approaches to software development. So my question is: “Is agile development yet another buzzword, or is there substance to this approach?”
Here’s how I responded:
Think about Agile as a means to get solid, well-tested software that is designed well, solves problems, and is amenable to change. You don’t need to have every coding standard determined up front–perhaps you’ll want to use an Agile process and mindset just to develop those standards–but your efforts will definitely fail if you think of Agile as a mess of shortcuts.
If it’s slapdash, it ain’t Agile. If it’s a shortcut, it ain’t Agile. Agile probably feels like the long way, actually, because you have to pay more attention as you go along.
Agile usually means less design up front in exchange for continuous design as the project evolves. The exchange part is important: there’s still no free lunch. But it’s not design-design-design-code-code-code. It’s design, code, design, code, design, code. (Or better still, it’s design, test, code, design, test, code…)
Your item #3 in particular (daily requirements changes) could point to managerial dysfunction, which makes Agile really hard; or it could point to a dynamic business model, which makes Agile incredibly useful. Or both. You may well find that a well-executed Agile development process draws attention to poor executive management. (Whoops.)
In answer to your question, though, Agility is definitely real. What’s not real is the idea that you can sprinkle Agile fairy dust on a hierarchical mess and everything is all better.
In fact, about the worst thing you can do is to impose Agile practices (such as daily standups, user stories, and sprints) without working the cultural changes that motivate them. For example, I’ve seen the daily standup used as a manager’s checkin and problem-solving session. That’s not a bad thing to do, but it’s not Agile because it makes one person the bottleneck, and it almost always becomes a scorecard situation rather a collaboration.
Likewise, the essence of the sprint (in Scrum) is that you use each one’s retrospective to inform the plans for the next one. The idea is to get rapid feedback from everyone and actually adjust to it. Which explained why I laffed out loud when overhearing a neighboring team’s project manager crow that “We’re really Agile! We have all our sprints planned for the next two years!” Sure, she got her Gantt chart filled out, but she precluded all meaningful input from the team.
Long story short: it’s real. But the key is to forget about the Agile practices and “tricks” you want to learn. Stop, pay attention to what your team is (overtly or covertly) asking for, and go about changing things in response to how your team really works. There are no buzzwords or shortcuts to it. You have to be willing to listen, to give up power, and in many cases to find out you are totally wrong.
If you’re up to that? Then it’s not a buzzword. But that’s up to you.
Tech journalism? You still need to do some research, or at least bring some personal stories to the table.
My attention was drawn this morning to an article on “10 Technology Skills That Will No Longer Help You Get A Job.” I’m not so impressed, mainly because I spend a lot of time around people who do research. This… isn’t research.
#3, “Software Support,” has no support.
The evidence for #4, “SEO Specialist,” is that Google renamed its Search Group. Nomenclature has power! That’s why my retirement account is named “Piña Coladas on the Beach With Jodie Foster.” (I am not making this up.) It should work, right?
#5, “QA Specialists and Managers,” seriously? “These days, the tech industry seems to be following Google’s lead and turning everyone into beta testers.” Hey, just because it is being done doesn’t mean it really can be done. This is a trend that won’t work out. (As some of the commenters pointed out, how’s that going for military and medical applications?)
I could go on, but the main thing I’m seeing in this article is a host of extrapolations, half-baked wishes, and flip assumptions. I do that all the time, too, but I save it for when I’m bored on long driving trips with anarchists. Heck, even my speculative blog posts here are full of anecdotes, not wild guesses.
Honestly, I’m just not seeing the value-add in that article. Maybe it would have been a good “link collection roundup” kind of post. Nothing wrong with that.
Marketing is part of the actual product. The actual product is part of the marketing. You can’t separate them!
Baqbeat is a little hard to describe. Dave filled me in:
Baqbeat generates timelines of configuration changes to all the servers in
your development and operations environments – version control, build
servers, app servers, databases, and others. It automatically infers
related events on different timelines. So for example, you can see problems
in your production environment and immediately trace it to the code change
that broke it.
Well! I just spent a lot of time with various tech-related startup companies. Some of them have Projects That Suck; others are simply getting started with new things. I’ve learned a lot more about what does and doesn’t work, and I’m ready to share the results with you.
Do you have a startup that’s not yet all the way started up? Not quite done with the software tech product that defines you? Not sure how to finish it, or where to go next? Still stuck for a platform? Worried about funding? Afraid of making expensive mistakes?
If this sounds like you, watch here next Wednesday for the plan and the details. We can work together to get your startup project on track, within budget, and under control. I’m really excited about this. I think you will be too.
Why do we have standards that assume people are trying to get away with doing less work, crappy work, and that they prefer to be selfish about it? These work rules are brute-force solutions to a problem that doesn’t really exist.
One blog entry from last year, “Look. This SOPA/PIPA Thing,” started out as an offhand blurb on my Facebook status. I think I spent two whole minutes writing it, which can be pretty effective when you know exactly what you want to say:
Rather than doing their own damn work chasing down copyright violators, they want to keep everyone off sites that *might* be used for unauthorized copying.
My favorite comment came from my old Grinnell College homie, Laura Allender Ferguson, who said simply: “Go Agile.” She was responding to my side-whine about the ever-changing requirements that we always get from software development clients.