Search

How To Define Agile Benefits For Business Sponsors?

“Agile” has been a buzzword in organizations of late.  Use of Agile methodologies results in continuous engagement of end users in the development process. Organization development processes are tailored to make them focused on accommodating change. Agile processes work well for both development teams and business sponsors. To make Agile appealing to organizations, possible benefits have to be articulated well. This would act as an incentive for business sponsors to consider Agile. This is of immense help especially at the beginning when organizations are in a dilemma about the use of Agile methodologies.  Buy in from business sponsors is critical as it results in continuous involvement of stakeholders and also helps to get the right product owners involved during the development process. Approach to define Agile benefits for software development project: The benefits from Agile could be seen on multiple parameters of a software development project.  To understand which parameter would appeal to a business sponsor, pre-work is needed to assess current performance of software development process. The performance should be understood in terms of Speed of delivery of scope, schedule adherence, cycle time, cost, quality of product and number of post-production issues. In addition to understanding current performance, some thought should also be given to the return on investment for a particular parameter. For example, an organization might be struggling with the issue of late delivery of products and cycle time could be a priority to bring in optimum return on investment.   In an adaptive or agile life cycle, the sponsor & customer reps should be continuously engaged with the project to provide feedback on deliverables as they are created and to ensure that the product backlog reflects their current needs. — Joelle A Godfrey (@jgodfrey) 29 December 2017 Above tweet from Joelle stresses the fact that sponsor should be continuously engaged with project and provide feedback on deliverables.  Table 1 represents the probable ask from business sponsor and the parameter to be picked up for improvement. Table 1 – Relationship between business sponsor ask and improvement parameter Based on feedback from business sponsor, a specific parameter could be the focus of improvement for Agile method implementation. Figure 1 shows the role of a Project Office and its contribution as a bridge between Development team and Business community. Figure 1 – Project Office (PO) as a bridge   I have taken a case study of an organization with issue of quality for delivered Information Technology (IT) system with a high number of issues after production rollout. This impacted the ability of users of the system to carry out their day-to-day business functions. Figure 1 indicates the number of issues for that system post implementation in production. The data is shown as week over week number after implementation of the newly developed system in production. Figure 2 – Post-implementation issues after production rollout   As can be seen from figure 2, the number of issues post implementation were high. It took almost 10 weeks to get the number of issues under control. A high number of issues also resulted in IT teams continuously working on fixing issues. Business users were unable to use the system effectively because of constant flow of issues for multiple weeks.  For the newly developed system continuous post-production issues also resulted in lack of interest on part of the users to promote the usage. This did not help change management and migration to the new system. Users tended to get disillusioned by the new system and did not want to invest time in learning its functioning and features. In summary, high volume of post-implementation issues resulted in failure of newly built system to gain traction with business users. For this case study, a deep dive was performed to understand the issues related to post-implementation defects. Following were identified as root causes: Lack of understanding of business analysts for actual user needs Lack of participation of business users in reviews for requirement sign off Lack of participation of business users in initial testing of new features Lack of usability testing of newly developed features Lack of phase-wise development for features, development of all features completed and then only business users were involved for testing  Compressed timeline for testing resulting in less focus on performance and operability testing Armed with the above analysis, a discussion was scheduled with the business sponsor. Questions were asked about the priority for the organization. This would enable to focus on the right return on investment parameter for use of Agile practice. In the long run, the usage of Agile methodologies would have positive influence on multiple parameters. However, to begin with, specific parameters should be focused to get benefits with respect to most pressing issue.  Business sponsor mentioned that he would like to focus on quality of product to reduce post-implementation issues and improve ease of use of new features, to begin with. The focus should be on these parameters.  An analysis of post-production defects was done. The analysis pointed to a high number of defects for some specific features involving multiple paths to accomplish same business functionality. This needed discussions with business users to make sure they are aware of how the business functions are to be used and how a standard training package could be developed for a larger community of business users. With respect to usability of the product, special attention needed to be given to a set of test cases pertaining to usability. Assessment of usability of the product had to be carried out as a part of usability testing. Feedback from business users had to be incorporated during development and testing.   In the case organization, Agile scrum was chosen as Agile methodologies to be used for implementation of upcoming product. The team was trained in the usage of Scrum methodology. Appropriate roles were assigned to the identified team members. The team took time to get started as it was a new process. Specific areas identified during the discussion with business sponsor were kept as priority areas of improvement and Agile sprint plans were made in line with specific outcomes in mind. Each sprint took up development of a business feature. Business users could get an early preview of what is coming up in the new product. They provided feedback about specific changes and usability of the product. These feedbacks and suggestions were incorporated in upcoming sprints. Constant communication and interaction with business users helped to create an environment of teamwork and trust. Business users also helped to create a training plan for the product for rolling out to larger organization and community of business users. After complete development and thorough testing the product was released to production. There were very few issues in post-production. The comparison of post-production issues is shown below. Figure 3 – Comparison of post-production issues before and after Agile implementation   As seen from Fig. 3, there were very few issues after Agile was implemented. The feedback from business users for usability was incorporated while testing was in progress. Business users also contributed to the training plan for a wider organization rollout. All this was possible because discussions with business sponsor helped to identify critical pain points, allowed mitigation actions and stated possible benefits from Agile implementation.  This case study showed that gathering feedback from business sponsor helps to identify priority areas of improvement when Agile is being implemented for the first time. Based on feedback from business sponsor, appropriate benefits could be identified and expected outcomes defined, keeping in mind the critical pain areas.  In summary: Early discussion with business sponsor contributed to the understanding of critical pain points Mitigation actions and focus areas were identified Possible benefits after Agile implantation were stated  Agile implementation was successful with perceived benefits being realized  
 How To Define Agile Benefits For Business Sponsors?
