Jayson ReadProject ManagerEden Prairie, Mn, United States
In an IT organization that is structured to align with business modes and functions by silos; each silo with its own set of IT roles (PM's, BA's, Dev's, and QA's) how would Agile work on projects that span these siloed teams?
When it comes to sprints and sprint planning, how do these dependencies get called out and planned for? Do other product owners attend those planning sessions? Do you have to implement a scrum of scrums? Any thoughts and feedback would be appreciated! Saving Changes...
Sort By:
Russell GeakeProject Management Consultant| Deciduous Partners LtdLostwithiel, Cornwall, United Kingdom
set up a project and priorities meeting, and a method of tracking/recording these. Depending on the size, and shape of your organisation (single site, remote workers) This will help understand the pressures and conflicts that may be arising and impacting the individual projects. By setting the priorities, the organisation will understand how siloes must work together to maintain progress.
Scrum of scrums is a nice term for it - use it and set up a weekly or fortnightly SoS.
Saving Changes...
Josh NankivelEngineering Project Manager| AppleSioux Falls, Sd, United States
My $ .02. I am assuming this is a rather large project, with 50-100 staff comparable to projects I've managed before.
1) For the duration of this project, structure the teams by functional specialty. Silos will kill you. I'm talking about a UI team, database team, processing (or whatever makes sense for your type of software systems), systems architecture/workflow, etc. Teams have lead developers or systems engineers, but there's 1 PM. QA/test is a single team. This increases team cohesion as you've got people who are good at/interested in a particular aspect of development together sharing knowledge. There is no 'throw it over the wall' - only work together to make my UI interface with your control system, etc.
2) Build interfaces first, build everything with automated unit and integration testing from the beginning. Automated build & test either with scripted daily builds or automated builds triggered by check on your code repository. (find interface issues and bugs immediately) Make sure you have a software architect and software configuration manager who know what the hell they are doing.
3) For delivery mechanism, go with Lean - Kanban. There are many software tools available like LeanKitKanban for tracking multiple teams and this kind of visual system makes it really easy to see where the bottlenecks and dependencies are.
4) Product owners / key stakeholders have a regular priorities session, they all work off the same shared backlog. There is only 1 backlog for the project. If you are doing Kanban, sprint planning goes away. When someone wants something done because it's an 'emergency' they either have to wait until the next product owner tag-up or negotiate with another product owner. It's all one one board so you just walk up to it and talk about it.
