Scaling for large projects
My large company is in the process of switching to Agile. Let's say that we do that and we have 20 Agile teams in my department, all happily running along with their sprints and backlogs and that things are working pretty well.
Then, all of a sudden, the business decides to do a big new project. Let's say that they want to completely revamp one of our main product lines and 18 of the 20 Agile teams will have work to do. Some of them will have more work than what they can possibly do. And the business doesn't want to alter the backlog of any of the 20 teams...they want all of the previously committed projects to still get done on schedule (this occurs all of the time with us today. They are always adding new projects without altering the committment on existing projects).
They give us a few million dollars and tell us to add more Agile teams, or expand the teams we already have or do whatever it is that we need to do in order to accomlish this. We figure that we'll have to add between 1 to 10 people to each of the affected 18 Agile teams. For the teams that are getting 10 new people, we'll need to split them up into 2 Agile teams. Some of the Agile teams will need to go beyond the recommended 7 to 9 people and end up with 10-12 people while we work on this. We determine that we'll end up with 26 Agile teams for the duration of this initiative. Then, when the initiative is over and the money runs out we'll go back to 20 teams and we'll lose all of the new resources that we added as well as the knowledge that they accumulated.
Is this the way handling big projects is supposed to work with Agile? If not, what's the better approach?
I'm asking this question because today in a waterfall mode, this is how our company works today. About 50% of our team is funded by a few large projects every year and so we are constantly expanding teams, completing projects and then letting large numbers of people go, only to add a new set of people a few months later for other initiatives. We make this churn work, although it's obviously inefficient. I'm worred that it will be worse with Agile and I'm wondering if there is a better way of dealing with this.
Hello,
Did you looked this? http://www.scaledagileframework.com/
It's a framework designed to scaled agile in big teams.
Best reggards
Hi Gary,
Did you have a look at the blog post by Ravi Verma?
https://www.scrum.org/resources/blog/im-not-calling-your-baby-ugly-two-…;
Thankyou so much friend
> And the business doesn't want to alter the backlog of any of the 20 teams...
> they want all of the previously committed projects to still get done
> on schedule (this occurs all of the time with us today. They are always
> adding new projects without altering the committment on existing projects).
Who made those commitments and why? In Scrum it would be reasonable for a Development Team to commit to a Sprint Goal. Moreover, backlogs would be continually inspected and adapted on the basis of empirical evidence.
My advice in this case is not to scale at all. Don't do it using any framework, or at least not yet. If agile practices cannot be implemented well in the small, there is very little chance of a successful agile implementation in the large.