blogarticle
An agile approach software development pros and cons
Whilst researching this article I found the following statement that at first shocked me, but on reflection wasnt a surprise:
According to the Standish Groups famous CHAOS Report of 2000, 25% of all projects still fail outright through eventual cancellation, with no useful software deployed. Sadly, this represents a big improvement over CHAOS reports from past years. And now there is more evidence of the same kind. In Agile and Iterative Development: a Managers Guide, renowned consultant and author Craig Larman does a thorough job of debunking the traditional waterfall model once and for all.
https://www.versionone.com/agile-101/agile-software-development-benefits/
Over the last 15 years we have developer over a 200 software applications and it is always disheartening when a solution isn't implemented within a business, for whatever reason. Sometimes, it's down to change management or simply user resistance, which is why we encourage all stakeholders to take an active role during the development, right from the start line, during the creation of the business requirements.
In nearly all cases we can attribute a lack of active participation during the capturing of the business requirements, project development and User Acceptance Testing (UAT) to projects failing. We've seen 4 fail, for this very reason; that's 2% and well under the figure suggested the CHAOS report. The other barrier to implementation is the pain a business had to go through in order to implement the solution; e.g. data migration, especially where data is dispersed across multiple sources across the business.
Three or four years ago, we developed a solution for a coaching business and we thought the project was going to fail, as when we got to the data migration and asked for the business contact details they looked in horror and said that they were spread out across the entire business on each individuals laptops! They had no centralised location where their client data was stored. You might be horrified at this, but it is something we see time and time again and is one of the benefits to having a bespoke solutions that gathers all your business data, enabling you to get far better transparency and Business Intelligence (BI) for decision making.
What is agile software development?
Agile software development is founded on evolutionary project management that enables the development process to adapt to changing requirements. This is in direct contradiction with traditional approaches of software development, whereby a specification was agreed upfront prior to the software development and was rigidly stuck too.
Agile software development is adaptive, able to cope with changes with business requirements (up to a certain point)! Its foundations are rooted in Rapid Application Development (RAD) methodologies from the nineteen nineties when developers used RAD Tools like Microsofts Visual Studio and Borlands Delphi, both of which supported Object Orientated Programming (OOP) languages that enable applications to be extended; i.e. adapted and changed to introduce new business requirements.
Agile provides:
- Improved visibility of software development with regular alpha releases.
- Far better adaptability; able to integrate changes to the business requirements.
- Greater value to the business, as they are able to access and utilise the solution far sooner, even if its not complete.
- Less risk, as they can see the progress of development.
So, why would an agile approach fail?
The single biggest reason an agile approach fails is lack client engagement. As a business we use an agile approach to software development and can start development, even where the business requirements are not complete. We need to have a high level list of requirements thrashed out, but we can capture the details during the development process.
In an ideal world we'll know a lot about the business and can make educated assumptions about how each process should work, but this needs the active involvement in the project development stage, as we'll need to discuss the finer details with the project manager. We'll often seek clarification and / or agreement of specific points, as we want to avoid re-writing code to integrate changes to elements like on screen and email copy, e.g. a sales receipt or order confirmation generated by the solution.
However, we predominantly work with small businesses that are constant struggling with resources, be they human or otherwise. We therefore accept that we do not operate in an ideal world and accept the risk of taking on projects with specifications that are far from idea. It is therefore essential that there is a good working relationship between the software development team and the client?s project manager. We work hard about building a relationship during the early stages, explaining the project managers responsibilities and stressing the work load required to complete the project, not only for the project manager, but other staff within the clients business.
The biggest issue having nurtured a good relationship? is a change of project manager part way through a project. It is imperative for the incoming project manage to get up to speed and work with the development team to understand the background of the project, but this doesn't always happen and can present challenges further down the road, when the expectations set with the original project manage are lost and the incoming project manager has their own set of expectations that often are completely unknown to the development team. We always say: never surprise the client, never allow the client to surprise us but we still get the odd curve ball thrown at us, from time to time.
Conclusion
Whilst this isn't an exhaustive explanation of agile development, it highlights the potential issues software development teams and clients face when adopting any of the agile methodologies: Extreme Programming, Scrum, DSDM, Lean or FDD. As long as all the stake holders are actively involved and are working to a common objective, agile is an ideal approach.
In our experience one shared by colleagues in other software development teams when projects fail the client always looks to blame the software development team and over looks their own failings, a truism in most cases where blame is used as an avoidance technique. It is essential that the blame game is avoided, but this isn't always possible, where ulterior motives are at play. As a project manager with over twenty five years experience, both as a lead / senior software developer and project manager for the last 15 years, I get a sixth sense when troubles lays ahead and work to strike compromise and seek resolution, but alas from time to time this isn't possible and that is when project fail!
Date: 13/10/2017
An agile approach software development pros and cons
Whilst researching this article I found the following statement that at first shocked me, but on reflection wasnt a surprise:
According to the Standish Groups famous CHAOS Report of 2000, 25% of all projects still fail outright through eventual cancellation, with no useful software deployed. Sadly, this represents a big improvement over CHAOS reports from past years. And now there is more evidence of the same kind. In Agile and Iterative Development: a Managers Guide, renowned consultant and author Craig Larman does a thorough job of debunking the traditional waterfall model once and for all.
https://www.versionone.com/agile-101/agile-software-development-benefits/
Over the last 15 years we have developer over a 200 software applications and it is always disheartening when a solution isn't implemented within a business, for whatever reason. Sometimes, it's down to change management or simply user resistance, which is why we encourage all stakeholders to take an active role during the development, right from the start line, during the creation of the business requirements.
In nearly all cases we can attribute a lack of active participation during the capturing of the business requirements, project development and User Acceptance Testing (UAT) to projects failing. We've seen 4 fail, for this very reason; that's 2% and well under the figure suggested the CHAOS report. The other barrier to implementation is the pain a business had to go through in order to implement the solution; e.g. data migration, especially where data is dispersed across multiple sources across the business.
Three or four years ago, we developed a solution for a coaching business and we thought the project was going to fail, as when we got to the data migration and asked for the business contact details they looked in horror and said that they were spread out across the entire business on each individuals laptops! They had no centralised location where their client data was stored. You might be horrified at this, but it is something we see time and time again and is one of the benefits to having a bespoke solutions that gathers all your business data, enabling you to get far better transparency and Business Intelligence (BI) for decision making.
What is agile software development?
Agile software development is founded on evolutionary project management that enables the development process to adapt to changing requirements. This is in direct contradiction with traditional approaches of software development, whereby a specification was agreed upfront prior to the software development and was rigidly stuck too.
Agile software development is adaptive, able to cope with changes with business requirements (up to a certain point)! Its foundations are rooted in Rapid Application Development (RAD) methodologies from the nineteen nineties when developers used RAD Tools like Microsofts Visual Studio and Borlands Delphi, both of which supported Object Orientated Programming (OOP) languages that enable applications to be extended; i.e. adapted and changed to introduce new business requirements.
Agile provides:
- Improved visibility of software development with regular alpha releases.
- Far better adaptability; able to integrate changes to the business requirements.
- Greater value to the business, as they are able to access and utilise the solution far sooner, even if its not complete.
- Less risk, as they can see the progress of development.
So, why would an agile approach fail?
The single biggest reason an agile approach fails is lack client engagement. As a business we use an agile approach to software development and can start development, even where the business requirements are not complete. We need to have a high level list of requirements thrashed out, but we can capture the details during the development process.
In an ideal world we'll know a lot about the business and can make educated assumptions about how each process should work, but this needs the active involvement in the project development stage, as we'll need to discuss the finer details with the project manager. We'll often seek clarification and / or agreement of specific points, as we want to avoid re-writing code to integrate changes to elements like on screen and email copy, e.g. a sales receipt or order confirmation generated by the solution.
However, we predominantly work with small businesses that are constant struggling with resources, be they human or otherwise. We therefore accept that we do not operate in an ideal world and accept the risk of taking on projects with specifications that are far from idea. It is therefore essential that there is a good working relationship between the software development team and the client?s project manager. We work hard about building a relationship during the early stages, explaining the project managers responsibilities and stressing the work load required to complete the project, not only for the project manager, but other staff within the clients business.
The biggest issue having nurtured a good relationship? is a change of project manager part way through a project. It is imperative for the incoming project manage to get up to speed and work with the development team to understand the background of the project, but this doesn't always happen and can present challenges further down the road, when the expectations set with the original project manage are lost and the incoming project manager has their own set of expectations that often are completely unknown to the development team. We always say: never surprise the client, never allow the client to surprise us but we still get the odd curve ball thrown at us, from time to time.
Conclusion
Whilst this isn't an exhaustive explanation of agile development, it highlights the potential issues software development teams and clients face when adopting any of the agile methodologies: Extreme Programming, Scrum, DSDM, Lean or FDD. As long as all the stake holders are actively involved and are working to a common objective, agile is an ideal approach.
In our experience one shared by colleagues in other software development teams when projects fail the client always looks to blame the software development team and over looks their own failings, a truism in most cases where blame is used as an avoidance technique. It is essential that the blame game is avoided, but this isn't always possible, where ulterior motives are at play. As a project manager with over twenty five years experience, both as a lead / senior software developer and project manager for the last 15 years, I get a sixth sense when troubles lays ahead and work to strike compromise and seek resolution, but alas from time to time this isn't possible and that is when project fail!
Date: 13/10/2017
An agile approach software development pros and cons
Whilst researching this article I found the following statement that at first shocked me, but on reflection wasnt a surprise:
According to the Standish Groups famous CHAOS Report of 2000, 25% of all projects still fail outright through eventual cancellation, with no useful software deployed. Sadly, this represents a big improvement over CHAOS reports from past years. And now there is more evidence of the same kind. In Agile and Iterative Development: a Managers Guide, renowned consultant and author Craig Larman does a thorough job of debunking the traditional waterfall model once and for all.
https://www.versionone.com/agile-101/agile-software-development-benefits/
Over the last 15 years we have developer over a 200 software applications and it is always disheartening when a solution isn't implemented within a business, for whatever reason. Sometimes, it's down to change management or simply user resistance, which is why we encourage all stakeholders to take an active role during the development, right from the start line, during the creation of the business requirements.
In nearly all cases we can attribute a lack of active participation during the capturing of the business requirements, project development and User Acceptance Testing (UAT) to projects failing. We've seen 4 fail, for this very reason; that's 2% and well under the figure suggested the CHAOS report. The other barrier to implementation is the pain a business had to go through in order to implement the solution; e.g. data migration, especially where data is dispersed across multiple sources across the business.
Three or four years ago, we developed a solution for a coaching business and we thought the project was going to fail, as when we got to the data migration and asked for the business contact details they looked in horror and said that they were spread out across the entire business on each individuals laptops! They had no centralised location where their client data was stored. You might be horrified at this, but it is something we see time and time again and is one of the benefits to having a bespoke solutions that gathers all your business data, enabling you to get far better transparency and Business Intelligence (BI) for decision making.
What is agile software development?
Agile software development is founded on evolutionary project management that enables the development process to adapt to changing requirements. This is in direct contradiction with traditional approaches of software development, whereby a specification was agreed upfront prior to the software development and was rigidly stuck too.
Agile software development is adaptive, able to cope with changes with business requirements (up to a certain point)! Its foundations are rooted in Rapid Application Development (RAD) methodologies from the nineteen nineties when developers used RAD Tools like Microsofts Visual Studio and Borlands Delphi, both of which supported Object Orientated Programming (OOP) languages that enable applications to be extended; i.e. adapted and changed to introduce new business requirements.
Agile provides:
- Improved visibility of software development with regular alpha releases.
- Far better adaptability; able to integrate changes to the business requirements.
- Greater value to the business, as they are able to access and utilise the solution far sooner, even if its not complete.
- Less risk, as they can see the progress of development.
So, why would an agile approach fail?
The single biggest reason an agile approach fails is lack client engagement. As a business we use an agile approach to software development and can start development, even where the business requirements are not complete. We need to have a high level list of requirements thrashed out, but we can capture the details during the development process.
In an ideal world we'll know a lot about the business and can make educated assumptions about how each process should work, but this needs the active involvement in the project development stage, as we'll need to discuss the finer details with the project manager. We'll often seek clarification and / or agreement of specific points, as we want to avoid re-writing code to integrate changes to elements like on screen and email copy, e.g. a sales receipt or order confirmation generated by the solution.
However, we predominantly work with small businesses that are constant struggling with resources, be they human or otherwise. We therefore accept that we do not operate in an ideal world and accept the risk of taking on projects with specifications that are far from idea. It is therefore essential that there is a good working relationship between the software development team and the client?s project manager. We work hard about building a relationship during the early stages, explaining the project managers responsibilities and stressing the work load required to complete the project, not only for the project manager, but other staff within the clients business.
The biggest issue having nurtured a good relationship? is a change of project manager part way through a project. It is imperative for the incoming project manage to get up to speed and work with the development team to understand the background of the project, but this doesn't always happen and can present challenges further down the road, when the expectations set with the original project manage are lost and the incoming project manager has their own set of expectations that often are completely unknown to the development team. We always say: never surprise the client, never allow the client to surprise us but we still get the odd curve ball thrown at us, from time to time.
Conclusion
Whilst this isn't an exhaustive explanation of agile development, it highlights the potential issues software development teams and clients face when adopting any of the agile methodologies: Extreme Programming, Scrum, DSDM, Lean or FDD. As long as all the stake holders are actively involved and are working to a common objective, agile is an ideal approach.
In our experience one shared by colleagues in other software development teams when projects fail the client always looks to blame the software development team and over looks their own failings, a truism in most cases where blame is used as an avoidance technique. It is essential that the blame game is avoided, but this isn't always possible, where ulterior motives are at play. As a project manager with over twenty five years experience, both as a lead / senior software developer and project manager for the last 15 years, I get a sixth sense when troubles lays ahead and work to strike compromise and seek resolution, but alas from time to time this isn't possible and that is when project fail!
Date: 13/10/2017
An agile approach software development pros and cons
Whilst researching this article I found the following statement that at first shocked me, but on reflection wasnt a surprise:
According to the Standish Groups famous CHAOS Report of 2000, 25% of all projects still fail outright through eventual cancellation, with no useful software deployed. Sadly, this represents a big improvement over CHAOS reports from past years. And now there is more evidence of the same kind. In Agile and Iterative Development: a Managers Guide, renowned consultant and author Craig Larman does a thorough job of debunking the traditional waterfall model once and for all.
https://www.versionone.com/agile-101/agile-software-development-benefits/
Over the last 15 years we have developer over a 200 software applications and it is always disheartening when a solution isn't implemented within a business, for whatever reason. Sometimes, it's down to change management or simply user resistance, which is why we encourage all stakeholders to take an active role during the development, right from the start line, during the creation of the business requirements.
In nearly all cases we can attribute a lack of active participation during the capturing of the business requirements, project development and User Acceptance Testing (UAT) to projects failing. We've seen 4 fail, for this very reason; that's 2% and well under the figure suggested the CHAOS report. The other barrier to implementation is the pain a business had to go through in order to implement the solution; e.g. data migration, especially where data is dispersed across multiple sources across the business.
Three or four years ago, we developed a solution for a coaching business and we thought the project was going to fail, as when we got to the data migration and asked for the business contact details they looked in horror and said that they were spread out across the entire business on each individuals laptops! They had no centralised location where their client data was stored. You might be horrified at this, but it is something we see time and time again and is one of the benefits to having a bespoke solutions that gathers all your business data, enabling you to get far better transparency and Business Intelligence (BI) for decision making.
What is agile software development?
Agile software development is founded on evolutionary project management that enables the development process to adapt to changing requirements. This is in direct contradiction with traditional approaches of software development, whereby a specification was agreed upfront prior to the software development and was rigidly stuck too.
Agile software development is adaptive, able to cope with changes with business requirements (up to a certain point)! Its foundations are rooted in Rapid Application Development (RAD) methodologies from the nineteen nineties when developers used RAD Tools like Microsofts Visual Studio and Borlands Delphi, both of which supported Object Orientated Programming (OOP) languages that enable applications to be extended; i.e. adapted and changed to introduce new business requirements.
Agile provides:
- Improved visibility of software development with regular alpha releases.
- Far better adaptability; able to integrate changes to the business requirements.
- Greater value to the business, as they are able to access and utilise the solution far sooner, even if its not complete.
- Less risk, as they can see the progress of development.
So, why would an agile approach fail?
The single biggest reason an agile approach fails is lack client engagement. As a business we use an agile approach to software development and can start development, even where the business requirements are not complete. We need to have a high level list of requirements thrashed out, but we can capture the details during the development process.
In an ideal world we'll know a lot about the business and can make educated assumptions about how each process should work, but this needs the active involvement in the project development stage, as we'll need to discuss the finer details with the project manager. We'll often seek clarification and / or agreement of specific points, as we want to avoid re-writing code to integrate changes to elements like on screen and email copy, e.g. a sales receipt or order confirmation generated by the solution.
However, we predominantly work with small businesses that are constant struggling with resources, be they human or otherwise. We therefore accept that we do not operate in an ideal world and accept the risk of taking on projects with specifications that are far from idea. It is therefore essential that there is a good working relationship between the software development team and the client?s project manager. We work hard about building a relationship during the early stages, explaining the project managers responsibilities and stressing the work load required to complete the project, not only for the project manager, but other staff within the clients business.
The biggest issue having nurtured a good relationship? is a change of project manager part way through a project. It is imperative for the incoming project manage to get up to speed and work with the development team to understand the background of the project, but this doesn't always happen and can present challenges further down the road, when the expectations set with the original project manage are lost and the incoming project manager has their own set of expectations that often are completely unknown to the development team. We always say: never surprise the client, never allow the client to surprise us but we still get the odd curve ball thrown at us, from time to time.
Conclusion
Whilst this isn't an exhaustive explanation of agile development, it highlights the potential issues software development teams and clients face when adopting any of the agile methodologies: Extreme Programming, Scrum, DSDM, Lean or FDD. As long as all the stake holders are actively involved and are working to a common objective, agile is an ideal approach.
In our experience one shared by colleagues in other software development teams when projects fail the client always looks to blame the software development team and over looks their own failings, a truism in most cases where blame is used as an avoidance technique. It is essential that the blame game is avoided, but this isn't always possible, where ulterior motives are at play. As a project manager with over twenty five years experience, both as a lead / senior software developer and project manager for the last 15 years, I get a sixth sense when troubles lays ahead and work to strike compromise and seek resolution, but alas from time to time this isn't possible and that is when project fail!
Date: 13/10/2017
An agile approach software development pros and cons
Whilst researching this article I found the following statement that at first shocked me, but on reflection wasnt a surprise:
According to the Standish Groups famous CHAOS Report of 2000, 25% of all projects still fail outright through eventual cancellation, with no useful software deployed. Sadly, this represents a big improvement over CHAOS reports from past years. And now there is more evidence of the same kind. In Agile and Iterative Development: a Managers Guide, renowned consultant and author Craig Larman does a thorough job of debunking the traditional waterfall model once and for all.
https://www.versionone.com/agile-101/agile-software-development-benefits/
Over the last 15 years we have developer over a 200 software applications and it is always disheartening when a solution isn't implemented within a business, for whatever reason. Sometimes, it's down to change management or simply user resistance, which is why we encourage all stakeholders to take an active role during the development, right from the start line, during the creation of the business requirements.
In nearly all cases we can attribute a lack of active participation during the capturing of the business requirements, project development and User Acceptance Testing (UAT) to projects failing. We've seen 4 fail, for this very reason; that's 2% and well under the figure suggested the CHAOS report. The other barrier to implementation is the pain a business had to go through in order to implement the solution; e.g. data migration, especially where data is dispersed across multiple sources across the business.
Three or four years ago, we developed a solution for a coaching business and we thought the project was going to fail, as when we got to the data migration and asked for the business contact details they looked in horror and said that they were spread out across the entire business on each individuals laptops! They had no centralised location where their client data was stored. You might be horrified at this, but it is something we see time and time again and is one of the benefits to having a bespoke solutions that gathers all your business data, enabling you to get far better transparency and Business Intelligence (BI) for decision making.
What is agile software development?
Agile software development is founded on evolutionary project management that enables the development process to adapt to changing requirements. This is in direct contradiction with traditional approaches of software development, whereby a specification was agreed upfront prior to the software development and was rigidly stuck too.
Agile software development is adaptive, able to cope with changes with business requirements (up to a certain point)! Its foundations are rooted in Rapid Application Development (RAD) methodologies from the nineteen nineties when developers used RAD Tools like Microsofts Visual Studio and Borlands Delphi, both of which supported Object Orientated Programming (OOP) languages that enable applications to be extended; i.e. adapted and changed to introduce new business requirements.
Agile provides:
- Improved visibility of software development with regular alpha releases.
- Far better adaptability; able to integrate changes to the business requirements.
- Greater value to the business, as they are able to access and utilise the solution far sooner, even if its not complete.
- Less risk, as they can see the progress of development.
So, why would an agile approach fail?
The single biggest reason an agile approach fails is lack client engagement. As a business we use an agile approach to software development and can start development, even where the business requirements are not complete. We need to have a high level list of requirements thrashed out, but we can capture the details during the development process.
In an ideal world we'll know a lot about the business and can make educated assumptions about how each process should work, but this needs the active involvement in the project development stage, as we'll need to discuss the finer details with the project manager. We'll often seek clarification and / or agreement of specific points, as we want to avoid re-writing code to integrate changes to elements like on screen and email copy, e.g. a sales receipt or order confirmation generated by the solution.
However, we predominantly work with small businesses that are constant struggling with resources, be they human or otherwise. We therefore accept that we do not operate in an ideal world and accept the risk of taking on projects with specifications that are far from idea. It is therefore essential that there is a good working relationship between the software development team and the client?s project manager. We work hard about building a relationship during the early stages, explaining the project managers responsibilities and stressing the work load required to complete the project, not only for the project manager, but other staff within the clients business.
The biggest issue having nurtured a good relationship? is a change of project manager part way through a project. It is imperative for the incoming project manage to get up to speed and work with the development team to understand the background of the project, but this doesn't always happen and can present challenges further down the road, when the expectations set with the original project manage are lost and the incoming project manager has their own set of expectations that often are completely unknown to the development team. We always say: never surprise the client, never allow the client to surprise us but we still get the odd curve ball thrown at us, from time to time.
Conclusion
Whilst this isn't an exhaustive explanation of agile development, it highlights the potential issues software development teams and clients face when adopting any of the agile methodologies: Extreme Programming, Scrum, DSDM, Lean or FDD. As long as all the stake holders are actively involved and are working to a common objective, agile is an ideal approach.
In our experience one shared by colleagues in other software development teams when projects fail the client always looks to blame the software development team and over looks their own failings, a truism in most cases where blame is used as an avoidance technique. It is essential that the blame game is avoided, but this isn't always possible, where ulterior motives are at play. As a project manager with over twenty five years experience, both as a lead / senior software developer and project manager for the last 15 years, I get a sixth sense when troubles lays ahead and work to strike compromise and seek resolution, but alas from time to time this isn't possible and that is when project fail!
Date: 13/10/2017
