Group items tagged

In a truly WIP limited process impediment removal is paramount.

So for those who would claim that Scrum and XP limit WIP and pull new work, such as Stephan Schmidt, I would point them to the feature sets of existing Agile tools. These tools do not impliment WIP limits, pull signalling nor are they particularly good at issue management and resolution. Recently, there are 4 new entrants to the Agile tools market. All of them producing WIP limiting Kanban tools including the same Mr. Schmidt. If earlier Agile methods had been truly WIP limited pull methods then tools from encumbent vendors would already reflect this. As a result there would be no market for new entrants such as CodeMonkeyism, AgileZen, LeanKit and RadTrack. More thoughts on managing WIP versus limiting WIP tomorrow... T

Lesson 3:  Actual progress is infinitely more important than planned progress.

Lesson 4:  Calculate your velocity and use that to plan for the future.

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.