The Cranky Product Manager is a little busy this week, seeing as she is now also doing the work of 4 people who were laid off.
So, she’s going to be a laze and reprint an old article from exactly 2 years ago: Scrum This! (see original post with the comments here).
Request: Don’t be an a-hole. Last time the Cranky PM published this article, she got scary, threatening, sexist, and pornographic emails and comments from the Agilista Henchmen – they were all freaked out she dared to say anything bad about their pet methodology.
———————————-
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
{ 27 comments… read them below or add one }
#prodmgmt – New Cranky Blog Post! : From the Archives: Scrum This! http://crankypm.com/2010/09/archives-scrum/
FROM THE ARCHIVES: SCRUM THIS! http://bit.ly/bJUhTX
From @crankypm archives: http://bit.ly/cDmNIE > I always figured PM to be above Dev methodologies, u just have to be the voice #prodmgmt #in
RT @capotribu: FROM THE ARCHIVES: SCRUM THIS! http://bit.ly/bJUhTX
RT @capotribu: FROM THE ARCHIVES: SCRUM THIS! http://bit.ly/bJUhTX
RT @crankypm: #prodmgmt – New Cranky Blog Post! : From the Archives: Scrum This! http://crankypm.com/2010/09/archives-scrum/
RT @crankypm: #prodmgmt – New Cranky Blog Post! : From the Archives: Scrum This! http://crankypm.com/2010/09/archives-scrum/
Cranky Product Manager has a good argument against Scrum … I agree: http://bit.ly/9dlfpW
RT @crankypm: From the Archives: Scrum This! ##prodmgmt http://bit.ly/bkajSW
RT @crankypm: From the Archives: Scrum This! ##prodmgmt http://bit.ly/bkajSW
It's not just startups that have to "get out of the building": Scrum This! – http://crankypm.com/2010/09/archives-scrum/
Some interesting points … if the product manager doesn’t have minions to act on his/her behalf, the productivity (velocity) of the Agile/SCRUM methodology does suffer. Looking forward to more on this thread from the prodmgmt perspective.
@crankypm #prodmgmt – New Cranky Blog Post! : From the Archives: Scrum This! http://crankypm.com/2010/09/archives-scrum/ <JB:I commented
From the Archives: Scrum This! http://bit.ly/cd0yj6
I’ve seen agile dev teams become completely crippled and unable to make a decision because the Product Manager acted as a Program Manager or Project Manager. For God’s sake, get on the plane, visit customers, and write user stories. Let the dev team be self organizing!
This is a very interesting point of view. Your blog is refreshing, but I wish one could find more content, though. I am looking forward to reading more from you. Keep up the good work. thanks.
Just in time for Labour Day – I love The Cranky Product Manager: RT @crankypm: From the Archives: Scrum This! #prodmgmt http://bit.ly/bkajSW
Ring any bells??? :) – Scrum This! http://is.gd/eW307
Nice Scrum/Product Management perspective by @crankypm.: http://bit.ly/a09uuV. Of course, I'm not a zealot so I would say that.
Hi Cranky PM,
while I can agree with some of your points in this post, what I find the most difficult to digest is your lofty and disdainful attitude towards your development team. Whether you share their interest on Star Wars and other assorted pop culture or not, these are the guys and girls that build your software. This is where the rubber hits the road, and all the client wooing and powerpoints in the world will be nothing other than vapourware if the team doesn’t build it. And you want them to build it to the best level of quality possible, right? Elevating yourself to a lofty position where you’re too busy or important to even enter their team room is not the best way to foster a healthy environment of trust and communication between you and your team.
Secondly, a scrum team needs a Product Owner if they are to succeed – especially in complex environments or with complex software. Either that’s you, or it’s not. If you have a separate person who is performing that role, then ok – you’re off the hook. But if you don’t, then it’s you. Those powerpoint slides aren’t going to break themselves down into user stories by themselves, hun. Ok, so now I’m being disdainful – but you can see my point.
#prodmgmt | Cranky PM : Scrum This! | http://is.gd/fbMJk
From the Archives: Scrum This! – http://crankypm.com/2010/09/archives-scrum/ #agile #scrum #pmot
Sensational, did you work for the same large Telco as me?
whoooooooa whoa whoa….whoa. hold..hold on. I’m WAY to high for this.
RT @crankypm: From the Archives: Scrum This! ##prodmgmt http://t.co/Mt4mrRez
From the Archives: Scrum This! – http://t.co/piz4GEnL
не согласен по всем пунктама) любой из 4-х моментов может быть дефектом, а может и не быть, причём вот даже если мы находим ошибку, которая воспроизводится во всех версиях продукта (ну не нашли её, либо тестировщики туда не смотрели вообще, либо проявлялась при определённых условиях, которые не были покрыты тестами, а тут тестировщик новый пришёл и тыкнул) её могут классифицировать как нам пофиг, всегда была и никто не требовал исправления, можем и не фиксить .б) даже реквест может быть багом, даже если в спеке написано не так. Дима вон не даст соврать я местами тупо выбивал из кастомеров требование соответствовать, например, Microsoft UI Guidelines, которые, по мнению заказчика, не критичны ибо врачи на интерфейс не смотрят .в) тестировщик должен быть экспертом-аналитиком программного обеспечения, в первую очередь. Он может разбираться в программировании, автоматизации, вебе и любой другой фигне, но главное он должен разбираться в софте, понимать зачем он нужен, что делает и кто будет его пользовать и зачем. С веб-софтом ситуация сложнее ибо там не всегда все варианты просчитаешь, но вот по факту: тестировщик Майкрософт, который молча кивнул на убирание кнопки вверх из проводника лох, даже если это было As Designed, тот факт, что кнопку вверх вернули подтверждает это.4) если тестировщик считает, что это баг это нужно писать. конечно он должен проанализировать, убедиться, что не дубликат, в некоторых случаях повторить воспроизводимость, можно уточнить дева или проконсультироваться с другими тестировщиками, что гоняли этот функционал, но в целом финальное решение баг или не баг должно быть всегда в сторону баг . В любом случае в процессе кто-то ОБЯЗАН ревьювить баги и принимать решения. Продукт овнер, дев лид, девелопер на которого заассайнили, но я своим всем (особенно новичкам) говорю всегда не бойтесь статуса не баг или так задумано эти статусы также важны для работы, благодаря им чистятся кейсы, уточняются текноты, улучшается документация и т.д.)5) по имейлам : вот свежайшая ситуация 6 лет назад было общение на стему спец-реквеста от одного клиента кастомеров, очень важного и крупного, там я предоставил специфическое решение по вопросам установки/удаления продукта через актив директори. Ессесно решение выслали, оно только для них, ни в какие текноты не попало. Продукт для этого клиента поддерживается, но новую версию они не покупают, точнее они купили один апдейт и дальше им не нужно (у мед учереждений США свои заморочки), таких клиентов несколько штук. И вот где-то полгода назад оказалось, что это же решение нужно другому кастомеру. Ессесно спросили меня, я поднял переписку, потратив на это пару минут и выслал солюшен с полным обоснованием, подводными камнями и вариантами решений без этого солюшена (имхо более правильными, тоже та ещё история). Если бы у меня его не было бы всё это заняло бы дохера времени снова, чтобы написать, описать, уточнить. Таких ситуаций, особенно на крупных продуктах для специфических клиентов у меня очень много. Чья это проблема неважно, важно, что даже если база знаний по деталям дефектов и каким-то проблемам есть и она в мыле, в багах это отлично. Если её нет жопа. Я вот очень хочу посмотреть на организацию процесса в Майкрософт, которые саппортят паралельно кучу разных ОСей и с разными и с одинаковыми багами, с разными клиентами, интересно, как у них там И кстати, в данном поле ввода баг: оно маленькое и писать в него такой пост визуально неудобно. При этом использование в Опере расширения Textarea resizer приводит к тому, что границы поля можно вывести вправо куда угодно, при этом ширина сайта не увеличится автоматически (хотя на форумах и других сайтах всё ок, ведёшь границу вправо, увёл слишком далеко сайт растянулся), видимо жёстко зафиксирована максимальная ширина (если тянуть вниз всё будет ок), после чего невозможно без рефреша страницы вернуть форму в нормальный вид, причём отрубается скролл, то есть ни мышкой, ни клавой, курсор ессесно заводится в невидимое пространство при печатании). Ну и на разрешении 1920х1200 сайт выглядит узковатенько )))