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
- Stop getting so defensive with people who don’t think Agile is the second coming, and
- Do something about your lunatics.
Please. And thank you.
Related Posts:
{ 43 comments… read them below or add one }
There is a reason that the world of product management isn’t perfect. The imperfections are being perpetuated by people who are too weak to change. Others are too weak to remove the weak. Worse, these weak organisms are allowed to reproduce to carry on this tolerance. We need to get rid of everyone who isn’t like me. Where is process Darwinism when I need it?
Fact is, things are getting better. Maybe too slow for some. But as they say, “We don’t have to change, survival isn’t mandatory.” Those lunatics said the world wasn’t in the center of the universe. The fringe of society gave voting rights to women. And to make things even more compelling, a black man is now the President of the United States.
Product Management is also making radical changes, sometimes frustrating, but moving forward. I’m sure the software developers have their side of the story, investor theirs. This is a war, someone must die. We pick a side, and kill the enemy. “The people’s tide shall rise and win, woe to those who can not swim.”
Okayyyyy, Val. Not sure if you are intending to be ironic or sarcastic or …? Who are the weak in your analogy? The “Agile is Perfect, Blaspheme My Methodology and Be Destroyed” zealots, or those who think Agile is not perfect?
Sounds like you’re in favor of the lunatic fringe? Could the Cranky Product Manager POSSIBLY be reading this wrong?
Seriously, how could you be in favor of the type of attacks and threats these crazies are using?
Is the CPM just totally not understanding your comment? She feels like she doesn’t get it. Sometimes irony / sarcasm don’t transmit properly on the web.
Dang it! Here you go and post a fairly elegant point-of-view reminding all of us that we work in a dynamic field that can change its mind so fast that we all find ourselves out of a job – AFTER I just got the big “I Agile” tattoo.
In all honesty, I had to get the tattoo because I needed something to cover up my previous “Ada FOREVER!” tattoo.
Which of course had been gotten to cover my original “FORTRAN 66 Rocks!” tattoo.
Sigh, maybe I can get a discount on that “Ruby on Rails Will NEVER Die” tattoo. Or not.
- Dr. Jim Anderson
The Accidental PM Blog
“Home Of The Billion Dollar Product Manager”
With 17 years in software development, I’ve had a nice vantage point from which to watch “Agile” wend its way from radical concept to over-leveraged buzz word. Having only hung up my production coding spurs a little over two years ago and having done custom-software one-off projects and product development alike, using myriad methodologies to include so-called Agile methods, I’ve never seen a method that could be implemented successfully without a high quality team of professionals. Moreover, I’ve seen all too many projects fall prey to incompetence regardless of the method employed. My point is that anyone who believes that a methodology of any stripe is the guarantor of success in product development is clearly either inexperienced, is more interested in talking about delivering software than actually delivering it, or is “a frakin’ lunatic”.
Every software development ecosystem requires a tailored approach using one of the well-understood methodologies available to choose from and based on the culture and capabilities of the organization conducting the work. I LOVE Agile. It works. But to make it work means a willingness to assess an environment and employ, on a dynamic basis, strategies that will improve that environment’s ability to deliver functioning, quality code that have value to the user. There is no prescription to solve these sorts of woes.
Finally, it’s the people, above all else, that make a method work. Buzz words come and go. People who are able communicators, who are smart and can get things done, and who value the needs of the users of their products, those people are unstoppable. All this process stuff is just another tool in their arsenal. Pick the right tool for the right job.
Finally, for all the Agilistas out there I want to remind them of the fundamental points of our glorious movement toward software development nirvana: http://agilemanifesto.org/ .
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Yeah, there’s no denying we’ve got some crazies. I break them down into four categories.
The Previously Crazy: New movements are crazy magnets. Many loons like yelling or ranting, so how could they resist a shiny new idol to worship or a big new stick to beat people with? This includes those with a natural taste for dogma, and a lot of Internet trolls.
The Recent Converts: This was my particular problem circa 2002. I had made software for a long time before then, and was just tired of it. I was ready to change careers. Adopting a lot of the Extreme Programming techniques made my life (and my products) worlds better. I wanted to tell people about it, and I’m sure I was just as annoying as anybody who had just lost weight with a new diet, found Jesus, or changed political parties.
The (False) Prophets: Most of the early agile bigwigs are actually pretty reasonable; they don’t think there’s only one way to do Agile, and they look forward to the day where we figure out what comes after Agile. But these days there are a lot of people who find it lucrative or ego-boosting to do the whole prophet shtick, which can include throwing stones at the non-believers.
The New and Insecure: It bothers some people, especially if they’ve just made the transition to some Agile method, that a lot of folks just miss the benefits of the Agile approach. Especially when the nay-sayers spend a lot of time peeing on other people’s parades. If they aren’t feeling secure, they may get sucked into the somebody-is-wrong-on-the-internet trap, which can make anybody a little crazy.
The first I can’t fix, other than to repudiate them. The second will mellow out. The third are attention whores; ignore them and hopefully they’ll go away. The fourth respond to a bit of golden-rule treatment.
As to your suggestions, Cranky, if you’ve got ideas on how to make it happen, I’m all ears. Aside from the time I’ve spent for the last 9 on mailing lists, blogs, and conference conversations trying to get everybody to play nice, I’ll make a public offer. If anybody feels like some Agile supporter is a jerk, send them my way and I’ll have a talk with them. My company is Scissor, and my email address is my first name. I’m glad to help.
Even Ken Beck, in his latest book on Implementation patterns, http://tinyurl.com/cq97tn, steps away from the zealotry.
It reminds me of the open movement. As a product manager, I run into programmers that feel like the profit motive is suspect. But, they should realize that they do eat, and somehow put food on the table, because someone is paying them to program not-so-open software, and paying them to spend 10 or 20 percent of their time coding open software.
And, there have been the recent spat of books on object thinking. Well, object oriented got hijacked by the functional programming types, so we are stuck with gets and puts. And, the databases with Id column keys that according to relational theory, they should be able to do without. It’s an imperfect world.
I’ll admit to being a TALC zealot, but do I really expect the rest of the world to do it my way? I have a hard enough time getting my founder to get us just one client gig. So no, of course not. In the meantime I zealot on.
And, there are the anti-sotware engineering crowd. They don’t realize, or maybe they do, that software engineering let everyone through the front door, and they are still coding today. If you go with Barry Bohem’s Software Economics II and the theory that smarter programmers make better programmers, then Agile is the way, but what about the real population, rather than the sample. Sure look for them, but you hire who you can find in that moment of need.
We’ve seen this over and over. The bigger problem surfaced today with someone’s tweet about design and how it is different from technical design. Superior they said. Tough! The art design crowd won’t hire us, and we still hire them.
Let’s just make the best product we can in this imperfect world. All of us, with all our divisions, make a difference and make the world better.
Thx for the vote of confidence – I really do try to cause a discussion to happen when there is a topic I think needs some more exposure; even at the risk of sounding naive or mis-educated.
There are a lot great comments here, and most have hit the nail on the head for me. Actually, more often than not I’ve worked with dev teams that hate any word you mention they recognize simply because they don’t want anything to do with formal process.
Something to do with being in a start-up and not wanting to “conform” for “the man.”
I think you can call a practice anything you like – if it’s helping your organization ship great products that solve a problem then that’s nothing called anything except good (or in some cases, great) product management.
“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.”
Did someone really say/write this to you???? How completely offensive. And violating.
Good lord. Thk god i don’t have a blog if that’s the type of message you get. Can’t believe no one else here has commented on how outrageous this message is.
Reminds me of something I read (can’t find reference) about how all the women writers at Slate received about 40x as much hate mail as male writers. I’ll bet you get more of the hate because you’re female.
Here’s a link to that Slate article about sexual threats against women bloggers.
http://www.slate.com/id/2165654/pagenum/all/
When it comes to Prod Mgt methodologies, keep al your options open and don’t get sucked into the Agile groupthink…(read the Halo Effect by Rosenzweig to help with your decision-making)…
In my experience, if you start off by thinking that you’re going to be 100% Agile, when it’s all said and done, you will likely end up with a custom process that generally follows some Agile best practices, however, will have its own flavor of Agile tweaked uniquely to fit the organization.
Approach Agile like it’s just another product that you manage. Soon after, you’ll see that it is simply foolish to think that any one methodology is perfect (Agile is certainly not), however, if you find yourself working on implementing a prod mgt methodology you should strive to study the organization, its processes and culture to make sure that what you’re going to implement will fit and the org will have the organic discipline to follow it into success.
The BIGGEST problem with EVERYTHING is its crazy, insulting, demeaning, and threatening lunatic fringe.
> “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.”
That is just astonishing. There is a saying that “in academia, tempers run high because the stakes are so small.” It is astonishing that people become so personally invested in a methodology that they think that sort of behavior is normal and acceptable.
I consider myself a strong advocate for Agile and a believer in the change it can bring about in a software development organization … and I agree with the CPM 110% … I’ve personally told a number of “agilistas” that the biggest threat to the success of Agile is the irrational behaviour of these individuals and the unfounded assertions about practices, behaviours, etc … thanks for surfacing the discussion CPM!
Nicolai, True enough, but the Cranky Product Manager receives about 10x as much hate mail when she posts on Agile versus any other topic. Why is that?
Well, you can always experiment by talking about DVCS and comparing it to Eric Sink’s responses…
There’s another group that seems to have some hot heads. In that case, one of the group’s most outspoken supporters comes off as being an incredibly rude and narrow minded individual. He may not be in real life and I would like to give him the benefit of doubt. But when speaking at high profile engagements that are obviously being filmed, people should have the common sense to appeal to a non-believer’s sense of logic rather than (attempt to) beat them down.
In the more general sense, I noted a comment that the current Agile gurus are generally not the crazies. But how did the early innovators of the agile movement get started? I don’t know, and I’m not trying to lay blame of any sort for something well in the past. I’m only trying to see if there’s a pattern in that direction. Are the originators of these new methods creating environments that lead to such hatred? I certainly hope not, but…
It’s sad to think that ideas that may have a great deal of merit to them may lag in acceptance because enough outspoken proponents, originators or otherwise, lack the courtesy necessary to create an environment where everyone is allowed to take part.
Jim Anderson shows good perspective. Agile is the latest in a long line of software development philosophies/methodologies. It’s a tool that should be applied where it makes sense. Some people will get overwrought — that’s life and that’s people. You see remarkably similar dynamics with other business methodologies, e.g. Toyota Production System, Lean, Six Sigma.
All methodologies make economic assumptions. For example: Unit testing is cheap. Customers are accessible. Communication between team members is cheap. Refactoring is easy. If the assumptions don’t hold true, the methodology probably won’t work for you, or at least not be cost effective.
I’ve worked on projects where I needed a $250K broadband protocol analyzer and a room full of PBX cabinets to test traffic shaping firmware for an ATM board. And that wasn’t even end-to-end testing.
I’ve worked on projects where refactorying code in an 8 million line code base (some of which dated back to the late 1970s) was expensive because there was no way to completely test it (unless, like, you had a Russian telephone system handy).
I’ve worked projects where I wasn’t allowed to know who the customer was, much less talk to them.
And we’re all now working on projects where the development team is spread across timezones encompassing many hours, making effective face-to-face communication very very expensive.
Most of the Agile proponents seem (to me anyway) to be firmly in the “four developers coding Python and Java to run on a Intel box running Linux” mentality. If that works for them, I’m all for it. But not all development follows that model.
Having said that, I believe in stealing good ideas where you find them, so if there’s some part of Agile (or any other process) that makes sense for you, use it.
I think most processes boil down to the following:
1. Recruit people who are willing and able to achieve your goals in a timely manner, whatever that means for your project.
2. Make the code-test cycle as short as possible so you can iterate as quickly as possible.
3. Make communication among team members as cheap and effective as possible.
Everything else is just some way of accomplishing those three things.
A recent post by Tom Grant prompted me to think about this, too.
Know how the people who love Twitter LOVE TWITTER?
“Agile” in the PM world, to me in a lot of ways, is like Twitter among the digerati. People are REALLY excited about it, because there’s some value there, and they’re getting really excited and–and–and-!!!
We’re forgetting:
Agile is a development methodology, created in reaction to wasted cycles stemming from poor management.
Product managers should be focused on assessing the market, creating the strategy, and providing enough context so dev can make proper engineering decisions based on solid data.
To answer your question to Nicolai — maybe this is the dark side of product management? The best PMs are really passionate about their products. But passion doesn’t always equate to “good” or “sane”.
- Chris
http://twitter.com/chriscummings01
Disclaimer #1 This is a hot topic for me that currently puts me into the red
Disclaimer #2 I am by no means trying to produce an incredibly thorough response, article, debate on this topic. Instead, this is a brief response to your post.
Disclaimer #3 All of this is my opinion as of right now. As I get new and valuable data, it is subject to change!
Disclaimer #4 It’s late on my side of the country
That being said, I am sure there are some decent responses to my questions / positions stated below. Drop me an email if you want to have a more in-depth discussion on the topic (CrankyPM and agile enthusiasts alike).
I am a software engineer turned Product Development person two years strong. My shift in responsibilities is what actually drew me to this site. I still put on my engineering hat from time to time (tonight for instance) so have stayed pretty plugged into the space both in specific technologies (we use Ruby on Rails, Python, and Clojure — uber geek technologies) and methodologies (we are also agile). However, CrankyPM, what you are addressing is a growing problem I have seen spreading rather rapidly through the engineering community. If you look at the basic principle’s of the agile manifesto craig references above
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
you will notice it doesn’t name any specific implementation choices currently touted by these agile zealots (XP, TDD, BDD, etc). Instead, it really emphasizes understanding the current domain, its constraints, and then picking the right tool(s) for the job that ultimately best serve business, customers, and users.
Internally, within the engineering community these zealots are being touted as gods, which for the life of me I don’t understand. I am afraid these zealots are representing and teaching a very rigid / fragile/ black & white methodology that serves more themselves then their customers. Every project represent new constraints that the engineering team must identify and react to. Not knowing how to identify and react to those constraints spells disaster. Which, from what I can tell, these zealots are teaching.
I (and my engineering team) view agile as an iterative approach to identifying the right tools for the job given the current environment. Specifically on a two week life cycle. From one iteration to the next they will reflect on what is working and wasn’t isn’t working and adjust, collaborate, and communicate. Simple as that. If the current environment supports some of these often touted implementation choices like BDD for example, awesome. However, if in the current environment these aren’t appropriate tools, awesome. The goals is to know both when, and when not to bring these tools out of the tool box and communicate / discuss/ collaborate with the customer.
PS. A question I keep asking is, “So, how did good software get developed prior to XP, TDD, BDD, etc? Seriously, is all of NASA’s, the financial systems, banking systems, C.I.A’s, N.S.A’s , and healthcare’s software complete crap prior 199X?”. I really doubt the answer to that question is yes
“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.”
Being in agile circles since the 90s, doing Scrum for som years I never met such a zealot you describe.
Some misconceptions cleared:
- There are no agile projects. In agile there is story flow, not projects.
- Most sprints are in-time and in-budget, and yes, there are sprints that fail mostly because of external impacts
“Seriously, is all of NASA’s, the financial systems, banking systems, C.I.A’s, N.S.A’s , and healthcare’s software complete crap prior 199X?”
Of course not. But perhaps with a lean methodology the taxpayer would have gotten the system with 50% of the money.
Cheers
Stephan
http://twitter.com/codemonkeyism
Hi, Anthony. Could you name some of the people you see as zealots teaching black-and-white dogma? It’s hard to fix the problem if I don’t know who’s creating it.
Regarding the relationship between the Agile Manifesto and the processes that are Agile, note that the Manifesto is a declaration of commonality, and not a description of all that you need to run a successful project.
Some of what you perceive as rigidness could be one of two things.
First, novices want different things from processes than masters. In particular, they generally ask for clear rules, checklists, and other obvious, easy-to-follow structures. If I give them a lot of high-minded agile philosophy, they’ll just look at me funny, and if they try to work from that, they’ll generally fail. Right now I’m learning to run, and I don’t want to be told to just trust my body and do the workout that feels right. I want clear, prescriptive schedules of how far I should run each day, and when to rest.
Second, one of the big problems with Agile getting popular is that a lot of people are doing weak, distorted versions of it. Some are doing their same old bullshit and putting Agile labels on it. Some read three blog posts, flip through some Agile book at a bookstore, and then change their process wholesale, creating fresh and new bullshit. And some are picking and choosing fragments that sound good to them, blaming us for the ensuing “Agile failure”.
The reaction to that has been for some to draw clearer lines between what is Agile and what isn’t. Some perceive that as rigid and dogmatic, and I’d welcome any suggestions on how to provide clear standards that don’t come across that way.
Also, a quick answer to the “how did good software get developed prior to Agile” question, some answers.
One, a lot of it wasn’t that good. Two, software today is, thanks to the incredible pace of hardware advance, much bigger, more complex, more feature-filled, and more interconnected. Three, their release cycles were 10-100 times longer than modern software. Four, what software was good was incredibly expensive by current standards.
Customer’s available works in an IT environment. No product manager/owner works in an IT environment. This changes in a software vendor. The Agilists need understand that change. What is their solution? Sticking to an IT perspective isn’t workable.
First of all, any ping-pong comment match on Agile PMishness isn’t complete without Roger Cauvin weighing in, so someone go knock on his door and invite him over for a few rounds. I offer this out of respect as I think he’s got a thoughtful POV, even if I don’t agree with him.
bob
Cranky,
I’m in violent AGREEMENT with you here! :-)
But you say it so much more forcefully and dare I say eloquently than I did in my post on the exact same topic.
http://onproductmanagement.net/2009/02/21/adam-bullied-vs-enthiosys-dont-fight/
Saeed
In my experiences as a scrum master and product owner, the most valuable advantages of the Agile methodology were:
1) Regular, frequent interaction between eng, product owner, and customers.
2) Emphasis on producing tangible, demonstrable results by the end of each sprint.
3) *GOLD STAR* This methodology is championed by engineering geeks.
That last point is the most important, but let me cover the first two quickly.
On #1, I’ve worked with teams where frequent interaction was the norm (= great) and with teams who practically had to be subpoenaed to interact with you outside of regular meeting (= bad). Engineering culture is adverse to having to spend time talking with non-engineers, especially non-engineers who use technical terms in awkward ways (e.g. marcomm folks). Daily stand-ups saved SO much time – I heard about problems almost immediately, rather than having to wait until they showed up buried in some engineering status report. As a result, those problems got triaged, clarified, and resolved much faster and the teams stayed on-course.
On #2, it’s harder to hide the shirkers when everyone is under peer pressure to show progress on a regular basis. Within a couple sprints, it’s painfully obvious who’s not holding up their end. And I’m not harping on productivity, I’m harping on reliability. A really productive guy who consistently misses his hourly estimates will hurt you a lot more than a less productive guy who actually sticks to plan.
On #3, this is the real clincher. If you read the histories of other prominent methodologies, they involve a lot of business/management types working with engineering types, often deriving from pre-modern-software methods. Agile comes out as the holy tablet from the Gods of Coding, untainted by the defiled hands of businesspeople. This immediately makes it much more attractive to programmers than, say, a methodology touted by a case study in Harvard Business Review that’s derived from manufacturing.
Ponder the last two “agile” points:
- Customer collaboration over contract negotiation
- Responding to change over following a plan
While the first two points aim to defuse the technology/process wars that occur between the geeks, these last two points aim to defuse the requirements/scheduling wars that occur between geeks and suits.
In fact, it always strikes me as naive that it implies that a good contract doesn’t involve customer collaboration, or that a good plan doesn’t accommodate change. Instead, I believe that a lot of programmers see those last two points as codifying their two most frequently used “outs” that otherwise get them into trouble – trying to do things “their way” because they know what the customer really wants (or what a smart one should want anyway), and slipping dates because of a problem purely on the engineering side (like bad time estimates, fixing problems with dev tools because they had to upgrade during the middle of the cycle, etc.).
Fortunately, even if my theory about the motivations for the agile manifesto are true, it still works out well for product managers. Why? Because unless software geeks decide they can suddenly change their stripes, the product manager will still be the one responsible for dealing with the customers. And the changes referred to in the manifesto are really supposed to be changes in the market and hence requirements, not changes dictated by willy-nilly technical issues. And again, the product manager will be the one who is up-to-date on the market and understands the big-picture about what it will take for the product to be successful.
Oh, in that last paragraph, you can change “product manager” to “product owner” – I just thought I’d point that out before anyone embarrasses themselves by trying to point that out. After all, if you quibble about the semantics, you’re doing exactly what the Agile founders were trying to avoid.
It’s an unfortunate practice that software programmers are frequently referred to as “engineers”, and I’m guilty as anyone for using that nomenclature. Fact is, many programmers can scarcely be called engineers as they have little to no formal education in engineering concepts. Instead, they just having training in how to use a certain set of tools, certain programming languages, and certain methodologies. If there were trade unions for programmers, those guys would be the members. It’s the difference between being an electrician and being an electrical engineer. And while that may sound derogatory, there’s also a big difference between being a chemist and chemical engineer. Doesn’t mean that one is “smarter” or “better” than the other, just pointing out that they aren’t the same.
Why do I even bring that up? Well, ever go drinking with a bunch of union contractors? Lets just say that they use language similar to what the CPM gets in her Agile hate-mail :)
Trivia question – can you name the state where it’s actually illegal to use the title “Software Engineer”?
Tennessee!
Finally, a question that doesn’t make me fall into, or off of, the Agile wagon.
Fierce debate about #Agile jihadists in post comments. Check it. http://tinyurl.com/cosgz8
RT @crankypm: Fierce debate about #Agile jihadists in post comments. Check it. http://tinyurl.com/cosgz8 Dialogue is good; so is debate.
RT @productologist: RT @crankypm: Fierce debate about #Agile jihadists in post comments. http://tinyurl.com/cosgz8 Dialogue/debate good
Coherently bitchy #Agile #prodmgmt thread. FTFC: “First, novices want different things from processes than masters” http://bit.ly/LFAF6
Carina – Holy crap! Didn’t think anyone else would get that :D
Good lord, never had a post with 26 comments before. http://tinyurl.com/cosgz8
Woh, many comments, several very long (why i am sounding like Rorshak?)
So, let’s twist the subject, shall we?
I suggest that Agile, like any method for developing software faster and better, will eventually succumb to the fate of diminishing returns.
At that point (or sooner if possible), it will be time to shift the focus from agile software development to developing Agile Software… Software that supports business change without requiring software change.
Use whatever approach you want to deliver it, but that is what the Business needs now.
Bookmarked: To the Agile Community – WTF is wrong with you? | The Cranky Product Manager http://tinyurl.com/cw45lg
RT @jonbab1: Bookmarked: To the Agile Community – WTF is wrong with you? | The Cranky Product Manager http://tinyurl.com/cw45lg
Don’t you the hard core fringe with most things?
* Linux
* Debian
* Emacs
* USA is the best (or is not the best)
* religion
* ways to cook a chicken
* vegetarianism (or wearing fur)
* etc, etc.
Now, do we require the moderates in each of those positions to control the lunatic fringe? Should we?
Hmm, perhaps we should ;)
Tim
Yes, you get true-believers for many, many things. Sometimes they can get a lot done with their intense focus and passion. This can be a good thing, but not always. It can be hard not to get swept up when the tipping point of popularity is reached. That’s why perspective and wisdom is important — choose the good ideas but realize that there are still many sources of good ideas and don’t fall into the trap of “when you’ve got a new hammer, everything looks like a nail”. Agile has the advantage of a good framework and common language for solving problems and there is a lot be said for that as a starting point, but it is not the whole story.
@pmagile from the crankyproject manager – follow the gourd :-) http://tinyurl.com/cosgz8
Someone reaaaaaally doesn’t like the Agile/Scrum process (maybe it’s the context?) http://tinyurl.com/cosgz8
Agile/Scrum is not all that > http://tinyurl.com/cosgz8
Hey,
I’ve been a PM for many years and employed a few myself. There is a venn diagram I sometimes show people that has one circle with (People who can really project manage) and another with (People who’ve been on a f***ing agile course or read a book). There is an intersection between the two but there are also a lot of other people outside the overlap .
I once watched someone have a stand-up meeting (useless PM, great agile convert) when the dev team were trying desperately to release code critical to a project. The timing was wrong, they misread the signals, didn’t communicate but hey, they were fundamentally borking the work in an *agile* way hehe.
I’m a convert to agile methods and I’ve used them long before they became fashionable but never in a way that interfered with or ignored my PM antennae. Draw the venn diagram.
Agile Jihad : Nice debate about Agile methods – I’m right in there with them <grin> : http://is.gd/pYWW
{ 1 trackback }