Twitter Updates

    follow me on Twitter

    Feeds & Email

    • Feeds and Lists
    • FeedBlitz
      Enter your Email

      Powered by FeedBlitz
    Blog powered by Typepad


    « Carnival of Enterprise Architecture #13 Coming December 2, 2008 | Main | My Uncle, The Blogger »



    I think you are being overly idealistic here. Projects have varying requirements (for example dealing smoothly with the internal politics of an organisation could be considered a non-functional requirement, in a broad sense), and a flexible approach to the problem is a benefit, not a hindrance.

    "I don't believe you can be purist about this stuff. It's not often I'll do a 100% FDD implementation. I'll look at what are the current resources, what are the current practices, what are the constraints, what's working and what's not and then it's a mix-and-match of practices and approaches." - Jeff DeLuca, SE Radio podcast


    I think the point the blogger makes is adept and honest. I would like to ask the previous commenter David, who reduces these important observations into being idealistic, does he then support the mentioned behavior patterns, like promoting your own ideas by misusing the name of some hit technology or methodology?

    As far as being a purist is concerned, do we call scientists purists when they inform us about the global dangers we will have in front of us if we don't change our consumption habits? When the medical professionals tell us that smoking is highly harmful to our health, do we accuse them of fundamentalism and point them to the importance of habits we have around smoking culture? I don't see much difference between these questions and the resistance of change there is against agile transformations.

    Suppose there is something true in the agile ideology. Then by not applying it correctly and diminishing the meaning of its statements (were they put in there accidentally?) we just blur the ideas and set the whole purpose of agile at stake. A bit similarly to the blogger's bottom line we can ask: why do it at all if we don't believe in it? You can always make a long list of factual hindrances there are for agile transformations, but similarly you can always find a million reasons for any change not to happen.

    Pawel Brodzinski

    While I agree with most of your points I strongly disagree with that one:
    "Picking what parts of Scrum or XP are appealing to the PM, Scrum Master, or product owner, and ignoring the rest or superimposing waterfall as related above. Disaster often lurks right around the corner."

    Actually picking what parts of Scrum/XP/any other nice methodology suits your process fine and applying only those parts is wise. If one of my projects would benefit from stand-ups why not to start them even if we don't keep 2-week iterations? If I find alue in short iterations while I don't have designated scrum master what keeps me from implementing it?

    My goal isn't to be agile or have pure-agile processes in software development. My goal is to improve my processes. You can always do it as they do it in the books - 100% implementation of some methodology - and it should work. Unfortunately it's quite an effort to go this way. On the other hand you can choose wisely different techniques from different methodologies and craft your own software development and project management process. Sure, I won't call it agile but as far as I can call it good I don't care.

    You can find more about my approach here:

    The comments to this entry are closed.