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.
Sunday, 29 January 2017
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)