Thursday, April 16, 2015
One of the classic ideas in Western civilization is that the Roman Empire fell to savage tribes of Goths in what is now Germany. The problem with this idea is that the Empire bifurcated about 100 years prior to that, in a process quite similar to the process Goethe identified in plants. The Western half of the Empire remained headquartered in Rome, the Empire's origin, and retained the original name as well. But the other half had its headquarters in Byzantium (aka Istanbul, aka Constantinople), and began to be called the Byzantine Empire. Although the Roman Empire's Western half collapsed only about a hundred years later, the Eastern half persisted for an additional thousand years, until sometime between 1450 and 1480 (depending who you ask).
Even that longevity looks paltry compared to my preferred interpretation, however. Assume for the sake of argument that empires exist primarily to establish hereditary advantages for the members of particular classes of people. Or, alternatively, that there is, at the core of any empire, a system which exists primarily to establish hereditary advantages for the members of that empire's aristocracy.
Depending on which variant you prefer, you could say that the aristocracy-favoring system within the Roman Empire abandoned the Empire and took over the Roman Catholic Church instead, or that the Roman Empire abandoned many of its governmental aspects and became the Roman Catholic Church. Keep in mind that popes commanded armies and exerted governmental authority in and around Rome for well over a thousand years, all the way up to 1870. Even today, the Church may be the third-biggest landowner in the world, although its vast wealth is difficult to calculate from the outside. And I had a Latin teacher in high school who met a Catholic priest from Poland and had a conversation with him in Latin, even though my teacher spoke no Polish and the priest spoke no English.
Consider also the British Empire. The best estimate for the official fall of the British Empire would be 1997, when control of Hong Kong reverted to mainland China. Likewise, although Britain lost its American colonies as early as the 1700s, colonies like India, Pakistan, Palestine (now Israel), and many others remained under British control until the middle of the 20th century. Although Canada became semi-independent in 1867, and Australia in 1901, Canada didn't officially finalize its separation until 1982, and Australia did it in 1986.
Here in the States, we tend to underestimate the British Empire's lifespan, because we got out of it much earlier than average. But again, there's an alternative interpretation which attributes even greater longevity to that empire as well. As with Rome and Byzantium, the Empire bifurcated, and its older half shriveled to a non-imperial status, while its newer half - the United States - continued to thrive as an imperial power right up to today.
The exact degree to which American foreign policy is imperialistic or democratic is wildly contested, yet its near-total domination of global politics is pretty hard to dispute. And again, just as the Roman Catholic Church kept some core elements of the Roman Empire intact, while allowing many others to atrophy, the US is quasi-imperialistic where the British Empire was unequivocally imperialistic. Both subsequent pseudo-empires have kept the original empire's language alive, as well as continuing to privilege the respective aristocracies involved, while dropping many of the core governmental and militaristic aspects of a true empire.
I can't prove this, but I believe that if you follow the money in either case, you'll find continuity. In the Roman example, my guess is families and companies which began in Rome were able to persist either through the Byzantine Empire or the Roman Catholic Church. In the British example, my guess is families and companies which began in England or Scotland were able to persist through the American continuation of British law, or through international corporations (which were originally invented by the British for explicitly imperialist purposes).
Whether this represents genuine imperial persistence or a vaguer kind of imperial drift is an interesting question, but not one I'm qualified to answer. It could be that empires are caterpillars, and their butterfly forms are more loosely organized and less explicitly governmental. But the continuity's easy to spot in either case, and I definitely think the commonality here is real.
Since pretty much everyone who reads my blog is a programmer, I'll bring this around to tech.
In the 1990s, I and many others assumed that Microsoft would die out because of the Internet. I'm sure a big crowd, twenty years before that, thought Microsoft would kill off IBM forever, too. Both these companies have been considered "empires" in their day, though never in a purely literal interpretation, of course. Each of these companies currently survives in a form which is very different from the form they held during their respective imperial glory years.
It's possible that this is always how it's going to be, and that Google will still be with us, in some radically mutated form, two hundred years from now. Likewise, if you're a tabletop gaming nerd, I used to think the Roman themes in Warhammer 40K were ridiculous, but those mecha legionnaires look more realistic to me these days.
Tuesday, April 14, 2015
Monday, March 30, 2015
Sometimes an industry which is very tightly regulated, or which has a lot of middlemen, has these obstructions for a reason.
Working for any taxi service holds enormous opportunities for kidnappers or rapists, and makes you an easy target for armed robbery. In some cities, being a cab driver is very dangerous. In other cities, it's dangerous to take a cab anywhere - don't try it in Argentina - and in many cities it's dangerous for both the driver and the passenger. A taxi service with built-in surveillance could be even worse in the hands of a total maniac. And just to state the obvious, both Uber drivers and regular taxi drivers have logical incentives for driving unsafely.
In this context, I have no problem with governments wanting to regulate Uber literally to death, at least outside of California. California is a special case, in my opinion. Cabs are completely unacceptable garbage throughout California, and the startup scene definitely skews Californian, so the typical startup hacker probably thinks all cabs suck, but cabs are gold in London, Chicago, and New York, and probably quite a few other places too.
In Los Angeles, cabs are licensed by city. A cab driver can only operate in one "city," and can face disastrous legal consequences if they pick up a passenger outside of their "city." But the term's misleading, because the "city" of Los Angeles is really a massive archipelago of small, loosely affiliated towns. It's extremely common that a taxi cab will be unable to pick up any passengers once it drops somebody off. I lived in San Francisco before I lived in Los Angeles, and I had always assumed Bay Area taxis were the worst in the industrialized world, but Los Angeles cabs make San Francisco cabs look competent.
(In the same way that San Francisco's MUNI system makes LA's Metro look incredible, even though both suck balls compared to the systems in New York, London, and Chicago. I'm told the system in Hong Kong puts even London's to shame.)
By contrast, in London, you have to pass an incredibly demanding driving and navigation test before you can become a cab driver. Researchers have demonstrated that passing this test causes a substantial transformation in the size of the cab driver's brain, in the regions responsible for maps and navigation.
Disrupting something which works great (i.e., cabs in London) is not as impressive as disrupting something which sucks ass (i.e., cabs in California). I think the tech industry overrates Uber, because the industry's headquartered in a state which probably has the worst taxicabs of any first-world country.
Uber is obviously a disruptive startup, but disruption doesn't always fix things. The Internet crippled the music industry, but introduced stacks of new middlemen in the process. Ask Zoe Keating how that "democratization" turned out.
In music, the corporate middlemen are this pernicious infestation, which just reappears after you thought you'd wiped it out. Artists have to sacrifice a lot to develop their art to a serious level, and a lot of music performance takes place in situations where people are celebrating (i.e., drunk or high, late at night). So somebody has to provide security, as well as business sense. There's a lot of opportunities for middlemen to get their middle on, and disrupting a market, under those conditions, just means shuffling in a new deck of middlemen. It doesn't change the game.
In the same way that the music industry is a magnet for middlemen, the taxi industry is a magnet for crime. A lot of people champion Uber because it bypasses complex regulations, but my guess is that disrupting a market like that means you just reshuffle the deck of regulations. If Uber kills the entire taxi industry, then governments will have to scrap their taxi regulations and re-build a similarly gigantic regulatory infrastructure around Uber instead. You still have to guard against kidnapping, rape, armed robbery, unfair labor practices, and unsafe driving. None of those risks have actually changed at all. Plus, this new regulatory infrastructure will have to deal with the new surveillance risks that come along with Uber's databases, mobile apps, and geotracking.
Uber's best-case scenario is that the society at large will pay for the consequences of their meager "innovation." But if you look at that cost realistically, Uber is not introducing a tremendous amount of new efficiency to the taxi market at all. They're just restructuring an industry so that it offloads, to taxpayers, the costs and complexities of a massive, industry-wide technology update.
Uber got rid of inefficient dispatch mechanisms, and routed around licensing laws, but odds are pretty good (in my opinion) that those licensing laws will re-assert themselves. Those laws don't exist to preserve an inefficient dispatch mechanism, which is the only real technological change here. They exist mostly to guard against risks of criminal behavior. Those risks are still present. Like it or not, licensing laws are a very common response to risks of that nature in societies like ours.
It's possible that those licensing laws might be gone forever, but I wouldn't bet on it. I think it's a lot more likely that Uber has a huge IPO and its stock price withers to nothing a few years later, once the slow-moving systems which generate regulation in democratic societies have had time to react. If all you're doing is building to flip, sure, you can take the money and run, but if you want an actual business that lasts, Uber might not deliver.
I could totally be wrong. Only time will tell for sure. But I think Uber is a really good lesson for entrepreneurs in how a market can look awesome but actually suck. From a long-term perspective, I don't see how they can hope for any better end-game than bribing corrupt politicians. While that is certainly a time-honored means of getting ahead, and it very frequently succeeds, it's not exactly a technological innovation.
Monday, March 23, 2015
My main critique: Scrum's full of practices which very readily and rapidly decay into dysfunctional variants, making it the software development process equivalent of a house which falls apart while people are inside it.
Most Scrum advocates have not addressed this critique, but among those who have, the theme has been to recite a catchphrase: "Inspect And Adapt." The idea is it's incumbent upon any Scrum team to keep an eye out for Scrum decay, and prevent it.
Scrum can be described as a framework of feedback loops, allowing the team to constantly inspect and adapt so the product delivers maximum value.
From an Agile glossary site:
“Inspect and Adapt” is a slogan used by the Scrum community to capture the idea of discovering, over the course of a project, emergent software requirements and ways to improve the overall performance of the team. It neatly captures the both the concept of empirical knowledge acquisition and feedback-loop-driven learning.
My biggest critic in this Internet brouhaha has been Ron Jeffries. Here's a sampling of his retorts:
Mr. Jeffries is a Certified Scrum Trainer and teaches Certified Scrum Developer courses.
In a blog post, Mr. Jeffries acknowledged that I was right to criticize the Scrum term "velocity." He then added:
For my part in [promoting the term "velocity," and its use as a metric], I apologize. Meanwhile you’ll need to deal with the topic as best you can, because it’s not going away.
He reiterates this elsewhere:
Mr Bowkett objects to some of the words. As I said before, yes, well, so do I. This is another ship that has sailed.
The theme here is not "Inspect And Adapt." The theme is "you're right, but we're not going to do anything about it."
This isn't just Mr. Jeffries being bad at handling disagreement. It's also the case with Scrum generally. I'm not the first or only person to say that sprints should be called iterations, or that "backlog" is a senselessly negative name for a to-do list, or that measuring velocity nearly always goes wrong. Scrum also has a concept of iteration estimates which it calls "sprint commitments" for some insane reason, and this terrible naming leads to frequent misunderstandings and misimplementations.
These are really my lightest and most obvious criticisms of Scrum, but the important thing here is that people who love Scrum have been seeing these problems themselves over the twenty years of Scrum's existence, and nobody has fixed these problems yet. In each case, all they had to do was change a name. That's a whole lot of inspecting and adapting which has not happened. The lowest-hanging fruit that I can identify has never been picked.
Monday, March 16, 2015
Thursday, March 12, 2015
Here's another one:
Here's a more electro-house-ish set Mistabishi recorded live at an illegal rave in London last year:
You can actually download all the patterns and patches in this from the Korg web site.
Korg also had Mistabishi demo the new Electribe – basically the next generation of the EMX – in a couple YouTube videos:
(In this one, he enters the video at around 6:45.)
The new Electribe seems pretty cool, but these videos motivated me to buy an EMX instead. The new one's untested, while the EMX is a certified classic, with a rabid fan base, tons of free downloadable sounds, tons of videos on YouTube showing you how to do stuff, forum posts all over the Internet, and rave reviews (no pun intended).
Also, the new version literally has a grey-on-grey color scheme, while the EMX looks like this:
They run about $350 on eBay, but if you find an auction ending 8am on a Sunday, you might pick one up for just $270 (I did).
It also helps that I'm a huge fan of the original Electribe, the Korg ER-1, one of the most creative drum machines ever made. I've owned two (or three, if you count the iElectribe app for iOS, based on the second iteration of the ER-1).
Wednesday, March 4, 2015
Dear Agile, Your Gurus Suck
Like any engineer, I've had some unproductive conversations on the internet, but I caught a grand prize winner the other day, when Agile Manifesto co-signer Ron Jeffries discovered Why Scrum Should Basically Just Die In A Fire, a blog post I wrote months ago.
possibly most wrong article about scrum ever written. no comments allowed. :( http://t.co/em5vorGlnT&mdassh; Ron Jeffries (@RonJeffries) February 18, 2015
I tried to have a civil conversation with him, but failed. It was such an uphill climb, you could consider it a 90° angle.
I answered Mr. Jeffries's points, but he ignored these remarks, and instead reiterated his flawed criticisms, at length, on his own blog.
If you're the type who skips drama, I'm sorry, but you want a different post. I wrote that post, and published it on my company's blog. I got some better criticism of my anti-Scrum blog posts, and I responded to it there. I also heard from Agile luminaries like Mr. Jeffries, but unfortunately, none of the insightful criticism came from them.
Because of Mr. Jeffries's high profile, I have to respond to his "rebuttal." But he failed at reading my post, and again at reading my tweets, so my rebuttal is mostly going to be a Cliff's Notes summary of previous remarks.
But let's get it over with.
It's Not Just Me
RSpec core team member Pat Maddox said this after seeing the Twitter argument:
@gilesgoatboy same dude who said "I want to learn RSpec" at agile conf, Ward recommended pairing w/ me, dude said "I'll find someone else"— Pat Maddox (@patmaddox) February 19, 2015
@gilesgoatboy of course, he couldn't have known that I was on RSpec core at the time. But I think a Ward recommendation ought to be solid...— Pat Maddox (@patmaddox) February 19, 2015
"Ward" is Ward Cunningham – another Agile Manifesto co-signer, the inventor of the wiki, and one of the creators of Extreme Programming. I'm not a huge fan of methodologies, but in my opinion, Extreme Programming beats Scrum. Even if you disagree, for people in Agile, yes, a Ward Cunningham recommendation ought to be solid, every time.
Here's an anonymous email I got from somebody else who witnessed the flame war:
We had a local “Scrum Masters” meet up here in [my home town] maybe 5 years ago. At the time my wife was trying to figure out a career transition for herself and a friend recommended becoming a Scrum Master. I’d been doing Scrum for a couple of years and I was friends with the organizers so I sent her over to that meet up. She came back and told me it was an epic fail and Ron Jeffries was the most unprofessional, rude speaker that she’d ever seen. In hindsight, it was probably a good thing that it turned her off Scrum completely.To his credit, Mr. Jeffries starts out his blog post by acknowledging that he could have been more polite with me:
Ron Jeffries was rude to most of the people asking questions about how to implement Scrum. One person in particular mentioned having an offshore team and some of the challenges involved in making Scrum work with a geographically distributed development team.
Ron Jeffries’ response was “Fire all the folks not in your office. If you’re trying to work with people offshore, you’ve already failed. Next question."
Even if this was 2010 and the prevailing thought in our industry was that offshoring and remote work didn’t work, his response was just tactless. He had similar short, rude responses to nearly every question that night and it resonated negatively with everyone there. I don’t think they ever asked him back there again.
My first reaction was not the best. I should have compassionately embraced Giles’s pain... But hey, I’m a computer programmer, not a shrink.This "apology" implies my expectation of basic common courtesy is equivalent to mental illness.
Mr. Jeffries then stumbles through several failures at basic reading comprehension.
Basic Context Fail
We'll start simple. In my post, I wrote:
I've twice seen the "15-minute standup" devolve into half-hour or hour-long meetings where everybody stands, except for management.I then gave examples.
At one company...Mr. Jeffries used the singular every single time he described my teams, my projects, or the companies I worked for:
At another company...
Things were not going well in planning poker and Giles’s team did not fix it...So he didn't even get that when I said I was talking about two companies, I was talking about two companies.
Giles’s team’s Product Owner...
Why didn’t the time boxes do that for Giles’s team?
...I’m sad that Giles suffered through this, and doubtless everyone else on the project suffered as well...
And I’m glad Giles remarks that Scrum does not intend what happened on his team. It does make me wonder why this article wasn’t entitled “Company XYZ and Every One of its Managers Should Just Die in a Fire.”
Advanced Context Fail
In fairness, you only had to miss the point of four or five paragraphs in a row to miss that detail, and my post contained many paragraphs. However, the point of those paragraphs was that you see Scrum practices decay at multiple companies because Scrum practices are vulnerable to decay. They have a half-life, and it is brief.
Mr. Jeffries missed this point. He also failed to recognize hyperbole which I'd thought was glaringly obvious. I said in my post:
In fairness to everybody who's tried [planning poker] and seen it fail, how could it not devolve? A nontechnical participant has, at any point, the option to pull out an egg timer and tell technical participants "thirty seconds or shut the fuck up." This is not a process designed to facilitate technical conversation; it's so clearly designed to limit such conversation that it almost seems to assume that any technical conversation is inherently dysfunctional.These egg timers really exist. I added "shut the fuck up" to highlight the ridiculousness of waving an egg timer at somebody in order to make a serious business decision. Somehow, however, what Mr. Jeffries took away from those words was that I actually, in real life, attended a planning poker session where somebody told somebody else to shut the fuck up.
It's ironic to see conversation-limiting devices built into Agile development methodologies, when one of the core principles of the Agile Manifesto is the idea that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation," but I'll get to that a little later on.
For now, I want to point out that Planning Poker isn't the only aspect of Scrum which, in my experience, seems to consistently devolve into something less useful.
Quoting from his post:
What’s going on here, and why is planning poker being blamed for the fact that Giles seems to be surrounded by assholes?I don't even get how Mr. Jeffries took that literally in the first place.
...People do cut their fingers off with the band saw, and I guess people do get told to shut the fuck up in a planning poker session.
Should not happen. Should never happen...
No one in Scrum wants abusive behavior...
Things were not going well in planning poker and Giles’s team did not fix it. That makes me sad, very sad, but it doesn’t make me want to blame Scrum. Frankly even if Scrum did say “Sometimes in planning meetings tell people to shut the fuck up”, that would be so obviously wrong that you’d be a fool to do it...
someone with a pair could take an individual aside and tell them not to be a jerk.
But I'll rephrase my point: building conversation-limiting rules into planning poker contravenes the basic Agile principle that face-to-face conversation is important. Additionally, these conversation-limiting rules provide an easy avenue through which the Scrum process can devolve into something less Agile – and also less productive – and I believe Scrum has several more design flaws like that.
Since Mr. Jeffries equated asking for basic courtesy with asking for free therapy, it's probably no shock that his condescending tone persists even when he acknowledges my points. I pointed out naming errors in Scrum, and he responded:
I’m not sure I’d call those “conceptual” flaws, as Giles does, but they’re not the best possible names. Mary Poppendieck, for example, has long objected to “backlog”. Again, I get that. And I don’t care...This is an adult, intending his words for public consumption. Even when he sees I'm right, he dismisses my critique in favor of his own critique, even though he also acknowledges that his own critique probably doesn't exist.
Giles objects to velocity. I could do a better job of objecting to it, and who knows, somewhere in here maybe I have, but the point is a good one.
Still, this is the apex of maturity in Mr. Jeffries's post, so I'll try to be grateful. We do at least agree "sprint," "backlog," and "velocity" are flawed terms. If a civil conversation ever emerges from this mess, it might stand on that shred of common ground.
But I'm not optimistic, because Mr. Jeffries also says:
For my part in [promoting the term "velocity," and its use as a metric], I apologize. Meanwhile you’ll need to deal with the topic as best you can, because it’s not going away.Apology accepted, and I'll give him credit for owning up to a mistake. But his attitude's terrible. If velocity's not good, you should get rid of it. And I don't need to deal with it, because it absolutely is going away.
Scrum's a fad in software management, and all such fads go away sooner or later. The most embarassing part of this fracas was that, while my older followers took it seriously, my younger followers thought the whole topic was a joke. Velocity is, in my own working life, less "going away" than "already gone for years." My last full-time job with Scrum ended in 2008. Since then, I've had to deal with velocity for a grand total of four or five months, and they weren't all contiguous.
Mr. Jeffries continues:
Giles has gone to an organization that pretty much understands Agile...I'd agree Panda Strike "pretty much understands Agile," but that's why we regard Scrum with skepticism. We also understand several flaws in Agile that I'd guess Mr. Jeffries does not. And it should be obvious I already had "a fun way to be productive" before Scrum got in my way. Why else would I dis Scrum in the first place?
I’m not sure just what they do at his new company, Panda Strike, but I hope he’ll find some good Agile-based ideas there, and I think probably he will. More than that, I hope Giles finds a fun way to be productive...
For the record, at Panda Strike, we do use some Agile ideas, but that's a different blog post.
I'm publishing this on my personal blog, not the Panda Strike blog, because this is my own social media snafu. On the Panda Strike blog, I've gone into more detail about Agile and Scrum, our skepticism, the compromises we'll sometimes make, the flaws we've found in the Agile Manifesto, and the things we still like about it (and, to a lesser extent, Scrum). That blog post is more balanced than my personal attitude on my personal blog.
My post on the Panda blog is a response to the coherent criticism I've received. Please do read it. I hope you enjoy it. But here I'm responding to incoherent criticism from a high-profile source. Sorry - the man has sixteen thousand Twitter followers, and every one of them seems to want to bother me.
Also, a point of order: I am not "Giles" to you, Mr. Jeffries. I am "Mr. Bowkett" or "Mr. Bowkett, sir." Those are your only choices. You don't know me, sir. Mind your manners, please, because I'd like to use my own without feeling put upon. And your repeated claim of being "sad" on my behalf would be creepy if it seemed plausible, but it does not. It reads as insincere, so maybe you could just stop.
My blog post argued that Scrum practices decay rapidly into non-Agile practices. Weirdly, most of my critics have repeatedly stated that my argument was not valid because I provided examples of Scrum practices which had decayed into less Agile versions.
Mr. Jeffries was one such critic. During my Twitter argument with him, I reminded him of this point repeatedly. Here's one of several such reminders:
Even after this exchange, he continued to hammer the idea that my argument – that Scrum's Agile practices decay rapidly – is invalid because the decayed versions of these practices are not Agile.
Mr. Jeffries's Terrible Reading Comprehension May Not Be A Fluke
One of Mr. Jeffries's Twitter followers, a Scrum consultant named Neil Killick, wrote a blog post criticizing my post also:
A controversial blog post... suggests that Scrum is broken for many reasons, but one of those reasons cited is that the 15 minute time box for Daily Scrum (aka Standup) is too short to allow for meaningful conversations, and promotes a STFU culture.This is false.
The phrase "shut the fuck up" occurred in a discussion of planning poker, not daily standups. This concept of "a STFU culture" is Mr. Killick's invention. The time-boxing in standups might undermine the Agile principle that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation" – it's certainly odd to find this "inhibiting conversation" theme in an "Agile" methodology – but a major theme in my post was that standups frequently go too long.
Having failed to grasp this, and possibly without ever reading my blog in the first place, Mr. Killick then explains how to solve a problem I never had:
IMO, in the situation the author describes, Scrum has exposed that perhaps the author and his colleagues feel their time together in the morning is so precious that they resent ending it artificially.So, recap.
As the Scrum Master in this situation I would be trying to find out why they are not able to continue talking after the Daily Scrum? Perhaps they struggle to find the time or will to collaborate during the working day, so being forced together by the Daily Scrum gives them an opportunity that they do not want to cut short?
I write a blog post about how Scrum's a waste of time. I get two blog posts defending Scrum. Neither of the individuals who wrote these posts showed enough respect for my time to read the post they were responding to. Both of them say inaccurate things about my post. Both of them then offer me advice about how to solve problems I never had. And this is their counterargument to my claim that Scrum is a waste of time.
A Quick Defense Of Some Innocent Bystanders
Many Scrum defenders have said things to me like "if your company had a problem with Scrum, it was a messed-up company," or even "if your team had a problem with Scrum, they were incompetent."
On behalf of my former co-workers and former managers, fuck you.
One of the companies I mentioned was indeed very badly mismanaged, yet I worked with terrific people there. There were some flaws at the other, too, but it was much better. There were plenty of good people, nothing really awful going on, and Scrum still decayed.
(In fact, standups decayed to a similar failure state in each case, even though the circumstances, and the paths of deterioration, were very different.)
I saw these problems at two companies with a serious investment in Scrum, and I saw echoes of these problems elsewhere too. It's possible that I just fell into shit company after shit company, and the common theme was pure coincidence. But I doubt it. And if your best argument relies on coincidence, and boils down to "maybe you just suck," then you're not coming from a strong position.
Is that even an argument? Or is it just a silencing tactic?
The first time or two that I saw Scrum techniques fail, my teams were using them informally. I thought, "maybe we should be using the formal, complete version, if we want it to work." The next time I saw Scrum techniques fail, we got official Scrum training, but the company was already being mismanaged, so I thought, "maybe it doesn't matter how full or correct our implementation is, if the people at the top are messing it up." The next time after that, management was better, and the implementation was legit, but we were using a cumbersome piece of software to manage the process. So I thought, "maybe Scrum would work if we weren't using this software."
Eventually, somebody said to me, "hey, maybe Scrum just doesn't work," and it made more sense than any of these prior theories.
And Scrum's answer to this is "maybe you just suck"?
Valid Critiques Addressed Elsewhere
As I said, I got better opposing arguments than these, and I addressed them on the Panda Strike blog. Check it out if you're curious.
Sunday, February 22, 2015
My friend Carlo Flores has died. He lived in Los Angeles, and on Twitter, every hacker in Los Angeles was going nuts with grief a few days ago. None of them would say what happened. I had the terrible suspicion Carlo killed himself, and I eventually found out I was right:
I can't even imagine the pain he must have been in to seek a way out, knowing that it would make all of us miss him this way.
I love you Carlo. I'm going to rock for you today.
Converted some former ashtrays into gardens. Working on getting better. pic.twitter.com/FvfYM1k0oV— see flowers (@lolcatstevens) February 12, 2015
All I want to do is build cool shit that is interesting and respectful.— see flowers (@lolcatstevens) February 16, 2015