[trhway]

after a year and half of thorough, to the letter, BigCo company-wide (only super important/critical projects were excepted :) push of Scrum/Agile/Lean down our throats and as result, in particular, work on our complex multi-team project slowing down to a crawl and failing to release while everybody was super busy with their mouths foaming and not being able to catch a breath, about a year ago everybody in our BigCo almost instantly forgot these words and about associated reports/tools/meetings/bla-bla-bla - Christmas magic i guess. The only thing reminding that it wasn't just a nightmare dream, that it was real is that our team's weekly status meeting is called "scrum meeting" :)

Beside other failures, one of a major failures of scrum in real environment (not toy building fun exercise during a scrum course) is failure to address the multi-team environment of real multi-layered projects. A team would usually have dependencies and dependents. In scrum/sprint process a team would try to avoid committing to anything with unsatisfied dependencies which results in that any vertically dependent feature would take a series of sprints, much longer than in non-scrum environment. Add to that complete impossibility of iterations/adjustments on the feature - team A delivers to team B and team B has no chance (until a sprint much much later in the release, i.e. never) to have team A to do an additional iteration upon the delivered changes desired as a result of the actual usage by the team B. It is expectably much worse when it comes to 3 layers/teams (like persistence/framework, business logic, UI).

I specifically asked consultants (during 2 different courses by 2 different consulting companies and at work) about dependencies management in scrum, and blank-facing was their answer. Think about it - software development methodology without addressing inter-component/layer/team dependencies.