Skip to main content

Home/ Agilesparks/ Group items tagged failure

Rss Feed Group items tagged

Elad Amit

The Failure of Failure - Michael Schrage - Harvard Business Review - 0 views

  •  
    Adding fail partially to fail early, fail often, fail cheaply...
Yuval Yeret

InfoQ: Opinion: Agile Coaches Frequently a Source of Adoption Problems - 0 views

  • Coaches help teams learn Agile practices get from 'Agile seems to be something we should do' to 'we are practicing Agile development and succeeding by regularly delivering business value'.
  • ncreasingly there are reports of initial success followed by failures with Agile adoption.
  • I believe that there is a problem to how current Agile coaches - especially external ones (such as the author) - have traditionally performed their jobs. In fact, I think we are part of the problem
  • ...2 more annotations...
  • We do a very good job - in general - teaching the skills. That is, teaching the team to run an iteration with a kickoff, demo and retrospective. Teaching test driven development. Some of us even do a very good job teaching the team to be pseudo-self-organizing by taking a socratic approach to coaching and standing back and letting the teams make their own mistakes and learn from them.
  • We even do a good job - in many ways - teaching the team the values of Agile development. If we are there long enough, the values come from diligent and disciplined application of the practices.
Yuval Yeret

Agile Product Manager in the Enterprise (5): Responsibility 3 - Maintain the ... - 0 views

  • The Roadmap consists of a series of planned release dates, each of which has a theme and a prioritized feature set.
  • While it is a simple thing mechanically to represent the Roadmap, figuring out the content for anything beyond the next release is another matter entirely. The topic of what else the team plans to ship and when can be a fascinating and contentious topic in agile
  • the easiest way to think about the Roadmap is that it is an output, rather than an input to the Release Planning process.
  • ...5 more annotations...
  • The dates and themes for the next release are fixed. The features are prioritized and variable.
  • The teams can commit only to the features in the next upcoming release. Releases beyond the next, represent only a best estimate.
  • The Roadmap, then, is a “plan of intent” and is subject to change as development facts, business context and customer needs change. With respect to the upcoming release, perhaps the most important guidance is this:
  • Even though the team has committed to the objectives and we have agreed that the feature set cannot be guaranteed, it is a reasonable expectation that the agile teams will: 1) meet the date 2) accomplish the theme 3) deliver most of the features, and certainly the highest priority ones, with the requisite quality.
  • Anything less would be unprofessional and belie the power, discipline and accountability of our agile enterprise model. Moreover, it will eventually threaten our own empowerment, as failure to deliver will inevitably cause the implementation of various controls to “help us”!
Yuval Yeret

Challenging Why (not if) Scrum Fails | NetObjectives - 0 views

  • I do believe for Scrum to work beyond the team you need more than Scrum
  • what to add to Scrum making it more effective when it won't readily work
  • lack of team agility is not always the major impediment to Enterprise Agility
  • ...12 more annotations...
  • While starting at the team level with Scrum is often good, you often need to start with the product management team - that is, where product enhancements to be worked on are selected
  • Even when Scrum works at the team level, organizations very often report little impact to the bottom line.  While this is better than nothing (if the teams are happier, that's good), it usually doesn't justify a huge investment
  • in many contexts in which Scrum does not work readily, Scrum has no power to improve the context in which it is in.  In other words, the impediments that one must fix are often outside of the scope of what Scrum helps you do.
  • These impediments are often not even seen or if they are, are often viewed as "just the way it is."
  • certain Scrum attitudes often makes things worse
  • Scrum does little to let management to know how the team works or what impact management decisions have on the team
  • There is almost a religious zeal that Scrum tells you little of what to do
  • While SoS works well for certain types of work, it does not work well when the different teams have different motivations. 
  • the high failure rate is due to the fact that Scrum works in certain contexts but has little ability to change the contexts in which it doesn't work wel
  • One needs to pay attention to where to start as well as see how to change the context.  Separating the team from management doesn't help.  Focusing on only the team part of the value stream - giving little guidance both up and downstream of the team also doesn't help.  Lean provides guidance here (meaning Scrum with the aid of Lean could provide insights),
  • look into using Lean as a context for any improvement in your software development organization
  • While Scrum may be an appropriate choice in many circumstances, other methods may be better (e.g., Kanban Software Development).  Scrum's rapid ascension probably has more to do with its success in the places it easily fits.  Now that it is past the early adopter phase, we may see it having even a harder time as people attempt to scale it.
Yuval Yeret

Why agile transitions initiatives might fail : Jeffrey Palermo (.com) - 1 views

  • The executive makes a “vendor” or external “coach” responsible for the transition If you have handled the first risk and have defined success and success metrics, you likely will not find a vendor who will base his payment on your metrics.  After all, the metrics likely call for less project failure rate, faster response times, etc.  You probably can’t measure these things in less than a year if you really want objective metrics and not one optimized for short-term results at the expense of the longer term.  A vendor might want: # of people trained % of teams using an “agile” project management tool # of teams with an embedded “agile champion” # of successful iterations It is really easy to accomplish the above metrics and still not make any material change in the organization.  I have worked with a client that did something similar to the above.  Most of the teams starting using some new Scrummy project management web application for project tracking.  They declared that monthly status meetings were now iterations.  They declared a member of the team to be the Scrummaster (and sent that person to training).  Overall, the same organizational problems persisted.  Vendors cannot produce real change in an organization unless the organizations executive leadership alters the culture in a meaningful way.
1 - 8 of 8
Showing 20 items per page