Based on what you have read in these chapters and your understanding of Agile, what are the problems with the Agile project Management model?

After reading Highsmith, J., (2009) and understanding the proposed model and layers I found the following existing problems:

1. The proposed APM model is a hybrid agile method, this meaning it doesn´t apply agile in all the layers it uses. It´s a wrap around agile that limits agility to the team layer. Portfolio and PM layers continue to be worked out in a traditional manner. This effectively kills the opportunity for the entire company to become agile.

2. The Explore phase is really an iterative waterfall, iterative waterfall is not agile as clearly explained in Mike Cohn (2015). These are also called mini-waterfall iterations, as a way to differentiate them from the mini-agile iterations that should happen inside an agile project.

3. It does exist a product team and development team differentiation and barrier, in Agile the team should be just one team containing all the people that are needed to produce an iteration ending on a releaseable product.

4. Omnipresent Project Manager, negating the reality that in agile project management is distributed across all the members of the team.

5. Iteration 0 recommendation is present in the model as an alternative.
This is a huge no-no in all agile practices, where it's heavily remarked that it shouldn't exist a iteration 0 (or Sprint 0), it shouldn't exist hardening iteration, technical debt iterations, planning iterations, etc. either. Long time has passed and one after another teams and authors still go into this common pitfall that make them feel "safe" in their illusion of planning some work in a non-agile way, in advance and before the project really starts.

6. Estimation in hours is proposed as an alternative to points, where the idea of using story points is not clearly stated. This gives the impression that both are providing the same benefits but that's not how the practice evolved.

Going from man hours estimations into story points (relative estimations) happened for a reason, to avoid the relation between fix time estimates, where the humans are not good and use a different approach (relative estimations), where the humans are more accurate.

If you have built a house in one month and I ask you how long will it take you to build an identical house you´ll probably be more accurate than if I ask you how long will it take you in man hours to build the first house. Removing the time and counting it into points also helped to reduce anxiety generated by managerial on the teams.

7. The book misses the point of what really iterative and incremental (when they happen together) releases mean in certain passages.

For example, when indicating that delivering half an airplane cannot be considered an option and it indicates that's why the iterations need to be longer. This is not a real cause-effect relation as the author pretends it to be.

What happens is his example is not necessary incremental and it's showing it is not iterative as well. On a real iterative and incremental approach no release would end up with half a product, ever.

8. "done-done" is a useless term, the only term in agile to describe you have something finished and ready to be released is "Done", this is so as it's done or it isn't.

Done-done is something some very prominent authors in the agile field (for example, Jeff Sutherland one of the Scrum authors) have mentioned for a while but never got anywhere, like his ready-ready term that also ended up in "Ready" all these duplicates have been removed from the scene as they only referred to the fact that it should be really "Done" (or really "Ready", albeit the definition of Ready is also not part of the Official Scrum Guide either).

8. The relative value points calculation described is arbitrary, confusing and not following standard rules.

9. Iteration managers shouldn't be the ones responsible for the iteration, the team should be. Teams are just relegated to workload management in the book.

10. When setting iteration depth, the 3 criteria presented plus all additional factors do not include an "Acceptable horizon for plannification". Resulting on a too team centric and narrow view.

The only three criteria that are needed are as it follows:
- 2 months or less as a time limit, according to the Agile manifesto on Beck et al. (2001).
- Minimum time for the team to deliver an increment (i.e.: everything the book mentions)
- Acceptable horizon for the Product Owner's plannification (or "Product manager's plannification") .

[750 words]


References
Cohn, M. (2015). An Iterative Waterfall Isn’t Agile [online] Mountain Goat Software. Available at: https://www.mountaingoatsoftware.com/blog/an-iterative-waterfall-isnt-agile [Accessed 05 February 2017]

Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R., Mellor, S., Schwaber, K., Sutherland, J. and Thomas, D. (2001). Manifesto for Agile Software Development. [online] Agilemanifesto.org. Available at: http://www.agilemanifesto.org/ [Accessed 21 January 2017]

Highsmith, J., (2009). Agile project management: creating innovative products. Pearson Education. pp. 77-270.