web counter

Posts tagged as:

Agile

To the Agile Community – WTF is wrong with you?

by The Cranky Product Manager on March 16, 2009

in Agile/Scrum

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.

Lovely.

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:

{ 44 comments }

Guest Post: The Cranky Test for Agile Product Managers

by The Cranky Product Manager on February 6, 2009

in Agile/Scrum

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.

CALCULATE YOUR SCORE

  • 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

{ 3 comments }

Take the Forest Ranger Agile Survey

by The Cranky Product Manager on January 26, 2009

in Agile/Scrum,Analysts

If you’ve been reading this blog for a while, you know the Cranky Product Manager thinks technology analysts (also known as Forest Rangers and Gardeners on this here blog) are GENERALLY (note 1) coin-operated ho-bags.  (See here and here.)

So you can appreciate the Cranky Product Manager’s consternation when confronted with Forrester’s Agile survey.  It’s about the effect of Agile development on the structure and operations of tech companies.

The Cranky Product Manager is very interested in this topic.  Very.

So, as much as this request makes the Cranky Product Manager feel disgusting/dirty/loathsome/repugnant/appalled with herself, she’s gonna ask you all to head over and take Forrester’s Agile Survey.

‘Cuz maybe then the Forest Rangers will share the results with her, even though she has no access to their research.  And even though she constantly maligns their good name. (hah!  right!)

Because then, maybe, she’d have more fodder for more cranky posts on Agile.

—————————

Note 1:  Observe that the Cranky Product Manager said GENERALLY.  No doubt, there are analysts that are NOT coin-operated.  But they are probably still ho-bags.

{ 2 comments }

The 5 Types of Beta Testing Programs and Why 4 of Them Suck

by The Cranky Product Manager on December 18, 2008

in Beta Testing

Let the Cranky Product Manager remind you all of the purpose of  Beta testing programs:  To get customers to actually use your about-to-be-released software.  Why? To find and fix problems that would not have been found by internal-only testing.

So WHY then, WHY(!?) do so many so-called Beta testing programs seem explicitly designed to PREVENT this type of feedback?

Let the Cranky Product Manager classify and explain the different types of Beta programs, of which the vast majority  do NOTHING to improve product quality or identify customer issues.

1. The “Don’t You Dare Complain Because This is Free” Beta

This type of Beta is otherwise known as the “Google Beta”.  An Example? Take Google Gmail, which put out its Beta release on April 1, 2004.  As of this writing in December 2008, 4.5 years later, Gmail is still officially in Beta, with no word for an official release. Ever. 
Clearly, the purpose of this type of Beta is NOT to collect customer feedback.  More likely, the “Beta” designation is a euphemism for “No Support. Take It Or Leave It. Don’t Complain To Us If It Doesn’t Work Because It’s Free.”
If there is no mechanism in place to actively contact Beta customers and solicit their feedback (as opposed to just relying on them to send messages to a forum or send YOU an email), and if there is no path to ever release this product, well it’s a “Don’t Complain Because It’s Free” Beta.

2. The Paper Beta

This is where a company has a ridiculously short Beta period, and as a result recruits very few (if any) test customers and thus gets very little feedback.  The whole goal here is to NOT uncover issues.  Instead it is to push a piece of crap out of the door on a certain date, regardless of (lack of) quality, while still being able to honestly look customers in the eye and tell them your product was Beta tested.  Because, yes, savvy customers ask that. 

(Even savvier customers ask how big the Beta program is, how many customers participated, how long it lasted, and how many issues were uncovered and subsequently fixed.)

Result?  There is no real effort to sincerely, honestly collect feedback.  And any feedback uncovered will probably be ignored – because “it’s too late to fix it now.” Bugs will be filed, and possibly, MAYBE, they’ll be addressed in the next production release.

If your Beta uncovers less than 10 issues or is less than 4 weeks long, congratulations, you had a Paper Beta.

