There are many projects which are Agile in name but chaos in reality #HoskWisdom
The Agile framework is like a person with a hammer, all problems look like nails and all projects look like Agile projects #HoskWisdom
Agile/Scrum used on large/enterprise projects with multiple Scrum teams, scaled Agile increases the complexity of a project and if not managed, adding more people can slow projects because there is a cost to adding more people to a project and increasing complexity.
Many agile project require an increase in velocity to meet an earlier completion date, the common method is to add more people to the project.
Adding manpower to a late software project makes it later. Fred BrooksThe bearing of a child takes nine months, no matter how many women are assigned. Fred Brooks
Adding more resources (usually developers) to a project would seem sensible. If one team have a velocity of 25 story points Sprint (Story points gets internally translated to days by 91 percent of the population #HoskWisdom). So if there are 4 teams a velocity of 100 story points per sprint.
The reality is teams and individuals don’t start delivering 100 percent instantly because there are other factors to consider.
Increasing people on a project increases complexity of working, collaborating and communicating #HoskWisdom
These other factors have been explained by Brooks Law
Brooks Law
Brooks points to the main factors that explain why it works this way:
- It takes some time for the people added to a project to become productive. Brooks calls this the “ramp up” time. Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully. Each new worker also needs to integrate with a team composed of several engineers who must educate the new worker in their area of expertise in the code base, day by day. In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even make negative contributions, for example, if they introduce bugs that move the project further from completion.
- Communication overheads increase as the number of people increases. Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people.[3]Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing.
- Limited divisibility of tasks. Adding more people to a highly divisible task such as reaping a field by hand decreases the overall task duration (up to the point where additional workers get in each other’s way). Some tasks are less divisible; Brooks points out that while it takes one woman nine months to make one baby, “nine women can’t make a baby in one month”.
- Business logic
- Project processes
- Best resources for situations
- Project politics
- Collaborate with others
A scrum team takes 2 sprints to get up to speed, usually 50% efficiency for sprint 1 and 60/70% in Sprint 2. When you add the added overhead of trying to collaborate with other teams this can slow new teams further and slow existing teams.
Deadlines are the common cause of adding more people to a project which adds more pressure to the project and the newly arriving people.
A big overhead is integrating the work from multiple teams into one solution, even with continuous integration there will be problems when bringing solutions together
Sutherland one of the creators of Scrum mentions scaling in this article
InfoQ: Now that more and more larger organizations are using Scrum, the need for scaling increases. Can you give some suggestions how organizations can scale Scrum?
Sutherland: Scrum is designed to grow like a biological system. To create a baby, you need one good cell that replicates. If this cell is bad you have a lot of problems. So the challenge is to first get a single team successful to use as a model for other teams, then replicate it. As you grow, Scrum as large follows the same basic principles as Scrum in the small. If it doesn’t you have introduced waste into the system. You will build out organ systems, just as in the human body that have some specialization and need some training on how to handle cross team coordination, elevating impediments all the way to senior management, avoiding the introduction of unnecessary teams that can compromise performance, and scrumming the entire organization.
We have published several papers showing that a properly scaled Scrum can provide linear increases in global velocity, something never seen before in software development. However, you need to do Scrum really well to make this happen.
Hosk thoughts on scaling agile projects
The first rule of large agile projects is not to do large agile projects #HoskWisdom
Large Agile or Scrum projects are difficult but this doesn’t mean Agile/Scrum are not right for large projects because large projects are difficult and have similar problems no matter the framework or methodology used.
Agile projects have an extra dimension because quick decisions are needed from empowered product owners to give Scrum direction and feedback
Having multiple teams adds the need for more communication and collaboration and managing dependencies between teams.
There are lots of different scaled agile frameworks, many of them discussed in article below
Comparing scaling agile frameworks
- SaFE – Scaled Agile http://www.scaledagileframework.com/
- Disciplined Agile Delivery (DaD)
- Nexus (Scrum)
Most of the frameworks try to solve problems with shared resources between teams and collaboration between teams (Scrum of Scrums meeting).
If you want existing teams working efficiently, you must remove project level impediments before adding new teams. When a team works well then try adding one more team at a time.
There are other reasons for project troubles
- What’s slowing down your CRM development
- Why rushed projects/code doesn’t save time and reduces quality
Is Safe Evil
Conclusion
Big projects are difficult, hard and challenging and having people with experience of large projects helps. There is pressure with big agile projects because sprinting and collaborating create conflicts and complexity.
Stick with the processes and aim to keep improving your processes and relationships. Challenging projects are the most satisfying to deliver because you have to work hard and earn the achievement of a successfully delivered project.
Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster. [page 14]
How does a project get to be a year behind schedule? One day at a time. Fred Brooks
picture from here
Hosk's Dynamic Blog 