Scrum will boost when it runs containing Kanban practices.
Anecdote: Kanban was initially labelled as non-agile by some agile practitioners.
Similarities
Both relate to Lean, with Scrum inception being the isolation of the Lean core developed by Takeuchi and Nonaka (1986) as the origin for further work by Jeff Sutherland and Ken Schwaber, and Kanban development directly related to Toyota Lean practices being the origin for David J. Anderson´s work.
Transparency and iterative and incremental (continuous) delivery exist in both.
Differences
Scrum is a framework while Kanban is a model or methodology. This has direct implications as Scrum should be applied as it is while Kanban is tailored to the environment.
Due to this Scrum is structured and it has its own roles, events and artifatcs (Definition of Done, Sprint Goal and Increment) while Kanban applies no change to the current company roles or processes initially and it relies on small changes (Kaizen) that happen across time, one at a time.
A Sprint is locked after the Sprint Planning, Kanban always accepts new work. Their boards (radiators) are slightly different, Scrum has a "fixed columns" board while Kanban board has flexible number of columns.
Scrum events are timeboxed, most Kanban processes aren't.
Being a framework Scrum doesn't limit Work in Progress, nor focuses on Lead or Cycle time (albeit this happens in mature Scrum teams anyway), this is so as a framework doesn't define specific application of methodologies else an scaffolding only. Kanban does as its focus is steady flow.
[250 words]
References
Takeuchi, H. and Nonaka, I., (1986). 'The new new product development game'. Harvard Business Review.
Saturday, 11 February 2017
Thursday, 9 February 2017
How does Scrum fit with the concept of Agile you read about?
Scrum fits perfectly in the concept of Agile as it relates to all the values and principles present in the Agile manifesto by Beck et al. (2001)
- It's an iterative and incremental framework.
- It promotes customer collaboration, this is also one of the Agile values that is prioritised over contract negotiation in the Agile manifesto by Beck et al. (2001).
- It empowers people by distributing the project management role across the three existing roles in Scrum (i.e.: Scrum Master, Product Owner and Development Team) and keeping a flat hierarchy where the process is what is managed and not the people that manage themselves.
- It promotes cross-functional, self-organising teams, simplicity, refactoring, continuous integration, continuous delivery and excellence.
- It promotes a sustainable pace for all the roles involved, including all involved stakeholders, as a way to be able to produce quality software and keep this sustainable pace as long as it's needed for the project to be finished. Exhausting your "resources" - a word disliked in Agile - in pro of unachievable goals is not in the list anymore.
- It welcomes requirement change, even in later stages of the software development.
- Every Sprint should last 30 days or less as a way to deliver working software frequently and gather feedback, this matches the "2 months or less" timebox stated in the Agile manifesto by Beck et al. (2001).
- It promotes the use of retrospectives as a way for continuous improvement and gathering lessons learned.
- It focuses on delivering value (ROI) to the customer, frequently.
[250 words]
References
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]
- It's an iterative and incremental framework.
- It promotes customer collaboration, this is also one of the Agile values that is prioritised over contract negotiation in the Agile manifesto by Beck et al. (2001).
- It empowers people by distributing the project management role across the three existing roles in Scrum (i.e.: Scrum Master, Product Owner and Development Team) and keeping a flat hierarchy where the process is what is managed and not the people that manage themselves.
- It promotes cross-functional, self-organising teams, simplicity, refactoring, continuous integration, continuous delivery and excellence.
- It promotes a sustainable pace for all the roles involved, including all involved stakeholders, as a way to be able to produce quality software and keep this sustainable pace as long as it's needed for the project to be finished. Exhausting your "resources" - a word disliked in Agile - in pro of unachievable goals is not in the list anymore.
- It welcomes requirement change, even in later stages of the software development.
- Every Sprint should last 30 days or less as a way to deliver working software frequently and gather feedback, this matches the "2 months or less" timebox stated in the Agile manifesto by Beck et al. (2001).
- It promotes the use of retrospectives as a way for continuous improvement and gathering lessons learned.
- It focuses on delivering value (ROI) to the customer, frequently.
[250 words]
References
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]
Tuesday, 7 February 2017
Is Prince2 an Agile model or a traditional project management model?
I see PRINCE2 as a subset of PMI, I've worked with both.
PRINCE2 is a traditional project management model, it's sequential. The separation that exist between themes, principles and processes creates no iterative nor incremental behaviour at all. In fact, none of the different stages the project goes through has a resemblance to Agile, they are all sequential, too.
The repetition of some phases does not make it Agile as they only happen because they divide the work to be done in different subphases but there is no iteration, no incremental approach, nor any customer interaction happens until the end.
The documents (work packages, project mandate, etc.) that are produced on each phase are literally the same standard "deliverables" that can be found in all other waterfall practices, like PMI for example.
Themes, principles and processes are interlinked but only to act like a way of enriching each other during the phases the project goes through, working as a way to explain how to tackle the different procedures that will happen and which are the different documents or artifacts to produce on each stage but there is no sense of incremental development of any type.
Stage after stage the product is generated and finally, testing and acceptation by the client happens. A very waterfall approach. Therefore, the PRINCE2 model suffers the same problems that any other waterfall approach would do: problems are found too late and they're very difficult to be amended without redoing long parts of the work, etc.
[250 words]
PRINCE2 is a traditional project management model, it's sequential. The separation that exist between themes, principles and processes creates no iterative nor incremental behaviour at all. In fact, none of the different stages the project goes through has a resemblance to Agile, they are all sequential, too.
The repetition of some phases does not make it Agile as they only happen because they divide the work to be done in different subphases but there is no iteration, no incremental approach, nor any customer interaction happens until the end.
The documents (work packages, project mandate, etc.) that are produced on each phase are literally the same standard "deliverables" that can be found in all other waterfall practices, like PMI for example.
Themes, principles and processes are interlinked but only to act like a way of enriching each other during the phases the project goes through, working as a way to explain how to tackle the different procedures that will happen and which are the different documents or artifacts to produce on each stage but there is no sense of incremental development of any type.
Stage after stage the product is generated and finally, testing and acceptation by the client happens. A very waterfall approach. Therefore, the PRINCE2 model suffers the same problems that any other waterfall approach would do: problems are found too late and they're very difficult to be amended without redoing long parts of the work, etc.
[250 words]
How would you change the waterfall model for it to work better in todays IT industry?
After reading the materials provided and getting to the conclusion that waterfall was even originally perceived as a faulty model, that probably was taken on board because it was the only one that could provide companies with certainty at the time, I would say that trying to amend Waterfall keeping its structure is a lost battle.
During my work on FMVEK module last year, as part of my research work I found a paper that I perceived then as regressive; the paper reflects the research done by Hong, N. et al. (2010) that created a "Waterfalled Scrum" because they found this worked for them in outsourced projects.
Avoiding using here the approach they took, I personally would try to move the model a bit towards agile, by trying to solve the disconnection with the customer and make it iterative plus gathering external and internal feedback.
It will not be really Agile, as explained in Mike Cohn (2015) an iterative Waterfall is not Agile, but at least it will be a step better than it is now. Dividing the work and requirements gathering in small phases would help to limit risks and adding reviews and retrospectives at the end of each iteration would help to receive customer feedback, and learn/improve from what have been done and how.
We would be doing mini-waterfall inside each of those iterations instead of doing agile but the small benefits we can scratch would improve the Waterfall model, albeit if just creating an "agile" illusion.
[250 words]
References
Hong, N. Yoo, J., and Cha, S. (2010) ‘Customization of Scrum Methodology for Outsourced E-Commerce Projects’, In Proceedings of the 2010 Asia Pacific Software Engineering Conference (APSEC '10), Nov. 30 -Dec. 3. IEEE Computer Society, Washington, DC, USA, 310-315. Available at: http://dx.doi.org/10.1109/APSEC.2010.43
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]
During my work on FMVEK module last year, as part of my research work I found a paper that I perceived then as regressive; the paper reflects the research done by Hong, N. et al. (2010) that created a "Waterfalled Scrum" because they found this worked for them in outsourced projects.
Avoiding using here the approach they took, I personally would try to move the model a bit towards agile, by trying to solve the disconnection with the customer and make it iterative plus gathering external and internal feedback.
It will not be really Agile, as explained in Mike Cohn (2015) an iterative Waterfall is not Agile, but at least it will be a step better than it is now. Dividing the work and requirements gathering in small phases would help to limit risks and adding reviews and retrospectives at the end of each iteration would help to receive customer feedback, and learn/improve from what have been done and how.
We would be doing mini-waterfall inside each of those iterations instead of doing agile but the small benefits we can scratch would improve the Waterfall model, albeit if just creating an "agile" illusion.
[250 words]
References
Hong, N. Yoo, J., and Cha, S. (2010) ‘Customization of Scrum Methodology for Outsourced E-Commerce Projects’, In Proceedings of the 2010 Asia Pacific Software Engineering Conference (APSEC '10), Nov. 30 -Dec. 3. IEEE Computer Society, Washington, DC, USA, 310-315. Available at: http://dx.doi.org/10.1109/APSEC.2010.43
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]
Sunday, 5 February 2017
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.
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.
Subscribe to:
Posts (Atom)