Scrum on Large Projects with External Players
I used scrum at my last company, and for about the past year with my current employer. I also have a lot of experience (20+ years) with various Waterfall methodologies in both commercial and government projects. One issue I still seem to have with Scrum is regarding dependencies in doing systems development. Systems development involves not just writing a piece of software, but designing and deploying the hardware and networking infrastructure to deploy a full system. This may involve dealing with multiple colocated sites serving as primary and backup (disaster recovery) sites as well as deploying other environments such as testing and staging environments. There are a lot of "stories" that are associated with designing, procuring, and deploying such a system. My understanding of scrum says that there should be no project plan, or planning of tasks and dependencies. To be honest, I can't see how to plan out such a project without identifying the major tasks and their dependencies (ala a Gantt chart.) This seems to be a problem especially when those responsible for performing some of the tasks in such a system development project are not working for my company, but work for one or more other companies which are not on our Scrum team and likely do not even use Scrum. The logical answer is that we can use Scrum for the stories/tasks for which my company is responsible...true. However, some of the stories that we have to complete are dependent on some of these other tasks that these other companies have to complete.
It seems to me that as a team, we have to be able to track and visualize those external tasks upon which we are dependent and understand how and when they will be completed in order to accurately plan our product/sprint backlog. How do we account for such complexities in a project when scrum seems so inwardly focused on individual features and simply lining them up in a sprint backlog, and does not seem to account for cross team dependencies on larger projects...or perhaps I'm just missing something.
It's perfectly reasonable to plan out multi-team dependencies so that they can be minimized, and so that the release of business value can be achieved at the lowest risk. Planning can be at task, user story, or any other level and it may involve teams from different organizations. Indeed this collaboration is to be encouraged.
The important thing in agile practice is for the release of value to be frequent and incremental, and subject to inspection and adaptation by those doing the work. This means having business sponsors who can articulate that value in incremental terms through their own representatives on the teams. They must also be able to make use of deliverables that are completed iteratively every few weeks, and provide relevant and timely feedback. Do you have that kind of sponsorship for incremental delivery in place?
Yes, we do. While the various participating organizations (and customer) do not use Scrum per say, they are supportive and like the fact that incremental enhancements can be shown.
Incremental delivery is the best single thing you can do to manage project complexity. Delivery risks around inter-team dependencies are then effectively timeboxed.
Each participating team must engage in joint Sprint Planning so a fully integrated potentially releasable increment can be delivered. Replanning may be necessary during each Sprint...holding a regular Scrum of Scrums may help.
Did you already have a look at the Agile Project management manual by DSDM? This will fill in some of the gaps you describe as the method does make use of delivery and deployment plans and describes more roles and responsibilities. It also makes it possible to combine scrum teams with non scrum teams.
Thanks, I will look into this. This sounds like it addresses a lot of the problems I am experiencing. I am also looking into Disciplined Agile Delivery (DAD).