Forensics of a Technical Project with Agile Solutions

Great blog post from Knowledge BLOG:  “What’s wrong with the project approach to software development?” It got me thinking and comparing project management vs. Agile practices.


Projects are work defined as activities and tasks. There’s a start and an identified end.

OK – but factor in complexity, time to do it, size of the team and available (estimated) budget and the wheels come off.

  • Project stalls or overruns.
  • Agile methods fix this (Strategy Meeting).

ProjMgt Best Practice

Do not begin a project until all goals are well defined and agreed upon. Seriously, who has a crystal ball to share? Let’s break this thing up.

  • Success measures, length of time for “agreed upon?”  – further out, the less agreement.
  • Agile methods fix this (Release Planning, Iteration Planning, Iteration Review).

Scope Creep

In a recent straw poll, 40% of product professionals selected “Managing scope /requirements change” as the most important topic for their career. Seems serious…

  • Agile methods fix this (Iteration Review, Daily Stand-up, Continuous Adaptive Planning).

Managing Expectations Both Sides of the Aisle

Clear communication between development teams and the business suits (I’m a suit), big #FAIL!

  • Mention: Culture clash between “stakeholders’ involvement” and “productive collaboration to build product.”
  • Agile methods fix this (Product Owner, Scrum Team).

Continuity, Lessons Learned

Projects are temporary in nature. Teams who work projects are assigned and then reassigned as the projects live/die.

  • What about continuity, flow, innovation? I think missing.  You lose what you’ve learned.
  • Agile methods fix this (Scrum Team, Retrospective Meeting).

Knock It Out

Why are the honest endeavours of software developers often so disconnected from the delivery of customer and stakeholder value?” –  pg_rule, Knowledge BLOG, January 11, 2011.

I think it’s about covered – using any Agile method provides the foundation for collaboration between product visionaries (sometimes suits), development teams and stakeholders to build products that customers want and buy.

6 Replies to “Forensics of a Technical Project with Agile Solutions”

  1. I’ll add in one other item, of which Grant Rule and others have espoused: Thinking in terms of Project Management is *dangerous*, as by definition, a project has a predefined end.

    What is developed is a product… It lives on. When the product, such as a software product, has complexity, it needs a responsible party to handle it until its need goes away. This should ideally be the same party as the original creators. Project thinking often causes a hand-off between those that initially developed the product and those that have to maintain the product. This reduces understanding about the product and the need it is trying to solve as well as how it solves the need specifically. Having a defined project end changes the mentality of all stakeholders, both external and internal.

    The best intention by a project manager can do little if the outside management stakeholder want to change the team when the product goes live. Or if developers don’t think the project will be interesting any longer since it is now to just be maintained. Or sacrificing quality over features to meet the arbitrary project end date or stay within an funding profile.

    With that said, projects aren’t going away anytime soon. What I personally have found lacking is a set of values and principles aligned with Agile thinking totally focused on projects of any kind. I created the Manifesto for Project Leadership as a response. It also contains a preamble about the danger of project thinking. You can find it at – and I welcome constructive critique and contributors.


  2. Paul, great manifesto…seems very aligned with Agile practices. I especially agree with this point:

    “Interacting in Person [My add: or video] over using communications that limit interactions”

    So much can go wrong with asynchronous communications like email. It’s the discourse within the group that brings the understanding.

    Let’s keep the discussion going, Karol

    1. Thanks, I thought pretty hard on it, but it actually came to very quickly after reading Leading Lean Software Development by the Poppendiecks. As you can tell some discussions have already shaped it.

      My goal with it is not to say things like the PMBOK are not useful, but to apply some value/principled-based framework and discourse on when and what tools should be used.


    2. Oh, btw, do you find video really that great? I find it still very limiting… (in terms of body language and such)

    1. It’s always about people, until the robots take over the world.

      posted link to Google+
      many of us are recovering proj mgrs
      hoping to hear from all sides.
      This can be a fun discussion 🙂

      Thanks Peter, as always.


Leave a Reply