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

View
 

AgileSuccessfactors

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.

 

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.