Raju Dhole
Rated 4.0/5 based on 20 customer reviews
How To Define Agile Benefits For Business Sponsors? 250
 How To Define Agile Benefits For Business Sponsors?

“Agile” has been a buzzword in organizations of late.  Use of Agile methodologies results in continuous engagement of end users in the development process. Organization development processes are tailored to make them focused on accommodating change. Agile processes work well for both development teams and business sponsors. To make Agile appealing to organizations, possible benefits have to be articulated well. This would act as an incentive for business sponsors to consider Agile. This is of immense help especially at the beginning when organizations are in a dilemma about the use of Agile methodologies.  Buy in from business sponsors is critical as it results in continuous involvement of stakeholders and also helps to get the right product owners involved during the development process.

Approach to define Agile benefits for software development project:

The benefits from Agile could be seen on multiple parameters of a software development project. 

To understand which parameter would appeal to a business sponsor, pre-work is needed to assess current performance of software development process. The performance should be understood in terms of Speed of delivery of scope, schedule adherence, cycle time, cost, quality of product and number of post-production issues. In addition to understanding current performance, some thought should also be given to the return on investment for a particular parameter. For example, an organization might be struggling with the issue of late delivery of products and cycle time could be a priority to bring in optimum return on investment.
 


Above tweet from Joelle stresses the fact that sponsor should be continuously engaged with project and provide feedback on deliverables. 

Table 1 represents the probable ask from business sponsor and the parameter to be picked up for improvement.

Table 1 – Relationship between business sponsor ask and improvement parameter


Based on feedback from business sponsor, a specific parameter could be the focus of improvement for Agile method implementation.

Figure 1 shows the role of a Project Office and its contribution as a bridge between Development team and Business community.

Figure 1 – Project Office (PO) as a bridge


 

I have taken a case study of an organization with issue of quality for delivered Information Technology (IT) system with a high number of issues after production rollout. This impacted the ability of users of the system to carry out their day-to-day business functions. Figure 1 indicates the number of issues for that system post implementation in production. The data is shown as week over week number after implementation of the newly developed system in production.

Figure 2 – Post-implementation issues after production rollout

 
As can be seen from figure 2, the number of issues post implementation were high. It took almost 10 weeks to get the number of issues under control. A high number of issues also resulted in IT teams continuously working on fixing issues. Business users were unable to use the system effectively because of constant flow of issues for multiple weeks. 