WARNING: Running a Paper Beta will DOOM your efforts to recruit customers for any future Beta program – Paper or not. The few customers that do participate be incensed that they spent time installing, testing, and providing feedback on your software, only to have their issues summarily ignored and potentially never fixed.

3. The “Agile” Beta

Allergic to any form of process, some Agile proponents will claim their awesome methodology eliminates the need for expensive Beta programs.  Why? Because, supposedly, with Agile the product is “Beta every day,” or at least it is at the end of each sprint or iteration.  And part and parcel of the Agile philosophy is getting direct customer feedback throughout the entire development process. Ergo, the claim that no Beta Program is needed.

All this is fine and good, but it still does not obviate the need for a Beta program.  Because without getting actual product into the hands of actual customers, you won’t uncover the problems that can’t be uncovered in internal-only testing.  It is ESSENTIAL that the customer actually attempt to use the software ON THEIR OWN, for things THEY actually want to do. If they don’t and you just provide a demo or screenshots (as is often the case for Agile-style “in process” customer feedback), well TOO BAD it doesn’t count.

How did you get into this sad situation?  Most likely, it’s because you’re letting the Development organization push you around.  Because, after all, if the Beta program is eliminated, their jobs become easier and less work. Plus, they can now push their risky bug fixes to the very last minute – as in minutes before that “final build.”  This is extremely dangerous yet happens all too often. 

4. The Haphazard Beta

The Haphazard Beta is one where you get the product to a particular state, claim it’s Beta, and THEN try to figure out (last minute!) how to actually recruit some customers and get some usable feedback.   There’s no organization, and no directed attempt to collect and quantify feedback. 

It’s a mess. A big loosey-goosey, panicky mess. 

And it’s your fault, Product Manager. Your fault.

If you had been on the ball and actually done some recruiting ahead of time, along with a smidge of planning about how to collect and handle issues, well you might have actually had a REAL Beta. Alas, it’s too late to fix it all now. So hold on tight, pray you don’t lose your job, and promise to do better next time.

5. The Real Beta

This is the Beta program done right.  Real customers and prospects actually use the software and identify issues (at the bug level, workflow level, and higher levels) that you could not have found on your own. 

And THEN… here’s the kicker…. you actually DO something about the issues they find.  That is, YOU ACTUALLY MAKE CHANGES.  You fix the bugs.  You fix the work flows… You learn how to make your product better. 

And it all goes smoothly.

You have recruited enough customers – in both number and variety - to accurately represent your target market.  You have enough time to fix their issues.  You care enough about putting out a quality product that the final product is something that you can be proud of – something that won’t create a PR disaster requiring a zillion-dollar advertising Band-aid, like the well-known disaster below…

{ 22 comments }

What a jackass the Cranky Product Manager is.  Before she knew that he would “violently” disagree with her (shame on him!), the Cranky Product manager promised Saeed of the excellent  On Product Management blog that she would post about his blog’s nomination for an uber-prestigious Canadian Blog Award in the category Best Professional/Career Blog.  But alas, the Cranky Product Manager did not act right away. She waited, thinking Thursday would be a good day for said post.

And so Thursday, today, arrives, and just as the CPM was revving up and writing a glorious call-to-action to help the On Product Management crew reap their just rewards, she discovers that “voting round 1″ is now over, and alas Saeed/Alan/Ethan did not advance to round 2.

F$&*.  The Cranky Product Manager feels partially responsible for this utter travesty of justice.  If only she got off her lazy ass and wrote a post earlier. Maybe it would have helped. What a turd she is.

Alas, the Cranky Product Manager flaked and broke her word. There’s no decent way to make up for this, but the CPM is going to try.  Here goes….

