19 September 2008

Agile projects and the project context

Posted by
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!
Labels:

6 comments:

  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
    pmStudent.com
    ReplyDelete
  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.
    ReplyDelete
  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.
    ReplyDelete
  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
    pmStudent.com
    ReplyDelete
  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...
    ReplyDelete
  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.
    ReplyDelete

Subscribe to: Post Comments (Atom)

Popular Posts

  • What is Project Scope? What should it be?
    I have been having a bit of a discussion over at the IIBA blog with Kevin (VP BOK) and Julian (Chief architect.) It’s migrated over to ...
  • User Story Template
    Due to popular demand I have aggregated some information on User Stories and created a simple template.  If you feel this would be useful to...
  • Change Request template
    Better Projects Templates I am uploading a couple of project document templates to Google Docs. As I add more I'll post them up here. You...
  • BCS forum on "Making Projects Work"
    You've heard many reasons why project fail.  Here is a discussion hosted by BCS on why projects work. The discussion covers four dimensio...
  • PDMs - Precedence Diagram Method
    The Precedence Diagramming Method ( PDM ) was developed in the early 1960s by H.B. Zachry in cooperation with IBM. It has largely repla...
  • Snowbird; Agile 2011 discussion on the BA
    In the below video some of the #10yrsagile participants discuss the role of the Business Analyst. A question for you; Do you agree or di...
  • Email, Whiteboards and Well-Caffeinated Wits
    This is a guest post by Jeff Hobbs.  Jeff is a project manager at ActiveState Software who provide pm and collaboration software. Email, ...
  • 7 Requirements Analysis techniques
    In one of the Carnivals of Business Analysts the theme was “ Requirements Analysis ." I searched the web far and wide and came up with a n...
  • An Introduction to Stakeholder Management
    The definition of a stakeholder is controversial. For example, project team members are generally not considered stakeholders, but in virtua...
  • The V-Model: Table of Contents
    I have written about the V-Model across several posts. The V model is a testing focused expansion of the software development lifecycle. In ...