Category: Agile/Scrum

To the Agile Community – WTF is wrong with you?

As you might know from previous posts, the Cranky Product Manager is pretty neutral on Agile / Scrum.

Yes, Agile is trendy.  Everyone is doing it.  Some consultancies out there have tied their entire brand to the Agile concept (digression – how smart is this when the inevitable backlash against something so over-hyped will inevitably occur?).

And don’t get the Cranky PM wrong, Agile/Scrum can help greatly with many types of product development problems.  It’s good. It can be fun. But Agile/Scrum is not perfect.  It has its problems too.  Some of which have been elucidated more eloquently by others.

Well, the Cranky Product Manager is going out on a limb and declaring that:

The BIGGEST problem with Agile/Scrum is its crazy, insulting, demeaning, and threatening lunatic fringe.

Yep, these zealots — and YES, they are TRUE frakin’ Drink-the-Kool-Aid, Jihadist ZEALOTS — believe that Agile is The One True Way to build a product.  And that if you do anything else, well, you’re a frakin’ moron who must be silenced.  You “just don’t get it,” “you must be doing it wrong”, etc.

And if a non-believer DARES publish something with less than ridiculous adoration for the Agile concept, well they get freakin’ flogged in a over-reacting, vitriolic, personalized fashion.

At best, the non-believer gets publicly berated as stupid/really naive by the principal of a product management consultancy.

At worst, the non-believer gets called a c-word who should “shut the f#$# up” and “watch out,” topped off with a “I’ll get YOU into some very Agile positions, you effing  b@#$%,” for good measure.


Yep. Each of the Cranky Product Manager’s three posts on Agile/Scrum received an amazing amount of hyper-nasty emails and comments, some of which were downright threatening.  The Cranky Product Manager has learned to scan and promptly dump these abusive comments and emails directly into the garbage before she has time to properly comprehend them.  Because otherwise, the Cranky Product Manager might become too afraid to leave her house (remember Kathy Sierra, anyone?  Fortunately, the Cranky Product Manager writes anonymously).

The Cranky Product Manager has had this post in draft form for months because she’s afraid of unleashing the wrath of the Agile Jihadists once more.  But eff it.  She won’t be intimidated by those f@#%s any longer.  Seeing the attack on Adam Bullied (even though it was relatively minor) made her want to speak up.

Anyway, the Cranky Product Manager does not know how to wrap this post up, except to call upon the more moderate elements of the Agile community to

  1. Stop getting so defensive with people who don’t think Agile is the second coming, and
  2. Do something about your lunatics.

Please.  And thank you.

Related Posts:

Guest Post: The Cranky Test for Agile Product Managers

Today we have a glorious guest post from Scott Sehlhorst, product management consultant extraordinaire and author of the tasty-good Tyner Blain blog.

Scott may be genetically incapable of true crankiness.  One of his co-workers once accused him of having excess serotonin levels.  And he’s never had a headache.  Nor has his dad or his grandfather. Scott once parachuted in to help out late in an “agile” project.  It inspired the following exam.  After you take the quiz, you’ll understand why the Cranky Product Manager is publishing it.

The Cranky Test for Agile Product Managers

One of the challenges that comes from the growing popularity of agile development is that sometimes the people racing to adopt the methodology out-pace the clue-train of understanding. Some teams say “Agile” without knowing what that really means. Sometimes part of the organization knows how to be agile, and other parts don’t. That can be a source of frustration for everyone. If you’re a product manager, working with an Agile (or “agile”) team, you might just get cranky. Being sensitive and pragmatic and realistic, just how cranky can you justifiably be?

Here’s a quick multiple choice test, for product managers joining an Agile team mid-flight.