For the newly developed system continuous post-production issues also resulted in lack of interest on part of the users to promote the usage. This did not help change management and migration to the new system. Users tended to get disillusioned by the new system and did not want to invest time in learning its functioning and features.

In summary, high volume of post-implementation issues resulted in failure of newly built system to gain traction with business users.

For this case study, a deep dive was performed to understand the issues related to post-implementation defects. Following were identified as root causes:

  • Lack of understanding of business analysts for actual user needs
  • Lack of participation of business users in reviews for requirement sign off
  • Lack of participation of business users in initial testing of new features
  • Lack of usability testing of newly developed features
  • Lack of phase-wise development for features, development of all features completed and then only business users were involved for testing 
  • Compressed timeline for testing resulting in less focus on performance and operability testing

Armed with the above analysis, a discussion was scheduled with the business sponsor. Questions were asked about the priority for the organization. This would enable to focus on the right return on investment parameter for use of Agile practice. In the long run, the usage of Agile methodologies would have positive influence on multiple parameters. However, to begin with, specific parameters should be focused to get benefits with respect to most pressing issue. 

Business sponsor mentioned that he would like to focus on quality of product to reduce post-implementation issues and improve ease of use of new features, to begin with. The focus should be on these parameters. 

An analysis of post-production defects was done. The analysis pointed to a high number of defects for some specific features involving multiple paths to accomplish same business functionality. This needed discussions with business users to make sure they are aware of how the business functions are to be used and how a standard training package could be developed for a larger community of business users.

With respect to usability of the product, special attention needed to be given to a set of test cases pertaining to usability. Assessment of usability of the product had to be carried out as a part of usability testing. Feedback from business users had to be incorporated during development and testing.  

In the case organization, Agile scrum was chosen as Agile methodologies to be used for implementation of upcoming product. The team was trained in the usage of Scrum methodology. Appropriate roles were assigned to the identified team members. The team took time to get started as it was a new process. Specific areas identified during the discussion with business sponsor were kept as priority areas of improvement and Agile sprint plans were made in line with specific outcomes in mind. Each sprint took up development of a business feature. Business users could get an early preview of what is coming up in the new product. They provided feedback about specific changes and usability of the product. These feedbacks and suggestions were incorporated in upcoming sprints. Constant communication and interaction with business users helped to create an environment of teamwork and trust. Business users also helped to create a training plan for the product for rolling out to larger organization and community of business users. After complete development and thorough testing the product was released to production. There were very few issues in post-production. The comparison of post-production issues is shown below.

Figure 3 – Comparison of post-production issues before and after Agile implementation


 

As seen from Fig. 3, there were very few issues after Agile was implemented. The feedback from business users for usability was incorporated while testing was in progress. Business users also contributed to the training plan for a wider organization rollout. All this was possible because discussions with business sponsor helped to identify critical pain points, allowed mitigation actions and stated possible benefits from Agile implementation. 

This case study showed that gathering feedback from business sponsor helps to identify priority areas of improvement when Agile is being implemented for the first time. Based on feedback from business sponsor, appropriate benefits could be identified and expected outcomes defined, keeping in mind the critical pain areas. 

In summary:

  • Early discussion with business sponsor contributed to the understanding of critical pain points
  • Mitigation actions and focus areas were identified
  • Possible benefits after Agile implantation were stated 
  • Agile implementation was successful with perceived benefits being realized

 

Raju

Raju Dhole

Blog Author

Raju has 23+ years of IT Experience. He has a strong and diverse background in program, IT delivery, and financial management. He is an expert in project delivery using Agile methodologies and DevOps framework. He is a Recognized leader in innovation and transforming global teams. A strong communicator, he has proven ability to interact with multicultural and multi-location teams.  Raju has worked in multiple roles in Delivery Management, Client Relationship Management, Transition Management, Pre Sales, Business Strategy and Leadership Mentoring. 

Leave a Reply

Your email address will not be published. Required fields are marked *

Suggested Blogs