If you haven’t checked out On Product Management do so now. Below are some of the Cranky Product Manager’s favorite posts, most of which give their unique take on the reality of Agile product development. Unlike most others writing on Agile, these guys don’t just drone on with the Agile party line. Instead they make though-provoking observations and arguments that you have not read anywhere else. Examples:

  • Annoyed by newly Agile-ized developers who act like they invented the concept of getting customer feedback?  Check out Is Product Management Agile?
  • Why Agile/Scrum is not a panacea, and commentary on the ironic inflexibility of some agile proponents: Agile/Scrum Reality Check.  (Was going to say “rigidity” instead of “inflexibility”, but kept snickering like Butt-head.)
  • Agile/Scrum and Product Management – Parts 1, 2, 3, 3a, and 4. (whew! lots of reading, but worth it).
  • Also, check out the hilarious Uninterruptible Power Supply Saga (don’t forget to read the comments): part 1, part 2, part 3, and part 4.

{ 3 comments }

WTF Refactoring

by The Cranky Product Manager on November 5, 2008

in Development

Scene: War Room. 2 days until Code Freeze.

LEAD DEVELOPER:
So, unfortunately, we’re going to have to pull FavoriteFeature out of the release in order to meet the schedule.

THE CRANKY PRODUCT MANAGER:
Huh? That feature’s been in the product for 3 releases now. Customers love it. Why do we have to pull it?

LEAD DEVELOPER:
Well, we had to refactor the code, but unfortunately we just don’t have the time to write unit tests.

THE CRANKY PRODUCT MANAGER:
Why do you need new unit tests? Can’t you just use the old ones?

LEAD DEVELOPER:
We can’t. We don’t have them.

THE CRANKY PRODUCT MANAGER:
Why?

LEAD DEVELOPER:
Because they weren’t working with the new code.

THE CRANKY PRODUCT MANAGER:
(pause)
Refactoring means cleaning up the code while preserving existing functionality, right?

LEAD DEVELOPER:
Yes…

THE CRANKY PRODUCT MANAGER:
(pause)
So, if we’re preserving existing functionality, why did all the old unit tests fail?

LEAD DEVELOPER:
Well, I, uh…. Well, …while the guys were in there modifying, you know, the CODE, well, they, uh, figured they could, uh…, well…, add some stuff to create some WICKED cool Hologram broadcasting stuff. It affected the old tests.

THE CRANKY PRODUCT MANAGER:
(pause)
First, Hologram what? That’s not in the backlog!

LEAD DEVELOPER:
We thought it would be cool.

THE CRANKY PRODUCT MANAGER:
No one agreed to it or even discussed it! Seriously, dude, what the effing eff!?

LEAD DEVELOPER:
 (looks at his shoes)

THE CRANKY PRODUCT MANAGER:
Second, how can you look me in the eye and call this refactoring when you SO did NOT preserve existing functionality? The Cranky Product Manager calls BULLSHIT. You did a rewrite or rearchitecture or whatever, in a risky piece of code without telling anyone, and then you try to claim it’s a “refactor”. How the FRAK is the Cranky Product Manager ever to believe you again when you tell her you’re refactoring something for readability and ease of future maintenance?!? Do we need group reviews of your code on a daily basis to make sure you’re not slipping Warp Drive into the product?

LEAD DEVELOPER:
(looks at someone else’s feet)

THE CRANKY PRODUCT MANAGER:
Third, can you tell me what the POINT of even having unit tests IS, if all you do is DELETE them when they fail?

LEAD DEVELOPER:
(Looks at watch)

THE CRANKY PRODUCT MANAGER:
(Sweet smile)
And forgive me for pressing on this point, but you’ve said, and I quote, ‘John McCain will reform the way Wall Street does business….’  Can you give us any more examples of McCain’s leading the charge for more oversight? … Specific examples in his 26 years of pushing for more regulation?

LEAD DEVELOPER:
Well, I’ll try to find you some and I’ll bring them to ya!

CPM smiles genially, then slowly pulls every single last hair from her head.

{ 12 comments }

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

{ 9 comments }

Heresy Against the Church of Agile Software Development

by The Cranky Product Manager on September 23, 2008

in Agile/Scrum

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:

{ 21 comments }

Scrum THIS

September 2, 2008

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 [...]

Read the full article →