Take the test to see just how cranky you can (justifiably) be. Record all your answers without reading ahead.

  1. In the first daily stand-up meeting you attend you heard (pick one):

    1. Each member of the implementation team say what he did yesterday, what he will do today, and what if any roadblocks he faces.
    2. A user-rep / proxy from the business says “I have a couple UATs I’d like to add to that ‘send a gift’ story you’re doing this sprint.
    3. The architect proclaims that all stories must be delivered two weeks prior to each sprint, after which point, the business is not allowed to change them — only development can change them.
  2. You sit down with the key stakeholders to prioritize the target users / market(s) / market segments, and you’re told (pick one):
    1. Here’s the persona representing our most profitable customers, and the one representing the bulk of our customers.
    2. We are focused on mom and pop SMB retailers. We’ll define the other market segments later. Remember:  Mom. And. Pop.
    3. It’s the Internet — for all we know, our customers are dogs. We suspect most of them speak English. At least some.
  3. You reviewed the stories to find (pick one):
    1. Each story is on a yellow post-it on the whiteboard in the war room, with a pink post-it nearby including some ‘verify’ statements.
    2. All the stories that were just estimated for this sprint are sorted into columns based on size in points (and the team uses fibonacci for the values).
    3. All ‘stories’ are managed in a requirements repository, from which MS-Word docs are generated, zipped up, and emailed to the development team, who modify the word documents, and store them in subversion in a directory structure reflecting if they were accepted or rejected (for lack of clarity).
  4. When you asked about testing, you were told (pick one):
    1. We automate our unit tests and incorporate into the daily build process – we won’t promote to the trunk with bugs.
    2. Do you mean testing what we wrote, or testing by users to make sure we wrote the right stuff? We did both.
    3. The person who manually tested was working against a different version of the product than development.
  5. When you asked what the user feedback so far has been like (pick one):
    1. Very positive from a couple people in our target demographic – and we uncovered some great new ideas.
    2. Rough. The stakeholders let us know that they met last week, and completely changed their strategic goals – but we’re adapting now.
    3. Users? Look at the time…
  6. You corner the QA lead for the project to talk about performance testing and (pick one):
    1. She shows you the logs, and how they identify which stories get the most action, and how long they take. Then she circles “the bad one” and shares that it just got prioritized into the current sprint.
    2. She takes you to the break room, and shows you the trend charts on the wall, for average response-times for the top ten stories (in importance to the key persona) – pointing out which times are above “ok” and which ones are below “ok.” Then she starts to ask you about scalability.
    3. She suggests that if you sit down with a stopwatch in front of the test server, next week, after the next build, you can probably measure performance, if the build doesn’t crash all the time like the current build.
  7. You hear a rumor that the cadence of releases is not working very well. When you investigate, you find (pick one):
    1. Weekly releases are too frequent for the users to review, and they are asking that we move to biweekly releases.
    2. Monthly releases are too far apart, and now that the automated build process is done, developers want to move to biweekly releases.
    3. Our first release is two months away. How can anyone be complaining about the frequency of releases? No one has seen it yet.
  8. The management team is completely replaced when a new CEO cleans house. When you meet with the new CEO to review project status, you share (pick one):
    1. The burndown charts and expected “completion” of today’s version of “the project vision.”
    2. The sequence of deployment of tangible, valuable capabilities, combined with the number of users at each release.
    3. A hand-waving explanation of why nothing can be deployed after 6 months, and how “everything” is 80% complete.


  • For every (a) answer, give yourself 0 points.
  • For every (b) answer, give yourself 0 points.
  • For every (c) answer, give yourself 5 points.
  • Give yourself 1 point for every time you’ve been hit with the recent Facebook reincarnation of the 25-things meme.

Add up the points. This will tell you, on a scale from 1 to 40, just how Cranky you can justifiably be.  If you hit 40, make sure you sign up to write a guest post.  The Cranky Product Manager needs your rantings and ravings to be put to good use!

Related Posts

Poll Results: Software Development Methodologies (Agile vs Waterfall)

Big thanks to the 119 of you who deigned to answer to the Cranky Product Manager’s lil’ Facebook poll on software development methodologies. The poll is now closed.

While this is hardly a scientific poll, the results show a HUGE change in software development methodologies between now (2008) and two years ago (2006).

Software Product Development Methdologies: 2008 vs 2006
Software Product Development Methdologies: 2008 vs 2006
  • In 2006, you reported that a sizable majority of product development used a waterfall methodology (55%), with Scrum garnering a mere 7%.
  • In 2008, the picture is very different. Scrum and its Agile cousins account for nearly 60%, where waterfall has dropped to a mere 28%.
  • The percentage of products using waterfall dropped by 50% in just two years! (from 55% in 2006 to 28% in 2008.)
  • Scrum increased by 410% (!), and is now definitely the most popular flavor of Agile.

Wow. What a difference in just two years.,

Poll Conclusions

The CPM sees the writing on the wall. She’s now on a mission to learn all she can about Agile/Scrum in order to stay employable. But geez, there’s got to be something better out there than that canonical (naive) Scrum book. Something that reflects the realities of developing software PRODUCTS for multiple customers, not doing custom one-off developing projects. Please, say there is.

