« Mike Griffiths Receives “PMI-SAC Fellow” Award | Main | Agile Horrors »

November 25, 2013


Your comment "many IT projects are not defined, repeatable endeavors, but instead design explorations into uncharted territory for that organization" in my opinion is only slightly wrong in that it starts with "many". Too many projects unnecessarily are made in to explorations for the sake of using technology in new ways. Where we need to innovate (and by that I mean business innovation - new products and services for the company; then yes, an agile approach is often / always(?) beneficial. But for other projects, why take the risk? Simple, known technology that works allows IT to focus on developing and IMPLEMENTING business logic in a risk averse way. Sure, things can change, but we can manage that. The need for constant reprioritization should be less if you are not innovating (as I define it above). Now reality may dictate that an enterprise does not want to do a lot of big up front planning, and wants to start building and realizing value soon. Great - do it the agile way. But too much change for non-innovation projects may just mean you were not properly prepared. Agile does not mean no up front planning.

Mike, you've described two end points on a continuum. Most software development projects need an approach somewhere in between. More importantly, most software development projects are actually part of something larger - a program, or a portfolio of capital investments. Failing to take those related activities into account is a far more common source of problems than simply accommodating changes to functional or technical requirements. I'd like to hear your thoughts on how we can accommodate these external influences in our project planning.

Hi Andy,

Thanks for your comment, you raise a good point, many projects don’t exhibit the “uncharted territory” so why use agile, and why risk a change to agile? This is true, a whole chunk of projects do not need the exploratory nature of agile methods and could be run just fine with traditional, plan driven processes. I have chosen not to work in that space, instead I work on custom application development for new and difficult to solve problems. I see many such projects a year and since I have been doing this now for 20 years, when I work on a more traditional project I still tend to use agile elements. I just prefer the increased collaboration, fast feedback cycles, smaller batch sizes, etc.

To me, using an agile approach is not adding new process or risk, but you raise a great point. Any change from the norm brings new risk. Adopting agile for the first time when your project does not need it is adding unnecessary risk of failure that needs to be carefully considered. Why are we introducing change? What improvements are we hoping to gain? How will we checkpoint and evaluate its effectiveness?

Hi Dave
Thanks for your comment and since you also bring up my seeming bipolar view of the world, I certainly accept I must have conveyed that. Yes, for ease of contrast I painted black and white views of the world when in fact we live with shades of grey. I think all projects are points on a spectrum and beyond the agile one I described are some like one I am working on right now that uses concurrent set based development and does A vs B sessions with the users. This is even more extreme but only the second time I have been asked to do it so I assume not that common.
Jim Highsmith talks about a “methodology per project” meaning since each project is different then so should its approach be. I like this recommendation and think process should be situationally specific. Anyway, you asked about integrating projects into a program and portfolio. Some great frameworks for this include the Scaled Agile Framework that describes how traditional and agile projects can be effectively managed together at a program and portfolio level. See http://bit.ly/IG1co6 the there is Disciplined Agile Delivery (DAD) that also does this along with providing a robust framework for hybrid approaches. I think both are useful references for creating frameworks for project execution.


The comments to this entry are closed.

AddThis Social Bookmark Button

Your email address:

Powered by FeedBlitz


  • Google Analytics
Blog powered by Typepad
Member since 07/2006

November 2016

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30