19 September 2008

Agile projects and the project context

More discussions about the suitability of agile approaches to projects.

My investigations and experience suggest a stable environment doens't so much need to approach projects with an adaptive method. One the other hand, when your project s operating in a dynamic environment, being adaptive seems sensible. Especially when there is a time to market pressure.

One of the significant differences between effectie agile organsiations and tradtional ones is the orientation to process or product management. In fact - nce you start looking at an agile approach to portfolio management the development strategy even moves away from projectised work.

This seems to me to be strongly related to the concepts of SOA and enterprise architecture. With these models in palce a lot of analysis is done for you. It is much easier to know what and how to build.

Comments welcomed!


  1. Could you expand on this statement? I'm not sure I fully understand the implications you are pointing at.

    "Once you start looking at an agile approach to portfolio management the development strategy even moves away from projectised work."

    Josh Nankivel

  2. Josh,

    Imagine you work somewhere that has a technical landscape that is all modern and SOA type flexible.

    At this point the business doens need new systems, it needs new features.

    So now you have an enterprise backlog rather than a product one.

    And that backlog, or work request queue will never die.

    So instead of addresing work in projects, tech team simply take the next most important feature in the list and get to work.

    Uncertainty, risk and so on fade right away. Reliability, cost certainty, etc are amplified.

    Projects will remain, but will be less about IT and more about transforamtion in the organsiation; business models, new customer offerrings, process re-engineering and organsaitional restructures.

    Try checking out this website for more on the idea.

  3. Craig,
    I agree with one axis Planned v. Adaptive. But I'd like to see the evidence - rather than ancedote - on the other.
    I work in environments where change is part of the product development process. Underly architecure, seperation of concerns, coupling and cohesion all provide a platform for changing the direction of the project.
    Being adaptive seems sensable - as you say. But what are the units of measure of adaptive. I can see the units for Planned, Stable and Changing.
    This is the age old question.

  4. I think I see what you are saying. Tell me if my related experience below is what you are getting at.

    A few years back I spoke with someone who worked in an organization where the projects utilized IT and development as a service. Requirements, ROI, and all the other necessities were done in the projects, then they fed these into the technology group.

    In the scenario you describe, it would be features fed into the technology group instead of sets of features in a defined project.

    What are the implications for communication amongst all the stakeholders of a feature? Does the idea of a sprint go away, replaced by a feature life cycle?

    Josh Nankivel

  5. Glenn,

    This is a question that is perplexing me.

    I have asked around on the agfile forums and no-one has yet pointed me to any proper studies that show scrum/xp etc are better than any other model.

    The surveys that do show up are obviously biased and you can't really use them as a comparison.

    I'll continue to sniff around until I am conviced one way or another. My current position is taht good people can leverage any process, and experience counts.

    (So many iterations helps because it gives you lots of full lifecycle experience.)

    At the end of the day we all agree with the principles in the agile manifiesto (ie do what's best for your customer.)

    Now - to your comment on the planned-adaptive axis. You've made me re-assess it.

    You, Josh, me and about 16 other people in the world all know that planned does not mean you are not adaptive.

    Change control does not mean change resistance.

    So, planned and adaptive are not opposites.

    So my model is wrong.

    It should be stubborn v adaptive.

    And in that light, maybe the other axis shuld be planned and not planned. Let's see what that looks like...

  6. Josh - that's the model.

    It's very similar to what happens when systems mnagers get all their stakehodlers to come together for a monthly release planning session.

    Everything gets prioritised according to importance and what fits makes the next release.

    What doens't waits until the next turn.