Nonetheless, the CPM thinks we are approaching Agile’s “Peak of Inflated Expectations,” soon to be followed by the “Trough of Disillusionment” (to borrow phraseology from the much-despised Gardeners), as people realize Agile still has flaws and is no Silver Bullet. Plus, Agile’s flaws aside, waterfall is not going away completely as there are too many products that CANNOT be developed via Agile (hardware, medical, defense, heavily regulated industries, products with very spread-out or outsourced development teams, to name a few).

Detailed Results

119 people responded to this Facebook poll, run between September 12 and October 1. Bare in mind that the readers of this blog are hardly representative of the entire software industry, and that the ones that use Facebook might be even less representative. Nonetheless, the results are very telling.

Question 1: Is your product currently being developed with one of the following software methodologies?

Reported Software Product Development Methodologies in 2008

Question 2: Two years ago, what methodology was used for the product from Question 1?

Reported Software Product Development Methodologies in 2006
Reported Software Product Development Methodologies two years ago, in 2006

Heresy Against the Church of Agile Software Development

The Cranky Product Manager is a big fan of anything that will get quality, innovative, market-killing products out the door more quickly.

Sincerely. This statement is a paragon of truthiness. Hell, the Cranky Product Manager would even trade in her extensive work wardrobe of Lucky Brand jeans for a pile of poofy skirts if it would improve product quality. She would even stop swearing and referring to her colleagues as “beeyotches” if it would speed up development and reduce the number of half-finished features. No lie.

But alas, the Cranky Product Manager’s cantankerous, tomboyish lifestyle is hardly threatened, despite DysfunctoSoft’s move to Agile (specifically Scrum) two years ago.  Things are slightly better now, but not that much.

Shocking, the Cranky Product Manager knows.  Because Agile and Scrum are SO FRAKIN’ FASHIONABLE right now, that speaking of them in anything but the MOST obsequious “Agile-is-the-absolute-shizz-it’s-even-better-than-sex” manner, well, it’s kinda heresy.

You see, Agile is a pseudo-religion. It has a Manifesto and a bunch of zealots and everything. (gack)  In fact, the Cranky PM fully expects a pile of comments and trackbacks along the lines of:

  • “The CPM just doesn’t get it. Agile is indeed the shizz. Plus it’s better than sex. It’s new (well, kinda). It’s iterative. All the cool kids (claim) to do it.”
  • “The CPM is a waterfall-worshiping Luddite, afraid of change, out of touch, and a control freak — so typical of a product manager. Doesn’t she realize that Scrum liberates us developer-artistes to at long last build for intelligent audiences, people just like us?”
  • “The CPM must be doing Agile the wrong way. Not me — I know all the secrets. To learn how to do Agile right, visit my blog, read my book, hire my consulting firm, take my training class… With my help, you too can use Scrum to MAKE MONEY FAST, MELT AWAY THE POUNDS without diet or exercise, and become ABSOLUTELY IRRESISTIBLE to the opposite sex. Agile riches will exceed your wildest dreams!!!!!!!!!!”

Hmmmphhh. Such are the stones a heretic must endure.

Anyway, let the Cranky Product Manager continue and speak directly about the unspeakable:

Sure, Agile makes some things (ok, many things) better.  But it also makes some things — IMPORTANT things — worse.

Yes, Agile can speed up the development and improve the quality of small features.  But it’s too often at the expense of the Big Important Work — the heavy lifting, multi-month market analysis and architectural work that lead to REAL customer value and REAL competitive differentiation.

Yes, Agile can do wonders to improve product usability. But the results are often incremental in nature.  Opportunities to come up with innovative user interaction models that put the user experience on a different plane are not explored. Not enough time.

Yes, Scrum can improve the speed of decision making by requiring a “Product Owner” make on-the-spot decisions. But because it does not allow the Product Owner the customer face time to intimately understand the market, it too often results in products that addresses the verbatim enhancement requests of one or two specific customers (whoever spoke to the Product Owner last) while missing the real market opportunities. (See footnote 1.)

Yes, Agile can reduce the size of the development team. But instead of cutting costs, it moves the resource bottleneck to the product management and project management teams which are usually understaffed for the greater demands Agile places on them.

Yes, Agile is good at holding developers’ feet to the fire and jacking their lines-of-code-per-day rate through the roof.  It helps them fix bugs faster too. But because Agile keeps them in an always-on, semi-panicked state, it also leads to burn-out and prevents developers from doing the deep thinking required to solve the really thorny problems and to truly innovate.

Further, the War Room atmosphere and pair programming practices require a different, more outgoing personality than many developers naturally possess.  Granted, his research might be dated, but Tom DeMarco (author of Peopleware) found productivity was highest when developers had private offices with actual walls, windows, and doors that shut — the very antithesis of today’s War Room. In the War Room, the ideas of the more quiet, introverted, and thoughtful developers are too often drowned out by their louder, more obnoxious, and less gifted brethren.

So, despite the massive amount of hype currently surrounding Agile / Scrum, let the Cranky Product Manager remind you that — in the immortal words of Fred Brooks — There Is No Silver Bullet.

Agile is NOT the end-all-be-all for software product development. It is NOT the second coming. It is an improvement to be sure, but it has some big flaws – just like ALL software development methodologies.  And that is more than just “truthiness.”  It is the actual fraking TRUTH, beeyotches…


1. The Cranky Product Manager knows that many Product Management bloggers believe that this problem is solved if you separate the market / customer-facing Product Manager role from the development-facing Product Owner. However, the Cranky Product Manager remains unconvinced.  How can the Product Owner gain the perspective to make the best product decisions without regular customer contact?  More on this later….

CORRECTION: In the Cranky Product Manager wrongly claimed that Rich Mironov of Enthiosys supported the idea of separating the product manager and product owner roles. Untrue. He says he supports this role split it in a world of infinite resources and perfect communication, but of course that ain’t reality. Read his article all the way through (and wait for part 2) for a more civil and scholarly discussion of the problems the Cranky Product Manager rants about. It is truly a WICKED AWESOME piece, so get over there and READ IT.

Related Posts:

Scrum THIS

Hey You! Mr. Release Manager!

The Cranky Product Manager appreciates that you’re trying to do this Agile Scrum thing by the book. And that it is hard for you. Because before this Agile tsunami came crashing down you mainly just tracked the progression of different release documents (Is the PRD done? Check. Is the Functional Spec done? Check. Is the Design Doc done? Check.)

Ok, that’s not fair of the Cranky Product Manager. You did more than that. You also ran hurried release meetings once a week that tried to bury issues instead of surface them (OK everyone, here’s the status of all the documents. Anyone have any issues? None? OK, let’s adjourn.) You also organized two or three Fantasy Cricket leagues plus your wedding during working hours, and boy it all took a lot of time.

But now, in the Scrum era, things are different.  It’ s not easy. You once had a private office, but you now spend the bulk of your day tethered to a communal table in a stifling hot “War Room,” inhaling the body odor of The Veteran, trying to tune-out the grandstanding arguments between two nimrod Hotshots (“My idea is the most elegant…”, “No it’s not. It’s trivial. You’d have to refactor it immediately.”), and listening to the documentation writer bitch and moan that she can’t write the doc by Friday if the product keeps changing every hour. It’s really hard to organize fantasy leagues or surf the web with so little privacy. Plus the porn shui of the War Room is completely off.

So it sucks to be you, Mr. Release Manager, and the CPM is sorry for you.

But just because you are stuck in that War Room doesn’t mean the Cranky Product Manager should have to join you. You argue that in Scrum the product manager is the same as the Product Owner, and therefore the Cranky Product Manager needs to be constantly available to the team in order to make on-the-spot decisions within minutes of the asking.  Ergo, you demand the Cranky Product Manager sit in that sticky-note-encrusted, windowless tomb with you all damn day.

Uh, no way.  Not gonna happen.

Why not? Because the Cranky Product Manager needs to be the Voice of the Customer and the Voice of the Market.  How is she to do that without actually VISITING some customers and prospects?  And VISITING means that she actually needs to leave the office, hop on airplanes, and fly far, far away.  She cannot answer questions from the dev team within 5 minutes if she’s on a plane, or in a meeting, or on the phone with a customer.  Not that the CPM wouldn’t LOVE to hear debates about Iron Man or whether that Star Wars cartoon is “canon” or not —  all day, every day, for hours on end. Who wouldn’t?

And your response, Mr. Release Manager?  You argued that perhaps the Cranky Product Manager should not visit so many customers and should spend more time in the War Room.

Anyone else see the irony? The Voice of the Customer should have less interaction with customers?  All so she can make on-the-spot customer-facing decisions more quickly?

TRUST that the Cranky Product Manager will have more to say about this Fatal Flaw of Scrum in an upcoming post… She feels a HUGE rant coming on.

Related Posts: So You Think “Agile” Methodologies Exempt You From Product Management