Embracing change
At the core of Agile principles is the understanding that change is an inevitable – and essential – part of any business. Market needs evolve, project funding gets reallocated and staff move on. An organization which expects and embraces change in customer requirements, market demand, supply chain provision and internal resource availability has a significant competitive advantage over less responsive organizations.
Responsive planning
Responsive planning to accommodate inevitable internal and external changes is at the heart of Agile approaches. Because change is an inevitable part of business, Agile approaches avoid creating extensive upfront documents that endeavor to predict business requirements, costs and timeframes over the long term. Instead, Agile approaches are based around the iterative delivery of business value in short timeframes (usually every two to four weeks), with ongoing planning based on the feedback received from key stakeholders at each iteration. This drive for responsive planning is most succinctly described in the Agile philosophy: “Apply, Inspect, Adapt.” Responsive planning allows for changes in the business environment (e.g. a change in market demand) to be almost immediately reflected in the iterative activities undertaken by staff members – instead of waiting several weeks (and sometimes months) for an updated plan to be agreed, released and implemented.
Frequent and continuous business value
The goal of each Agile iteration is to provide stakeholders with frequent and continuous business value, so that the organization can benefit more quickly from their investment in money, people and time. Agile approaches are designed so that each iterative delivery contains the highest-priority items identified by the business to the greatest extent that can be provided in the time allocated. This results in each deliverable having immediate value for the business, thus maximizing the effort of each resource to focus on high priority activities, and minimizing the likelihood of unnecessary work being done.
Importantly, Agile approaches also provide the organization with the opportunity to review tangible outputs at each delivery point, to redirect efforts (where required), and to determine whether further budget expenditure should be focused on additional work in this area – or reallocated to higher priority business activities across the organization.
Direct stakeholder engagement
So, how do Agile delivery teams ensure that their deliverables continuously meet the needs of the organization? The most effective way to ensure ongoing business value is to directly involve key internal and external stakeholders in the process. (When was the last time you included customer service representatives in the review of proposed products? Or invited prospective investors to comment on the draft annual plan?)
Representative stakeholders participate as active members of the Agile team during the process, providing the team with real-time input and hands-on feedback at two key points in the process:
» at the start of each iteration to describe and prioritize their business requirements
» at the end of each iteration to review and assess outputs against their stated requirements.
Ideally, these stakeholders are also able to make themselves available to the team during each iteration, to respond to questions and review work while it is being completed. The more available stakeholders are to the Agile team throughout the process, the closer that each deliverable will be to meeting the true needs of the organization. However, Agile approaches are also realistic in understanding that the full-time allocation of a key internal resource – or ongoing availability of an external customer – is not always possible. The objective for an Agile organization is to create this opportunity wherever possible, but no less than at the start and end of each iteration.
Regular face-to-face communication
Agile approaches strongly advocate that the most effective way to actively involve stakeholders in the process is through face-to-face communication (which can include online meetings where required). The underlying premise is that business requirements are most clearly stated (and clarified) in a forum where people can
» respond to each other in real-time
» draw diagrams on a whiteboard that others can immediately provide feedback on
» get a firsthand perspective on each stakeholder’s reaction.
Conference calls and e-mails can be used (where required) to clarify ongoing questions during the iteration; but the description of the business requirements at the start of each iteration – and review of outputs at the end of each iteration – require physical (or virtual) face-to-face communication in order for these sessions to be effective. In the Agile world, there is no point where a pile of documentation is an acceptable substitute for active face-to-face communication.
Minimizing waste
The Agile imperative to deliver the highest business value possible in a short timeframe results in the added benefit of minimizing waste in work undertaken. Effort is not expended on low priority items that are less likely to be needed by the business, resulting in a reduced likelihood of over-production by the team. Regular feedback from stakeholders helps to ensure that ongoing efforts continue to be focused on the highest value activities. Short timeframes also mean that, even if the team goes slightly off-track in one iteration, the cost to the organization is contained. Activities can be ended when the team has delivered every outcome that the organization considers essential – versus maintaining teams to meet predetermined timeframes or budget allocations.
Agile approaches also minimize waste by encouraging employees to make business processes and deliverables as efficient as possible. This not only assists employees in delivering value within a short timeframe; it allows these processes and deliverables to be more readily reused and expanded upon in the future.
Tangible outputs
Agile methods work on the basis that the best way to measure the progress of work is not to create endless status reports, but to review the tangible outputs of the work as the primary measure of progress. Status reports are often time-consuming, generally sanitized for management review and can be designed to give the reader a false sense of security that things are progressing on track. Tangible outputs, on the other hand, are irrefutable indicators of the ongoing success or failure of each Agile team’s activities.
Most important, however, is the effect that producing tangible outputs has on the way in which Agile teams undertake their work. The drive to deliver tangible outputs in short iterations forces the team to touch on every stage of the delivery process, from planning and design to quality control, packaging and presentation. It forces the team to avoid endless planning meetings and infinite rethinking of ideas before action is taken. It requires the team to go through every stage of the process upfront, providing an early identification of risks and hurdles that are likely to impact ongoing delivery. Arguably the most valuable outcome, it gives team members the satisfaction of regularly seeing tangible results from their efforts, providing them with inspiration and motivation for their ongoing work.
Empowering the team
Agile approaches rely on the mutual trust (and dependency) that emerges between stakeholders and delivery team members: delivery teams depend upon the expertise of stakeholders to accurately communicate and prioritize the business requirements; and stakeholders equally depend upon the expertise of the delivery team members to regularly produce outcomes that meet these requirements. If either group falters, the process fails.
It is this interdependency that makes Agile approaches so compelling for employees. Stakeholders are responsible for guiding the business priorities and for measuring the outcomes of each iteration, but they are not the people who determine the volume of work that can be achieved in that short timeframe. Instead, stakeholders defer to the multi skilled delivery team to advise them on the actual work required to achieve their objectives, the estimated time for each task, and what the delivery team can realistically achieve in an iteration given their current workload and other commitments.
The structure of Agile approaches also means that stakeholders do not need to keep a close watch of every step that the delivery team makes, because they know that they are never more than a few weeks away from seeing the results of their work. Throughout each iteration, stakeholders also have the ability to both sit in on the delivery team’s daily status reviews and to monitor the overall progress of the team through real-time status tracking tools. This means that stakeholders can be confident that work is progressing without having to constantly monitor the delivery team, and delivery team members are entrusted, empowered and left alone to do the work that they have committed to.
The interesting thing about this dynamic is that, as it progresses, it is able to feed off itself to create ongoing motivation for employees. Delivery team members know that their continued ability to self-manage their work depends on their regular delivery of high-value business outcomes. Additionally, because they are the ones who identify what work can (and cannot) be achieved in each iteration, they are motivated by their personal responsibility to achieve these outcomes. This combination of factors is heightened by the satisfaction and pride that delivery team members feel when they produce tangible outputs that truly meet the needs of the organization.
Quality by design
The requirement for Agile delivery teams to regularly deliver tangible outputs in each iteration makes quality control essential throughout the process. In order to be able to respond to stakeholders in short timeframes, deliverables must be designed to accommodate ongoing change. Agile teams learn early on that maintaining quality, flexibility and extensibility of deliverables is critical in their ongoing ability to be responsive to change without impacting their levels of productivity. This knowledge drives Agile teams to build in quality by design in everything they deliver – not only to avoid the problems that can occur when faulty deliverables are handed over, but to reduce the impacts of low quality on their own work (and ongoing ability to self manage) in the future.
Continuous improvement
The “Apply, Inspect, Adapt” philosophy, which underpins Agile approaches, provides the organization with a proven method for continuous improvement on an ongoing basis. Performance improvement is not reserved for annual employee reviews; it occurs as part of the review at the end of each iteration. Teams use Agile tools to monitor their own progress during each iteration. Management is provided with real-time progress monitors to measure the advancement of work against the organization’s objectives. The very nature of Agile approaches is to continuously review and improve the work that is being undertaken, to ensure that the organization is focused on delivering the highest value outcomes at a regular and sustained pace. The active involvement of stakeholders throughout the process ensures that these deliverables genuinely meet the needs of the organization, and allows for real-time adjustment of the work if these objectives are not being met.
Agile in action
Although the core principles that underpin Agile approaches can deliver benefits in every market sector, there are currently two industries at the forefront in their use of Agile approaches: information technology (IT) and manufacturing. Several prominent organizations in these industries have publicly documented their success in using Agile approaches, including Google, Yahoo!, Nokia Siemens Networks and Microsoft.
The prominence of Agile approaches in these two industries can be attributed to a number of factors, most notably the fact that the most vocal proponents of Agile approaches have tended to come from more technical backgrounds – resulting in the information regarding these practices generally being presented only in a technical context. There is, however, another compelling issue which has driven the widespread adoption of Agile practices across the IT industry specifically – and understanding this issue is the key to understanding why Agile approaches are powerful strategies for every industry.
In the 1990s, the IT industry was plagued by the remarkably high failure rate of software development projects: projects that became notorious for their missed deadlines, substantially overrun budgets, faulty deliverables and dissatisfied customers. A handful of thought leaders in the industry believed that these IT project failures could be attributed to three key factors: over-planning, insufficient communication and “all-at-once” delivery.
Over-planning
IT software projects traditionally began with the production of extensive “upfront” documentation, including project plans, functional requirements, system design specifications and technical architectural designs. These documents, which often took months to produce (and even longer to get approved), were intended to ensure that the developed software would align with user requirements. In reality, however, these documents only served to provide corporate managers with a false sense of security in the expenditure of their IT budgets; and to ensure that delivered software would be substantially misaligned with the ongoing – and changing – needs of the business.
One of the biggest problems was that, by the time these big upfront documents were finalized, nearly everything about the proposed project was likely to have changed, including user requirements, market demand, internal resource availability and the capabilities of the underlying technologies. The time required to revisit and adapt these documents would have resulted in even further delays to the project. So, development work was undertaken against plans and designs that were clearly outdated on the first day, and significantly more outdated by the time that the software was delivered.
Another key problem in the industry’s use of “big upfront documents” was the inevitable misalignment between text descriptions of the user’s needs and the resulting software. Users who provided input into these documents often fell into two common traps:
» not clearly articulating their requirements
» wanting everything under the sun in an effort to guarantee that any requirement they could possibly have in the future would be supported in the software. (Given the amount of time it took to deliver the software, who could blame them?)
Both of these factors ensured that the big upfront design documents were saddled with unclear requirements (which were left to the discretion of the technical team to interpret), or with highly critical business requirements lost in a sea of extraneous requirements. Most importantly, these documents ignored the simple fact that products which look good on paper may not always have the same appeal when presented on the screen. The bottom line is that software products delivered to meet these design documents were destined to fail – and businesses were losing millions in the process.
Insufficient communication
The second overwhelming driver in the ongoing failure of software development projects in the 1990s was the traditional – and often deliberate – separation of the business areas that required the software and the technical staff responsible for delivering the solution (i.e. development in a vacuum).
Once the big upfront design documents for an IT project were finalized, they were generally handed over to the technical team for development. The technical team was then sent back to their desks (often located in a separate section, floor or even building from the business areas), with a pile of paper and an immutable deadline. The next time that the technical team interacted with the business area was when they installed the resulting software on the users’ machines for acceptance testing.
This isolation between the users with the business knowledge and the technical team tasked with delivering the software, created inevitable issues with the resulting software, including:
» user requirements left to the interpretation of the technical team members, without the benefit of understanding the business context
» the inevitable disconnect between the two-dimensional concept proposed in the documentation and the manifestation of that concept into tangible screens that the user could interact with
» not allowing for changes to business requirements that may have occurred between the time that the user was last consulted and the months (and sometimes years) that followed before the resulting software was installed on their system.
All of these factors resulted in the delivery of software that was frequently misaligned to the needs of the business users, including inadequate workflows, system errors, critical design flaws and features that were rarely (or never) used by the business – with no remaining budget or resources available to address these issues.
“All-at-once” delivery
Software development projects in the 1990s depended heavily on “waterfall” project management techniques, where analysis, design, development, testing and delivery stages are undertaken serially, requiring the full completion of one activity before the next one can begin. The use of waterfall techniques on these projects meant that software design could not begin until all of the requirements analysis was complete; software testing could not begin until software development was complete; and software was not delivered to the users until all of the preceding stages had been completed.
This use of waterfall approaches in the IT industry was intended to reduce business risk in project delivery, requiring each step to be completed to management’s satisfaction before further spending was incurred. In reality, waterfall approaches significantly increased the risk of IT project failure by:
» mandating big upfront documentation (with all of its related issues)
» discouraging responsiveness to changing requirements as the project evolved
» creating “silos” of ownership that reduced communication across project team members.
Perhaps the most risky impact of these waterfall approaches was delaying the delivery of tangible business outcomes until the very end of the project – when problems in the software are the most evident and changes to the software are the most costly.
Instead of enabling the organization to manage expenditures and risks throughout the software development project, executives were faced with an all-ornothing proposition: keep pouring resources into a failing IT project, so that at least some value can be recovered from the previous investment, or end the project midstream and receive no tangible benefit to the organization. The “all-at-once” delivery approach often left these executives with no other options.
There were, of course, other factors that influenced the high failure rate of software development projects in the 1990s, including limitations in technology and the lack of availability of skilled technical resources. However, the three issues outlined above – over-planning, insufficient communication and “all-at-once” delivery – were factors that were within the control of the organization to change.
Thankfully, a group of innovative thought leaders22 at the time realized the power that Agile approaches could bring to the IT industry. Their insights revolutionized the way in which software is currently developed worldwide.
Source of Information : IT Governance Publishing-Agile Productivity Unleashed 2010
At the core of Agile principles is the understanding that change is an inevitable – and essential – part of any business. Market needs evolve, project funding gets reallocated and staff move on. An organization which expects and embraces change in customer requirements, market demand, supply chain provision and internal resource availability has a significant competitive advantage over less responsive organizations.
Responsive planning
Responsive planning to accommodate inevitable internal and external changes is at the heart of Agile approaches. Because change is an inevitable part of business, Agile approaches avoid creating extensive upfront documents that endeavor to predict business requirements, costs and timeframes over the long term. Instead, Agile approaches are based around the iterative delivery of business value in short timeframes (usually every two to four weeks), with ongoing planning based on the feedback received from key stakeholders at each iteration. This drive for responsive planning is most succinctly described in the Agile philosophy: “Apply, Inspect, Adapt.” Responsive planning allows for changes in the business environment (e.g. a change in market demand) to be almost immediately reflected in the iterative activities undertaken by staff members – instead of waiting several weeks (and sometimes months) for an updated plan to be agreed, released and implemented.
Frequent and continuous business value
The goal of each Agile iteration is to provide stakeholders with frequent and continuous business value, so that the organization can benefit more quickly from their investment in money, people and time. Agile approaches are designed so that each iterative delivery contains the highest-priority items identified by the business to the greatest extent that can be provided in the time allocated. This results in each deliverable having immediate value for the business, thus maximizing the effort of each resource to focus on high priority activities, and minimizing the likelihood of unnecessary work being done.
Importantly, Agile approaches also provide the organization with the opportunity to review tangible outputs at each delivery point, to redirect efforts (where required), and to determine whether further budget expenditure should be focused on additional work in this area – or reallocated to higher priority business activities across the organization.
Direct stakeholder engagement
So, how do Agile delivery teams ensure that their deliverables continuously meet the needs of the organization? The most effective way to ensure ongoing business value is to directly involve key internal and external stakeholders in the process. (When was the last time you included customer service representatives in the review of proposed products? Or invited prospective investors to comment on the draft annual plan?)
Representative stakeholders participate as active members of the Agile team during the process, providing the team with real-time input and hands-on feedback at two key points in the process:
» at the start of each iteration to describe and prioritize their business requirements
» at the end of each iteration to review and assess outputs against their stated requirements.
Ideally, these stakeholders are also able to make themselves available to the team during each iteration, to respond to questions and review work while it is being completed. The more available stakeholders are to the Agile team throughout the process, the closer that each deliverable will be to meeting the true needs of the organization. However, Agile approaches are also realistic in understanding that the full-time allocation of a key internal resource – or ongoing availability of an external customer – is not always possible. The objective for an Agile organization is to create this opportunity wherever possible, but no less than at the start and end of each iteration.
Regular face-to-face communication
Agile approaches strongly advocate that the most effective way to actively involve stakeholders in the process is through face-to-face communication (which can include online meetings where required). The underlying premise is that business requirements are most clearly stated (and clarified) in a forum where people can
» respond to each other in real-time
» draw diagrams on a whiteboard that others can immediately provide feedback on
» get a firsthand perspective on each stakeholder’s reaction.
Conference calls and e-mails can be used (where required) to clarify ongoing questions during the iteration; but the description of the business requirements at the start of each iteration – and review of outputs at the end of each iteration – require physical (or virtual) face-to-face communication in order for these sessions to be effective. In the Agile world, there is no point where a pile of documentation is an acceptable substitute for active face-to-face communication.
Minimizing waste
The Agile imperative to deliver the highest business value possible in a short timeframe results in the added benefit of minimizing waste in work undertaken. Effort is not expended on low priority items that are less likely to be needed by the business, resulting in a reduced likelihood of over-production by the team. Regular feedback from stakeholders helps to ensure that ongoing efforts continue to be focused on the highest value activities. Short timeframes also mean that, even if the team goes slightly off-track in one iteration, the cost to the organization is contained. Activities can be ended when the team has delivered every outcome that the organization considers essential – versus maintaining teams to meet predetermined timeframes or budget allocations.
Agile approaches also minimize waste by encouraging employees to make business processes and deliverables as efficient as possible. This not only assists employees in delivering value within a short timeframe; it allows these processes and deliverables to be more readily reused and expanded upon in the future.
Tangible outputs
Agile methods work on the basis that the best way to measure the progress of work is not to create endless status reports, but to review the tangible outputs of the work as the primary measure of progress. Status reports are often time-consuming, generally sanitized for management review and can be designed to give the reader a false sense of security that things are progressing on track. Tangible outputs, on the other hand, are irrefutable indicators of the ongoing success or failure of each Agile team’s activities.
Most important, however, is the effect that producing tangible outputs has on the way in which Agile teams undertake their work. The drive to deliver tangible outputs in short iterations forces the team to touch on every stage of the delivery process, from planning and design to quality control, packaging and presentation. It forces the team to avoid endless planning meetings and infinite rethinking of ideas before action is taken. It requires the team to go through every stage of the process upfront, providing an early identification of risks and hurdles that are likely to impact ongoing delivery. Arguably the most valuable outcome, it gives team members the satisfaction of regularly seeing tangible results from their efforts, providing them with inspiration and motivation for their ongoing work.
Empowering the team
Agile approaches rely on the mutual trust (and dependency) that emerges between stakeholders and delivery team members: delivery teams depend upon the expertise of stakeholders to accurately communicate and prioritize the business requirements; and stakeholders equally depend upon the expertise of the delivery team members to regularly produce outcomes that meet these requirements. If either group falters, the process fails.
It is this interdependency that makes Agile approaches so compelling for employees. Stakeholders are responsible for guiding the business priorities and for measuring the outcomes of each iteration, but they are not the people who determine the volume of work that can be achieved in that short timeframe. Instead, stakeholders defer to the multi skilled delivery team to advise them on the actual work required to achieve their objectives, the estimated time for each task, and what the delivery team can realistically achieve in an iteration given their current workload and other commitments.
The structure of Agile approaches also means that stakeholders do not need to keep a close watch of every step that the delivery team makes, because they know that they are never more than a few weeks away from seeing the results of their work. Throughout each iteration, stakeholders also have the ability to both sit in on the delivery team’s daily status reviews and to monitor the overall progress of the team through real-time status tracking tools. This means that stakeholders can be confident that work is progressing without having to constantly monitor the delivery team, and delivery team members are entrusted, empowered and left alone to do the work that they have committed to.
The interesting thing about this dynamic is that, as it progresses, it is able to feed off itself to create ongoing motivation for employees. Delivery team members know that their continued ability to self-manage their work depends on their regular delivery of high-value business outcomes. Additionally, because they are the ones who identify what work can (and cannot) be achieved in each iteration, they are motivated by their personal responsibility to achieve these outcomes. This combination of factors is heightened by the satisfaction and pride that delivery team members feel when they produce tangible outputs that truly meet the needs of the organization.
Quality by design
The requirement for Agile delivery teams to regularly deliver tangible outputs in each iteration makes quality control essential throughout the process. In order to be able to respond to stakeholders in short timeframes, deliverables must be designed to accommodate ongoing change. Agile teams learn early on that maintaining quality, flexibility and extensibility of deliverables is critical in their ongoing ability to be responsive to change without impacting their levels of productivity. This knowledge drives Agile teams to build in quality by design in everything they deliver – not only to avoid the problems that can occur when faulty deliverables are handed over, but to reduce the impacts of low quality on their own work (and ongoing ability to self manage) in the future.
Continuous improvement
The “Apply, Inspect, Adapt” philosophy, which underpins Agile approaches, provides the organization with a proven method for continuous improvement on an ongoing basis. Performance improvement is not reserved for annual employee reviews; it occurs as part of the review at the end of each iteration. Teams use Agile tools to monitor their own progress during each iteration. Management is provided with real-time progress monitors to measure the advancement of work against the organization’s objectives. The very nature of Agile approaches is to continuously review and improve the work that is being undertaken, to ensure that the organization is focused on delivering the highest value outcomes at a regular and sustained pace. The active involvement of stakeholders throughout the process ensures that these deliverables genuinely meet the needs of the organization, and allows for real-time adjustment of the work if these objectives are not being met.
Agile in action
Although the core principles that underpin Agile approaches can deliver benefits in every market sector, there are currently two industries at the forefront in their use of Agile approaches: information technology (IT) and manufacturing. Several prominent organizations in these industries have publicly documented their success in using Agile approaches, including Google, Yahoo!, Nokia Siemens Networks and Microsoft.
The prominence of Agile approaches in these two industries can be attributed to a number of factors, most notably the fact that the most vocal proponents of Agile approaches have tended to come from more technical backgrounds – resulting in the information regarding these practices generally being presented only in a technical context. There is, however, another compelling issue which has driven the widespread adoption of Agile practices across the IT industry specifically – and understanding this issue is the key to understanding why Agile approaches are powerful strategies for every industry.
In the 1990s, the IT industry was plagued by the remarkably high failure rate of software development projects: projects that became notorious for their missed deadlines, substantially overrun budgets, faulty deliverables and dissatisfied customers. A handful of thought leaders in the industry believed that these IT project failures could be attributed to three key factors: over-planning, insufficient communication and “all-at-once” delivery.
Over-planning
IT software projects traditionally began with the production of extensive “upfront” documentation, including project plans, functional requirements, system design specifications and technical architectural designs. These documents, which often took months to produce (and even longer to get approved), were intended to ensure that the developed software would align with user requirements. In reality, however, these documents only served to provide corporate managers with a false sense of security in the expenditure of their IT budgets; and to ensure that delivered software would be substantially misaligned with the ongoing – and changing – needs of the business.
One of the biggest problems was that, by the time these big upfront documents were finalized, nearly everything about the proposed project was likely to have changed, including user requirements, market demand, internal resource availability and the capabilities of the underlying technologies. The time required to revisit and adapt these documents would have resulted in even further delays to the project. So, development work was undertaken against plans and designs that were clearly outdated on the first day, and significantly more outdated by the time that the software was delivered.
Another key problem in the industry’s use of “big upfront documents” was the inevitable misalignment between text descriptions of the user’s needs and the resulting software. Users who provided input into these documents often fell into two common traps:
» not clearly articulating their requirements
» wanting everything under the sun in an effort to guarantee that any requirement they could possibly have in the future would be supported in the software. (Given the amount of time it took to deliver the software, who could blame them?)
Both of these factors ensured that the big upfront design documents were saddled with unclear requirements (which were left to the discretion of the technical team to interpret), or with highly critical business requirements lost in a sea of extraneous requirements. Most importantly, these documents ignored the simple fact that products which look good on paper may not always have the same appeal when presented on the screen. The bottom line is that software products delivered to meet these design documents were destined to fail – and businesses were losing millions in the process.
Insufficient communication
The second overwhelming driver in the ongoing failure of software development projects in the 1990s was the traditional – and often deliberate – separation of the business areas that required the software and the technical staff responsible for delivering the solution (i.e. development in a vacuum).
Once the big upfront design documents for an IT project were finalized, they were generally handed over to the technical team for development. The technical team was then sent back to their desks (often located in a separate section, floor or even building from the business areas), with a pile of paper and an immutable deadline. The next time that the technical team interacted with the business area was when they installed the resulting software on the users’ machines for acceptance testing.
This isolation between the users with the business knowledge and the technical team tasked with delivering the software, created inevitable issues with the resulting software, including:
» user requirements left to the interpretation of the technical team members, without the benefit of understanding the business context
» the inevitable disconnect between the two-dimensional concept proposed in the documentation and the manifestation of that concept into tangible screens that the user could interact with
» not allowing for changes to business requirements that may have occurred between the time that the user was last consulted and the months (and sometimes years) that followed before the resulting software was installed on their system.
All of these factors resulted in the delivery of software that was frequently misaligned to the needs of the business users, including inadequate workflows, system errors, critical design flaws and features that were rarely (or never) used by the business – with no remaining budget or resources available to address these issues.
“All-at-once” delivery
Software development projects in the 1990s depended heavily on “waterfall” project management techniques, where analysis, design, development, testing and delivery stages are undertaken serially, requiring the full completion of one activity before the next one can begin. The use of waterfall techniques on these projects meant that software design could not begin until all of the requirements analysis was complete; software testing could not begin until software development was complete; and software was not delivered to the users until all of the preceding stages had been completed.
This use of waterfall approaches in the IT industry was intended to reduce business risk in project delivery, requiring each step to be completed to management’s satisfaction before further spending was incurred. In reality, waterfall approaches significantly increased the risk of IT project failure by:
» mandating big upfront documentation (with all of its related issues)
» discouraging responsiveness to changing requirements as the project evolved
» creating “silos” of ownership that reduced communication across project team members.
Perhaps the most risky impact of these waterfall approaches was delaying the delivery of tangible business outcomes until the very end of the project – when problems in the software are the most evident and changes to the software are the most costly.
Instead of enabling the organization to manage expenditures and risks throughout the software development project, executives were faced with an all-ornothing proposition: keep pouring resources into a failing IT project, so that at least some value can be recovered from the previous investment, or end the project midstream and receive no tangible benefit to the organization. The “all-at-once” delivery approach often left these executives with no other options.
There were, of course, other factors that influenced the high failure rate of software development projects in the 1990s, including limitations in technology and the lack of availability of skilled technical resources. However, the three issues outlined above – over-planning, insufficient communication and “all-at-once” delivery – were factors that were within the control of the organization to change.
Thankfully, a group of innovative thought leaders22 at the time realized the power that Agile approaches could bring to the IT industry. Their insights revolutionized the way in which software is currently developed worldwide.
Source of Information : IT Governance Publishing-Agile Productivity Unleashed 2010
|
|
0 comments
Post a Comment