• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.



Page history last edited by PBworks 14 years, 5 months ago

Agile Success Factors



This page lists factors critical to the success of Agile at a client.


The discussion of Team Success Factors has been moved to TeamSuccessfactors.


Factors for Success of Agile at a client:


Note: Which of these are symptoms and which are underlying factors??


  • Most Agile projects are viewed as successful


    • Assume there are two or more major "programs" at the client. Does this mean that the agile projects related to those programs must all succeed?
    • Is project success viewed as 'delivered the functionality close to "expected date" and close to or on budget' ?
      • as opposed to "delivered the customer's most important features to production quickly and with high quality" which I'd consider a more suitable Agile goal.


  • Most teams are happier with Agile (prefer Agile to waterfall)


  • Most product owners are happy with Agile


  • A good cadre of internal SMs


  • The coming backlash (who has that crystal ball when I need it?) by the "waterfall people" is not successful


  • Continuing success in overcoming (improving on) larger blocks


  • Continued improvement in Time To Market


  • Visibility to the business side that better ROI is being achieved


  • Continued movement toward "better agile"


    • "Better agile" might also be called "purer agile", except that some would argue that pure agile does not exist.


  • Agile is viewed as less risky than waterfall
    • eg, somewhat less documentation is not viewed as riskier
    • doing Agile inside a waterfall organization is not viewed as problematic - whereas it's actually quite risky
      • selling Agile in such an environment is a big task in itself, and necessary to get understanding and collaboration of colleagues outside the Agile team. This overhead can reduce the return normally expected of Agile.
      • dependencies on teams still working in muda-time can be crazy-making - failed dependencies reflect on the Agile team despite originating outside.
      • Agile shows up other groups' muda, making it unpopular and a target to be thwarted or shut down.




  • Who did the very last sub-bullet? I am thinking there may be several thoughts in that item -- that might be better expressed as multiple bullets. Certainly I would like to understand better what you meant. -- Joe
    • maybe it was me... I can't recall which page I was editing when the wiki crashed my browser yesterday. Anyway, I can elaborate on that one --deb




Comments (0)

You don't have permission to comment on this page.