BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon New York

Find real-world practical inspiration from the world’s most innovative software leaders. Attend in-person.
QCon San Francisco

Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or get video-only pass to recordings.
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News Opinion: Agile Adoption is Distinct from Agile Practices

QCon San Francisco (Oct 2-6): Learn what's next from software leaders pushing the boundaries.

Opinion: Agile Adoption is Distinct from Agile Practices

This item in japanese

Bookmarks

Feb 19, 2008 2 min read

Write for InfoQ

Join a community of experts. Increase your visibility.
Grow your career.Learn more

Using Agile practices effectively is not as easy as knowing what Agile practices are.  To use test driven development effectively is different than knowing that you should follow the red-green-refactor loop.  How does one get from: Agile seems like a good idea, to: We have used Agile practices to significantly improve the value we deliver to our organization?

Success stories abound in the literature of Agile, but so do failures - there is no silver bullet.  So whether you can follow another team's example is based on context - is your context the same?  If not, then you probably won't get the same benefits. 

To start things off, Carel Lotz reports his organization's difficulties in getting real value from adopting Scrum:

I'm currently part of a team that needs to re-define our company's SDLC methodology.  I'm all for using a more agile SDLC (Scrum, Open UP etc.) as the current SDLC methodology is based on a Waterfall model of software development.  In the past 2 years, a few projects have attempted to use a more Agile SDLC, but they either failed miserably in their attempt or only succeeded in implementing some of the technical aspects of agile development like Continuous Integration (CI) and Test Driven Development (TDD).

What is really interesting, is his analysis (hindsight is 20/20) on why these failures probably occurred:

I read an interesting article on InfoQ this morning that highlights one of the primary reasons why the transitioning to Agile has not yet been successful in our environment. [this is a reference to last week's personal agility article on InfoQ]

We currently don't have enough of these key individuals who actually understand and have adopted the correct agile mindset (i.e. not Scrummerfall).  The result - without enough correct guidance and a strong believe in the benefits of agile development, a team quickly becomes disillusioned and reverts to the "known" waters of a Waterfall approach.

Over the next several months I will report exclusively on issues of Agile adoption.  The promised benefits are great, and the pitfalls are plentiful - tune in to InfoQ's Agile Queue on Tuesday for a weekly update on how people are adopting and adapting Agile practices!

If you think the focus on adoption has merit, then please let us know what you think here and send us emails about your thoughts, interesting blogs, and useful news that pertains to this topic. 

Rate this Article

Adoption
Style

This content is in the Agile topic

Related Topics:

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Re: Agile Adoption

    by Dave Rooney,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Has anyone ever written about how virtually all organizations that have attempted to adopt the 'waterfall' model have failed to do so properly (at least according to how Royce defined it)?

    How about the multitude of failures of implementing the RUP? RAD? (Insert acronym or buzzword here)?

    Perhaps the focus shouldn't be on failures of adopting Agile, but rather failure of adopting any process. If an organization has been struggling in their software development efforts using other processes, why would anyone think that they would be successful at adopting a method that requires more discipline, interaction and transparency?

    Dave Rooney
    Mayford Technologies

    Back to top
  • Re: Agile Adoption

    by Amr Elssamadisy,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    Perhaps the focus shouldn't be on failures of adopting Agile, but rather failure of adopting any process.


    I believe that you mistook my intention Dave. I will be focusing on all of Agile adoption - both successes and failures. It just happens that my first example was a negative one. I'll try for a positive story next time :)

    Now, if it turns out that Agile has nothing to do with success and failure of change - that would be very noteworthy.

    Amr Elssamadisy
    Gemba Systems

    Back to top
  • Agile Adoption is Distinct from Agile ENGINEERING Practices

    by Deborah (Hartmann) Preuss,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I do think that the discipline of Agile Adoption Practices is emerging. It's just different than the better-established Agile Engineering Practices.

    Imo, Agile Adoption Practices includes things like: retrospectives to set the stage for change, coaching and mentoring to help with the stress of change, and transparent dissemination of development metrics (rolled up to a meaningful level) to build communication with the organization.

    Back to top
  • Re: Agile Adoption is Distinct from Agile ENGINEERING Practices

    by Amr Elssamadisy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I respectfully disagree....

    Adopting Retrospectives, Iterations, Demos and getting value from them is distinct from what a Retrospective is.

    For example, we can read "Agile Retrospectives" and know the toolset that can be used to perform a retrospective.

    But what about actually practicing it and getting real value from a retrospective? How do you know you are getting it right? What does it look like when a retrospective goes wrong? When are you just 'going through the motions'?

    These set of questions are valid for all practices - technical and people practices.

    Back to top
  • Re: Agile Adoption is Distinct from Agile ENGINEERING Practices

    by Deborah (Hartmann) Preuss,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Ah, we are talking apples and oranges, perhaps.

    I am thinking of a retrospective run by (whoever is leading adoption), and run well, at the beginning of an adoption effort. It serves to help the broader team understand "where are we now" and "where do we want to go," to provide perspective and motivation to (hopefully) "pull" change from the team, rather than "pushing" it on them.

    Retrospectives for iterations are of smaller granularity and I'd agree they are a team practice. But what I'm talking about is a change-agent practice directly related to making an adoption successful.

    Back to top

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT