Agile “Resource” Allocation - Forming Agile Teams

In traditional resource allocation, we assign programmers or “resources” to a project based on need or availability. However, issues arise when we start working on multiple projects and suddenly our programmers are now working on multiple projects and teams. Traditional resource allocation is a sure way to overwhelm individuals.
In Agile, we form teams much differently. Agile teams work together to tackle the work that is prioritized the highest, according to stakeholders.
Learn more about forming successful Agile teams and how to prioritize projects effectively with this video from David Hawks.
Want to know more about forming strong Agile teams? Check out our whitepaper: Build High Performing Teams Through Trust and Alignment (info.agileveloc...)
Follow Agile Velocity around the internet:
Our Website: www.agileveloci...
Our Agile Library: agilevelocity....
Twitter: / agile_velocity
Facebook: / agilevelocity
LinkedIn: / agil. .
Instagram: / agile_veloc…

[@MrUWpt]

No, waterfall does not work as described unless managed really badly.
We have WBS and Gantt to show WHEN and HOW much work is needed from particular people / resources. That gives you chance to identify clashes and than prioritisation comes into place in terms of assessment what is the possible delay and financial impact impact on particular projects with different scenarios. Easy to do a company priority than. Have seen that hunderts of times in telco. It works. 👍🏻

[@Xieerqi]

There's couple things I did not like about this video. One, the instantaneous assumption that developer will work on coolest,easiest, and self-beneficial features of the project. Sorry, while it may have been true in the past, nowadays developers ( even those coming out fresh from university ) are aware of agile, aware of taking into account stakeholder's desired features or functionalities. Assumption that developer will work on easiest feature should also be reconsidered: the goal of agile is to produce working software, and when you automatically assume developer works on the easiest feature, while they may reasonably prioritize the a feature that gets project working - that's gonna lead to unnecessary friction between management and developers. The two points in the end - shared ownership of the project and dialog with stakeholders - that's the good part, and probably should have been introduced right from the beginning of the video. Otherwise, I'm guessing with 1823 views so far, a lot probably did not finished watching the video and were just rolling the eyes by the middle of it all

[@davidhawks2457]

To clarify in the first scenario (waterfall) I was stating that in the absence of management providing input into priority and just saying everything is high priority the developer is left with prioritizing based on non value based criteria, such as, coolest, easiest, etc. I agree that in agile (the second scenario) developers shouldn't work in this way.