6 Compelling Benefits of (TDD) Test Driven Development

Introduction to Test Driven Development (TDD):  Test-driven development is a balanced approach for the programming perfectly blended with tightly interwoven three activities: coding, testing (writing unit tests) and designing (refactoring).  The revolutionary new age approach emphasizes on test-first development with the primary goal of correcting specification rather than the validation first. In other words, TDD is a smart approach to understand and streamline the requirements prior to writing the functional code in the line of Agile principles.  For most people trying to understand and implement Test Driven Development, the Certified Agile Tester Training has been found to be very much effective.  Two levels of TDD: TDD approach requires great discipline because the common tendency and traditional approaches inspire the programmers to “slip the test” and to write the functional code. To simplify the TDD implementation process, Agile TDD methodology can be categorized into two levels:  1.Acceptance TDD (ATDD): At this stage, you write the acceptance test specifying behavioral specifications, and then write the functionality/code. ATDD also termed as ‘Behavior Driven Development’ (BDD), neglecting the thin separating line over focus area, specifies the detailed and executable requirements for the acceptable solution on JIT- just in time basis.  2.Developer TDD: At this advanced level of TDD in Agile process, you write the developer test prior to writing the production code accordingly. The objective of TDD developer is to specify the detailed and practical design for the profitable solution on JIT basis.  6 Benefits of (TDD) Test Driven Development:  TDD has been the favorite approach of Agile organizations following the time-tested approaches to delivering the best quality product in a shorter period while securing the interests of all the stakeholders. It essentially bridges the gap between Development and Testing.  A survey conducted in 2010 confirmed that 53% Agile teams were following Developer TDD while 44% Agile teams were applying Acceptance TDD (ATDD) method. For the period of 7 years, Test Driven Development is getting massive popularity and the acceptance because of several behavioral and practical benefits; 6 key TDD benefits, driving the Agile teams to follow TDD methodology, are:     1.  The Best Level Acceptance:  TDD implementation helps the developers to understand the requirements from the perspective experience of clients. The test cases are designed without the constraints of architecture design or traditional programming approaches. TDD maximizes the possibility of developing the best quality product fulfilling the communicated needs of all the stakeholders. 2.   TDD - Customer-Centric Agile Process:  TDD process gets fit into the customer-centric agile methodology. The iteration for quality improvement is defined as the incorporation of new functionality against the model set of traditional practices or problem statements. 3.  Prompt Feedback:  The streamlined TDD process helps the project development team members to improve their delivering capability because of providing the immediate feedback on the developed components. The shorter feedback sharing loop squeezes the turnaround period for the elimination of identified defects; and, the outcome is comparatively much better than it is in traditional waterfall methodology.  4.   Extended Modulation for Small Units: TDD helps to create better modularized, extensible and flexible code. Test Driven Development approach drives the Agile team to plan, develop and test the small units to be integrated at advanced stage. Under this approach, the concerned member delivers and performs better because of being more focused on smaller unit.  5. Easy Anticipation & Identification of Voids:   Test Driven Development process provides a comprehensive toolset to test every line of coding; the best part is that the entire thing is checked automatically within minutes. The comprehensive test suite alerts for timely changes to save the efforts, time and cost. Even in case, you inherit the coding of an absent team member or you outsource the coding, TDD allows you to test the practical suitability in the line of specified requirements; provided, you have author code. Fast testing at each step helps you to anticipate and identify the possible voids and to fill up those with modified practices.      6. Programmers Feel More Confident By Continuous Achievement:  Looking at big targets sometimes disheartens the programmers because of involved complications. With TDD approach, every test instills the confidence of moving in right direction. Every test, sub-test and successfully completed component marks the win giving you clear picture of ‘what has been completed and what is remaining to be done?”.    Conclusion:  The scope of TDD benefits goes beyond the validation of correctness by step by step scaling. The organizations following TDD approach can easily make changes to current applications without disturbing the daily operations. The most organizations need to update the software to combat the challenges posed by continuous technology advancement and competitors; and, Agile TDD gives the businesses all the freedom to address new requirements or unforeseen variables.     
6 Compelling Benefits of (TDD) Test Driven Development
Author Image
Rated 4.0/5 based on 20 customer reviews
6 Compelling Benefits of (TDD) Test Driven Develop...

