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.
Sunday, 29 January 2017
What extra challenges/possibilities does adaptability post for you as a leader?
Challenges
Adaptability means different options can co-exist, variations can happen, as can last minute changes. So adaptability is more demanding than wanting everything "acording to plan".
Encouraging teams to explore is not easy, equally difficult it's changing traditional frames of mind to fire creativity and innovation. Barriers must be overcome.
Adaptability demands a dynamic approach, the context/environment should be open, flexible, it should support bending - i.e.: shaping the idea onto another direction should be possible at any time as it should be abandoning them - and this is difficult to achieve sometimes.
Humans oppose change by nature however the opportunity to change needs to be embraced by the people involved. An open mind is needed as otherwise good opportunities can fly away.
In relation to costs, adaptability can be costly under situations where the materials to be used are expensive and where numeric models (virtual representations, statistical models, etc.) cannot be used to create simulations, prototyping can be an option in some of those cases though.
To be effective, the effort demanded by adaptability should help beat the competency otherwise its costs could not be justified.
Opportunities
The exploratory approach (envision-explore) allows broader freedom to create and innovate than traditional models (plan-do-check-act). Creativity and innovation can only exist in a dynamic environment that allows adaptability and testing different options to select the right one.
Adaptation is more powerful when providing value than optimization as optimization can only improve something that exists while adaptation re-shapes existing products or create new things.
[250 words]
Note: This reflection and words are my own but it was written after reading Highsmith, J., (2009). Agile project management: creating innovative products. Pearson Education. pp. 63-76.
Adaptability means different options can co-exist, variations can happen, as can last minute changes. So adaptability is more demanding than wanting everything "acording to plan".
Encouraging teams to explore is not easy, equally difficult it's changing traditional frames of mind to fire creativity and innovation. Barriers must be overcome.
Adaptability demands a dynamic approach, the context/environment should be open, flexible, it should support bending - i.e.: shaping the idea onto another direction should be possible at any time as it should be abandoning them - and this is difficult to achieve sometimes.
Humans oppose change by nature however the opportunity to change needs to be embraced by the people involved. An open mind is needed as otherwise good opportunities can fly away.
In relation to costs, adaptability can be costly under situations where the materials to be used are expensive and where numeric models (virtual representations, statistical models, etc.) cannot be used to create simulations, prototyping can be an option in some of those cases though.
To be effective, the effort demanded by adaptability should help beat the competency otherwise its costs could not be justified.
Opportunities
The exploratory approach (envision-explore) allows broader freedom to create and innovate than traditional models (plan-do-check-act). Creativity and innovation can only exist in a dynamic environment that allows adaptability and testing different options to select the right one.
Adaptation is more powerful when providing value than optimization as optimization can only improve something that exists while adaptation re-shapes existing products or create new things.
[250 words]
Note: This reflection and words are my own but it was written after reading Highsmith, J., (2009). Agile project management: creating innovative products. Pearson Education. pp. 63-76.
What is the difference in how the project team would be managed in an Agile vs. a traditional project?
In my humble opinion, the differences are all engrained in the context that produced each approach.
Traditional projects approaches' goal was getting out of the existing chaos so they focused on control to do so. Agile projects wanted to react timely to change and beat competitors, so they focused on adaptation and value. The course material expresses this as leading (self-organising) teams for agile versus managing tasks for traditional approaches.
These means agile focuses on change through a steering servant-leadership while traditional approaches focus on management tasks achieved through a command and control leadership style.
At inception level
Agile focuses on a product vision that helps finding boundaries and needs (adaptative approach), traditional approaches focus on requirements, plans, monitoring, risks, contraints and milestones (plan-do-check-act approach, also known as the Deming cycle or PDCA).
On a team level
Agile is about getting people with the right skills and attitude, to create effective, self-organised efficient teams and promotes collaboration and knowledge sharing, while traditional approaches focuses on skills, "doers' obedience" and following identified requirements.
On a trust level
Agile promotes non-blaming cultures, with responsibility spread across the entire team, the "teams suceed or fail together". Accountability still exist but it's based on trust and empowering team members to do their work. (Traditional) failure is now perceived as a learning opportunity.
In traditional projects failure relates to control, demanding "finding the one to blame and amending the situation", i.e.: searching for the one that "didn't follow the requirements"or "planned incorrectly" and act accordingly.
[250 words]
Note: This reflection and words are my own but it was written after reading Highsmith, J., (2009). Agile project management: creating innovative products. Pearson Education. pp. 47-61.
Traditional projects approaches' goal was getting out of the existing chaos so they focused on control to do so. Agile projects wanted to react timely to change and beat competitors, so they focused on adaptation and value. The course material expresses this as leading (self-organising) teams for agile versus managing tasks for traditional approaches.
These means agile focuses on change through a steering servant-leadership while traditional approaches focus on management tasks achieved through a command and control leadership style.
At inception level
Agile focuses on a product vision that helps finding boundaries and needs (adaptative approach), traditional approaches focus on requirements, plans, monitoring, risks, contraints and milestones (plan-do-check-act approach, also known as the Deming cycle or PDCA).
On a team level
Agile is about getting people with the right skills and attitude, to create effective, self-organised efficient teams and promotes collaboration and knowledge sharing, while traditional approaches focuses on skills, "doers' obedience" and following identified requirements.
On a trust level
Agile promotes non-blaming cultures, with responsibility spread across the entire team, the "teams suceed or fail together". Accountability still exist but it's based on trust and empowering team members to do their work. (Traditional) failure is now perceived as a learning opportunity.
In traditional projects failure relates to control, demanding "finding the one to blame and amending the situation", i.e.: searching for the one that "didn't follow the requirements"or "planned incorrectly" and act accordingly.
[250 words]
Note: This reflection and words are my own but it was written after reading Highsmith, J., (2009). Agile project management: creating innovative products. Pearson Education. pp. 47-61.
Wednesday, 25 January 2017
How customer value is viewed differently in Agile and more traditional project management models?
As per my previous post, Agile focuses on value, quality, adaptability, feedback, continuous delivery and time to market. Efficiency and optimization - boosted by removing waste (i.e.: everything that does not provide value) - are used to accelerate time to market, continuous delivery and innovation. Delivering value early is key.
The whole process is driven by a product vision, delivery (i.e.: execution) and empowering people for them to self-organise.
Agile is based on iterations based on feedback and an incremental approach normally timeboxed and based in features - albeit a functional approach doesn't stop the process being agile, this being a widespread false myth. Technical excellence (quality) embeds value into the product making the work done by self-organising teams easier to mantain, modify (adaptability) and scale.
In contrast, traditional project management focuses on scope (requirements), through planning, monitoring and controlling, not so much on execution.
Based on command and control to make sure what was planned is created according to its requirements, removing need for feedback and continuous delivery but killing innovation and self-organisation by doing so.
Too much time is dedicated to documentation and processes (i.e.: compliance). Radical application of traditional methods can easily end up being a justification through documentation where it's more important to show you're not the one to blame than what was created. Excessive compliance is perceived as a waste in Agile.
Traditional methods are mostly sequential, they expect "doers" instead of professionals with technical excellence, people that obey and do what they were asked (according to requirements).
[250 words]
Note: This reflection and words are my own but it was written after reading Highsmith, J., (2009). Agile project management: creating innovative products. Pearson Education. pp. 27-45.
The whole process is driven by a product vision, delivery (i.e.: execution) and empowering people for them to self-organise.
Agile is based on iterations based on feedback and an incremental approach normally timeboxed and based in features - albeit a functional approach doesn't stop the process being agile, this being a widespread false myth. Technical excellence (quality) embeds value into the product making the work done by self-organising teams easier to mantain, modify (adaptability) and scale.
In contrast, traditional project management focuses on scope (requirements), through planning, monitoring and controlling, not so much on execution.
Based on command and control to make sure what was planned is created according to its requirements, removing need for feedback and continuous delivery but killing innovation and self-organisation by doing so.
Too much time is dedicated to documentation and processes (i.e.: compliance). Radical application of traditional methods can easily end up being a justification through documentation where it's more important to show you're not the one to blame than what was created. Excessive compliance is perceived as a waste in Agile.
Traditional methods are mostly sequential, they expect "doers" instead of professionals with technical excellence, people that obey and do what they were asked (according to requirements).
[250 words]
Note: This reflection and words are my own but it was written after reading Highsmith, J., (2009). Agile project management: creating innovative products. Pearson Education. pp. 27-45.
Tuesday, 24 January 2017
What is Agile Project Management?
Agile Project management is a relatively new project management paradigm that is based in agile principles and values.
An iterative and incremental model that focuses on value, quality, adaptability, feedback, continuous innovation and time to market. In oposition to more traditional and rigid models its adaptability makes it ideal for projects that need to react quickly to what the market demands and those where it's not fully defined in advance what needs to be produced, where the final product depends in one way or another of the demand in the current market.
Agile models strive for quality, continuous development and continuous integration, with a product vision that exists from the inception of the products but without too much constraints on how to get to that vision. The paths selected - sometimes more than one - will help shaping the final product through (a) continuous interaction with the final users, this is why continuous integration is needed, and (b) the feedback received from them being used to re-shape the product until a final product is reached.
This flow produces an iterative cycle that adapts to feedback and grows the product incrementally, with each of the iterations producing a usable product that can received feedback to be considered against and towards the final vision.
In comparison with traditional methods that lack a continuous input from final users agile methodologies differentiate themselves by far, doing this they achieve productivity increases, produce better products with shorter costs and launch final products in shorter periods of time.
[250 words]
Note: This reflection and words are my own but it was written after reading Highsmith, J., (2009). Agile project management: creating innovative products. Pearson Education. pp. 5-26.
An iterative and incremental model that focuses on value, quality, adaptability, feedback, continuous innovation and time to market. In oposition to more traditional and rigid models its adaptability makes it ideal for projects that need to react quickly to what the market demands and those where it's not fully defined in advance what needs to be produced, where the final product depends in one way or another of the demand in the current market.
Agile models strive for quality, continuous development and continuous integration, with a product vision that exists from the inception of the products but without too much constraints on how to get to that vision. The paths selected - sometimes more than one - will help shaping the final product through (a) continuous interaction with the final users, this is why continuous integration is needed, and (b) the feedback received from them being used to re-shape the product until a final product is reached.
This flow produces an iterative cycle that adapts to feedback and grows the product incrementally, with each of the iterations producing a usable product that can received feedback to be considered against and towards the final vision.
In comparison with traditional methods that lack a continuous input from final users agile methodologies differentiate themselves by far, doing this they achieve productivity increases, produce better products with shorter costs and launch final products in shorter periods of time.
[250 words]
Note: This reflection and words are my own but it was written after reading Highsmith, J., (2009). Agile project management: creating innovative products. Pearson Education. pp. 5-26.
Saturday, 21 January 2017
What do you think are the strengths, weaknesses, opportunities and threats of the two types of models discussed?
On this reflection I will deal separately with traditional models and agile models. A small SWOT analysis is shown for each model below.
Traditional Project Management
Strengths
They are ideal for predictable projects, also for those in which a command and control approach is looked for as they are used to gain control. This model could work in chaotic systems, those that are in the unknown space with not much time to react.
Weaknesses
Suffer from a bad adaptation to late change requests. It's sequential and rigid approach - closed to the option of going back and review a certain stage, once each of the stages is over - is their biggest weakness. That makes it inflexible. It's prone to too much red tape if applied 'by the book'. It focuses on what was signed off, leaving outside what could have turned to be the real need. It can get to be too procedural.
Opportunities
Those projects where all requirements are known in advance or they can be found up front; or projects with repeating patterns or well known steps are a good opportunity for traditional models.
Threats
Change requests, problems with documentation being unnecessarily excessive as it´s applied by the book instead of as and when needed.
Documentation is not always easy to mantain, analysis paralisis can be a problem during some phases.
It can end up perversely transformed in a formal justification of who did what to avoid being pointed out as the one to blame, losing focus on what needs to be done and focusing on "protecting oneself from future punishment".
Agile Project Management
Strengths
Ideal for projects with emergent answers across time or where many ideas exist and compete between them. It´s adaptability, flexibility and transparency make it ideal for hearing everyone involve, discussing different ideas and approaches and reaching agreements, modifications, etc. based on the feedback received from all parties involved (including the final user). It potentiates a more effective communication, collaboration and cross-functionality. It empowers those with the knowledge to do the correspondent tasks. It (hopefully) provides a product that it's fit for purpose, with all the involved parties taken in consideration. It provides the product the customer wants, not the one the company wanted without receiving feedback from customers.
Weaknesses
It doesn´t work in chaotic systems and it's not needed in situations where all the answers are known in advance and there is no change to be expected, those projects that are in the fully unknown space with not much time to react or take decisions are not fit for an agile model. The model turns innefficient when the some stakeholders are voluntarily absent during the process or when no self-organising is present and this turn the experience in an environment where the focus is moved into the wellbeing of the team and delivering the product takes a second place.
Opportunities
Projects where changes are expected, where there is enough time to take the right decisions and where the final product is not 100% defined in advance, following the idea that the client cannot know exactly what they want until they see it.
Transforming entire organisations was left for traditional models in the past as big organisations where afraid of trying, fortunately there is now an opportunity for the agile model to transform organisations entirely, including departments where the idea of transition them into Agile was considered taboo not so long ago, we are talking about departments as accountancy or HR.
Threats
Failed attempts to remain in waterfall but calling it agile are the main thread as companies don't know what to expect or blame these brainchildren generated by consultancies where the main interest is cashing in.
Agile myths are promoted by people without enough knowledge making teams believe agile means they now do not need to provide any documentation, that everything will emerge by its own, etc.
Replicating old waterfall approaches in agile kills agility. Agile is still very misunderstood, even some of those that promote certain things lack real knowledge on what Agile is about.
Traditional Project Management
Strengths
They are ideal for predictable projects, also for those in which a command and control approach is looked for as they are used to gain control. This model could work in chaotic systems, those that are in the unknown space with not much time to react.
Weaknesses
Suffer from a bad adaptation to late change requests. It's sequential and rigid approach - closed to the option of going back and review a certain stage, once each of the stages is over - is their biggest weakness. That makes it inflexible. It's prone to too much red tape if applied 'by the book'. It focuses on what was signed off, leaving outside what could have turned to be the real need. It can get to be too procedural.
Opportunities
Those projects where all requirements are known in advance or they can be found up front; or projects with repeating patterns or well known steps are a good opportunity for traditional models.
Threats
Change requests, problems with documentation being unnecessarily excessive as it´s applied by the book instead of as and when needed.
Documentation is not always easy to mantain, analysis paralisis can be a problem during some phases.
It can end up perversely transformed in a formal justification of who did what to avoid being pointed out as the one to blame, losing focus on what needs to be done and focusing on "protecting oneself from future punishment".
Agile Project Management
Strengths
Ideal for projects with emergent answers across time or where many ideas exist and compete between them. It´s adaptability, flexibility and transparency make it ideal for hearing everyone involve, discussing different ideas and approaches and reaching agreements, modifications, etc. based on the feedback received from all parties involved (including the final user). It potentiates a more effective communication, collaboration and cross-functionality. It empowers those with the knowledge to do the correspondent tasks. It (hopefully) provides a product that it's fit for purpose, with all the involved parties taken in consideration. It provides the product the customer wants, not the one the company wanted without receiving feedback from customers.
Weaknesses
It doesn´t work in chaotic systems and it's not needed in situations where all the answers are known in advance and there is no change to be expected, those projects that are in the fully unknown space with not much time to react or take decisions are not fit for an agile model. The model turns innefficient when the some stakeholders are voluntarily absent during the process or when no self-organising is present and this turn the experience in an environment where the focus is moved into the wellbeing of the team and delivering the product takes a second place.
Opportunities
Projects where changes are expected, where there is enough time to take the right decisions and where the final product is not 100% defined in advance, following the idea that the client cannot know exactly what they want until they see it.
Transforming entire organisations was left for traditional models in the past as big organisations where afraid of trying, fortunately there is now an opportunity for the agile model to transform organisations entirely, including departments where the idea of transition them into Agile was considered taboo not so long ago, we are talking about departments as accountancy or HR.
Threats
Failed attempts to remain in waterfall but calling it agile are the main thread as companies don't know what to expect or blame these brainchildren generated by consultancies where the main interest is cashing in.
Agile myths are promoted by people without enough knowledge making teams believe agile means they now do not need to provide any documentation, that everything will emerge by its own, etc.
Replicating old waterfall approaches in agile kills agility. Agile is still very misunderstood, even some of those that promote certain things lack real knowledge on what Agile is about.
How do you relate the Agile Manifesto and principles to what you have learned so far in this program?
In this first part of the course, we have learned so far some of the differences between traditional project management and agile project management.
The agile manifesto has a clear approach based on empowering people to do their work; individuals and interaction, working software, customer collaboration and responding to change are all related to this and they are the most valued items in the manifesto on Beck et al. (2001).
This is in clear opposition to those items that where indeed most valued in traditional project management approaches, where control exerted by well defined processes, negotiated contracts, extensive documentation, and plans were key.
In Agile a servant-leadership approach - as proposed by Greenleaf (1970) in his groundbreaking essay - is used, in opposition with the control and command approach typical of all other leadership styles.
Despite how wonderful it could sound the Agile approach doesn´t come at no cost, and despite it´s easy to understand the items and principles it´s not easy at all to put them in practice, to be agile, as a look into the principles will make clear straightaway.
Customer satisfaction and value are king, openness to change is a must, fast and frequent delivery a need for the customer to receive the software and give feedback in a timely way - in clear opposition to Waterfall where the customer only see the product at the very end -, all stakeholders have to work together/communicate during the process to be effective in this approach - opposed to waterfall where the external stakeholders are not present in all stages - and there is no benefit on having a shelf full of documentation if the software doesn´t work as expected.
A sustainable pace is demanded, at the same time the work done should have the highest quality possible to avoid the need to amend it or re-do it infinitively (albeit refactoring is also key). This is a new threshold bar regarding demand and quality, it´s not about doing what you were told anymore, now there is a quality threshold that is achieved by a compound of tests (TDD, BDD, ATDD, etc.), working software, the value it delivers, simplicity, good design, technical excellence, continuous delivery and continuous integration. No work is done in advance, everything emerges while all involved actors are working on it. The team reflects on what has been done and constantly tries to improve by using what was learned up to then and finding ways to do better.
These principles are also linked to personal and professional values; for example commitment, courage, focus, openness and respect are the Scrum values one can find in an article by West (2016) announcing its inclussion in the Scrum official guide in July 2016 but they are common to other existing agile approaches, too. The values are there because agile seems very simple in theory but it´s difficult in practice as it´s not easy at all to remain agile when interruptions and external pressures to do it the traditional way come into play. Sticking to the values and principles is therefore a goal in itself but without the principles and values no agility is achieved.
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]
West, D. (2016). Updates to the Scrum Guide – The 5 Scrum values take center stage - Scrum.org Community Blog. [online] Scrum.org Community Blog. Available at: https://blog.scrum.org/updates-scrum-guide-5-scrum-values-take-center-stage/ [Accessed 21 January 2017]
Greenleaf, R. K. (1970). The servant as leader. Indianapolis, IN: Robert K. Greenleaf Center
The agile manifesto has a clear approach based on empowering people to do their work; individuals and interaction, working software, customer collaboration and responding to change are all related to this and they are the most valued items in the manifesto on Beck et al. (2001).
This is in clear opposition to those items that where indeed most valued in traditional project management approaches, where control exerted by well defined processes, negotiated contracts, extensive documentation, and plans were key.
In Agile a servant-leadership approach - as proposed by Greenleaf (1970) in his groundbreaking essay - is used, in opposition with the control and command approach typical of all other leadership styles.
Despite how wonderful it could sound the Agile approach doesn´t come at no cost, and despite it´s easy to understand the items and principles it´s not easy at all to put them in practice, to be agile, as a look into the principles will make clear straightaway.
Customer satisfaction and value are king, openness to change is a must, fast and frequent delivery a need for the customer to receive the software and give feedback in a timely way - in clear opposition to Waterfall where the customer only see the product at the very end -, all stakeholders have to work together/communicate during the process to be effective in this approach - opposed to waterfall where the external stakeholders are not present in all stages - and there is no benefit on having a shelf full of documentation if the software doesn´t work as expected.
A sustainable pace is demanded, at the same time the work done should have the highest quality possible to avoid the need to amend it or re-do it infinitively (albeit refactoring is also key). This is a new threshold bar regarding demand and quality, it´s not about doing what you were told anymore, now there is a quality threshold that is achieved by a compound of tests (TDD, BDD, ATDD, etc.), working software, the value it delivers, simplicity, good design, technical excellence, continuous delivery and continuous integration. No work is done in advance, everything emerges while all involved actors are working on it. The team reflects on what has been done and constantly tries to improve by using what was learned up to then and finding ways to do better.
These principles are also linked to personal and professional values; for example commitment, courage, focus, openness and respect are the Scrum values one can find in an article by West (2016) announcing its inclussion in the Scrum official guide in July 2016 but they are common to other existing agile approaches, too. The values are there because agile seems very simple in theory but it´s difficult in practice as it´s not easy at all to remain agile when interruptions and external pressures to do it the traditional way come into play. Sticking to the values and principles is therefore a goal in itself but without the principles and values no agility is achieved.
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]
West, D. (2016). Updates to the Scrum Guide – The 5 Scrum values take center stage - Scrum.org Community Blog. [online] Scrum.org Community Blog. Available at: https://blog.scrum.org/updates-scrum-guide-5-scrum-values-take-center-stage/ [Accessed 21 January 2017]
Greenleaf, R. K. (1970). The servant as leader. Indianapolis, IN: Robert K. Greenleaf Center
Subscribe to:
Posts (Atom)