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

  • Whenever you search in PBworks, Dokkio Sidebar (from the makers of PBworks) will run the same search in your Drive, Dropbox, OneDrive, Gmail, and Slack. Now you can find what you're looking for wherever it lives. Try Dokkio Sidebar for free.

View
 

AgileSuccessfactors

Page history last edited by PBworks 16 years, 7 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.

 

Comments

 

  • 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.