Introduction to Test Driven Development (TDD):  Test-driven develo... Read More

Establishing The Agile PMO

Long back, I posted an article on LinkedIn titled, Lessons Learned in Establishing a Project Management Office (PMO.) It centred around the discussion of plan-driven projects, typically manifested by the waterfall methodology.I subsequently spoke on this topic at a Project Management Institute (PMI®) chapter meeting and was asked to incorporate some thoughts on how the PMO might support adaptive or Agile methodologies. Having now helped establish several PMO’s, I’d like to share a few thoughts on this.Firstly, Agile is different philosophically in many ways than waterfall. One of the main tenets of the Agile Manifesto is "Working Software Over Comprehensive Documentation." This does not mean NO documentation; it just means that working software is valued more.Conversely, the plan-driven project typically relies heavily on documentation. And therefore, the waterfall-based PMO reflects this by having any number of templates, forms, and archived notes. So, for example, the well-stocked plan-driven PMO has templates for charters, risk registers, project management plans, etc.But in Agile, let's say specifically in the Scrum variant, the team requires artifacts such as product backlogs (essentially all the requirements), sprint backlogs (what activities you will perform during a sprint), and release plans (how many sprints you will need to perform). Often – outside of reporting – Agile teams don’t use much more than that.In the PMO’s in which I have been involved, we created these templates and put them in the repository, but, depending on the type of PMO it was, teams were free to use them or not as they decided.If teams in Agile are, by definition, self-organizing, what else besides templates might a PMO provide? Well, the best practices organizations will be able to provide Agile coaches to kick-start a project. As one Agile coach advised me, this helps create a mindset in the team right from the start. And of course, the PMO can then provide ongoing mentoring and training.This same coach advised that not all projects should be Agile. If a product that the team is creating is well-understood or the culture of that division does not support the Agile philosophy, the PMO can advise as to whether a project should be Agile. It should not impose its philosophy on every project.You might argue that the “world is going Agile.” In a very real sense, yes, it is. But there are any number of projects that have lent themselves for years to the waterfall methodology and continue to do so. A colleague of mine works for a telecommunications company and they are always rolling out new networks. This is such a well-understood technique that classic waterfall works quite well for them.One area in which the Agile PMO can assist is in gathering metrics. Since Agile is all about delivering value, how well teams deliver that value might be of interest. You can track and measure such things as a team's velocity, burn-up or burn-down rate.Since the Agile PMO has visibility across the organization, it has the unique ability to coordinate resources and best practices among teams. In a sense, it is an overseer of quality and resource management. Some organizations employ the concept of Scrum of Scrums, wherein Scrum Masters who are "ambassadors" from other teams regularly convene. The PMO could facilitate this get-together to share ideas, especially if teams are siloed.And while it is by no means known as an exemplar of agility, PMI recently published an Agile Practice Guide1. They noted three things about the Agile PMO that I agree are worthy of note:An Agile PMO is value-driven. It provides the right value at the right time, not imposing on its customers but working with them in a consultative fashion.An Agile PMO is invitation-oriented. A corollary of the first precept, the PMO is available to all in the organization but especially invites in those who find the concept and its services of value. Their interest makes them much more likely to engage.An Agile PMO is multidisciplinary. Not all PMOs are created equal. The more successful ones are centers of excellence and provide not only project management-related expertise but also advice in disciplines such as change management.Key point - if you're introducing Agile into a more traditional organization, try to do it in such a way that management is comfortable with the tools you're using. In one company that I consulted to, we made sure to use recognizable formats and templates wherever possible. People ask for change but nobody really likes it very much.These are just a few of the ideas that we (it's a team endeavor to set up a PMO), considered. In the instances where I've done this work, I've kept a copy of the Agile Manifesto handy. The takeaway here is to make sure that the Agile PMO is ....Agile!1. Agile Practice Guide, p. 81. ©2017, Project Management Institute, Inc.© Jim Stewart, PMP, CSM 2018
Establishing The Agile PMO
Author Image
Rated 4.0/5 based on 59 customer reviews
Establishing The Agile PMO

Long back, I posted an article on LinkedIn titled, Lessons Learned in ... Read More

Agile Project Management Vs. Traditional Project Management

In this fast-moving world, project management has become one of the most important pillars that are helping businesses run without any glitch in their processes. Companies – both big and small – around the world are exploiting technology and depending on project management systems to get their stuff done. Whether it is team workflow management or timing, these tools can ensure everything’s flowing as water without any hiccups. However, with technology comes limitations. While there are tens of different project management approaches, Agile is considered one of the most practical and flexible software development mechanism that exist today. It is capable of a variety of tasks, but what sets it apart from others? Let’s find out. Here’s a brief comparison between Agile and other traditional project management software: Overview of Agile When a traditional system focuses on upfront planning where factors like cost, scope, and time are given importance, Agile gives prominence to teamwork, customer collaboration, and flexibility. The basic concept behind Agile’s software development is that it delves on evolving changes and collaborative effort to bring out results rather than a predefined process.  Adaptive planning is perhaps the biggest feature of Agile and one that makes it a crowd favorite among project managers. Scrum and Kanban are two of the most widely used Agile frameworks. The former is known for encouraging decision-making and preventing time consumption on variables that are bound to change. It stresses on customer satisfaction and uses available teams to fast-track software development at every stage. Basic Comparison Points Following are the basic differences between Agile and traditional project management approaches: Agile focuses on adapting changes into its core plan and still being responsive. Other approaches usually require managers to control the changes Agile is all about the customer whereas other software put adherence to plans first It provides control to teams at all levels making them self-sufficient and self-manageable. Traditional ones go for top-to-bottom hierarchy, which often causes delays in the project Agile can be seen as an evolutionary process which gradually gathers speed and development. It is a total opposite of upfront planning  It bases its results on the value given to the customer. All other metrics are irrelevant for Agile Agile processes can be heavily customized, thus making them more inclusive. Can Agile Coexist with Other Approaches? This is a question asked by many project managers, and opinions of experts seem to be divided. While some say it is possible for Agile to coexist with traditional project management systems, they suggest being cautious and using them for different terms. For example, using two different approaches on the same project can be counter-productive and highly explosive. As Agile and most other frameworks are totally contrasting to each other, the projects may go for a toss. On the other hand, some experts believe that it is not possible for Agile and other tools to co-exist because of their contrast. Using them together can cause disorder in the entire company system, making the productivity to go for a toss. Why is Agile Preferred? Agile is preferred by most managers because of a variety of reasons. Let’s have a look at the most common ones: Divided Into Parts Agile divides a project into parts (called iterations) where the release is sent to the customer after every single iteration. Additionally, the success of the project can be easily foreseen through the success of these iterations. This removes the need of upfront planning completely. Self-organized As mentioned above, Agile uses a parallel mode of management. Employees of a company are not managed by a central line of control, but by groups. For example, in Agile, there may be eight teams working on a single project. Each team is managed by itself without external guidance. The teams only interact with each other for project discussion and process linking as they are otherwise not self-sufficient. Generally speaking, an Agile project consists of three parts: The product owner – the expert on the project (for which the product is being developed) and is the main person who oversees the projects The scrum master – this person manages the process involved in Agile. He/she looks after the iterations and its completion The team – individuals who play significant and minor roles in the software development process Customer Engagement In Agile, customer engagement is at the very top. The customer is regarded highly in its frameworks as after every iteration, feedback is generated and acted upon. Overall, Agile is clearly the winner among project management systems. When compared with other traditional approaches, Agile’s features come to the fore and reiterate why it is one of the top software used by companies globally.  
Agile Project Management Vs. Traditional Project Management
Author Image
Rated 4.0/5 based on 20 customer reviews
Agile Project Management Vs. Traditional Project M...

In this fast-moving world, project management has become one of the mo... Read More