The series so far:

1. Should You Consider Agile for Very Large IT Projects?
2. Providing the Necessary Tools and Reports for Very Large IT Projects

Requirements of large IT projects (typically, part of Transformation programs)

Many organizations often need to tackle several major changes to the IT that underpins their business simultaneously. This type of project is hard to deliver.

IT projects, like any other type of project, have a budget, delivery dates and requirements. What makes IT projects so unusual when compared to construction or engineering projects is that the scope and requirements change during the project. There is, to be sure, usually a small allowance in the budget for changes to the requirements, but the delivery time, typically nine months or less in an IT transformation, doesn’t change along with the changing requirements because this timeline must be met for the program objectives to stay relevant.

A large IT project will generally present some of the following challenges.

1. The requirements will be complex.
2. There will be a large number of requirements.
3. The End-to-end requirements will affect many systems and have a high interdependency
4. Many systems will be involved, sometimes requiring different skillsets.
5. There will be significant changes in many systems at the same time.
6. Some of the project resources are likely to belong to different companies and different cultures, and in different geographic locations.
7. With project size, the task of managing Integration Testing and end-to-end testing will increase exponentially.

All these challenges can be managed individually, but when they come together in one project then project design and execution becomes highly complex. It takes specialist skills and tremendous effort from all involved to keep such a project on track.

 

Software Development Models

Let’s take a brief look at software development models to provide the context.

Waterfall model

The Waterfall model of software delivery is the first established approach to build an IT system, defined by Winston W. Royce in 1970. It gained support in early days of software development and underlies methodologies such as such as SSADM, Prince, soft systems methodology, structured design, Yourdon Structured Method, Jackson Structured Programming, and structured analysis. In this model, everything flows logically from beginning through end and is split in clearly defined phases. The key steps in this model are Analysis, Design, Implementation, Testing, Installation and Maintenance. The Waterfall model makes a very important assumption – all requirements have been collected up front and frozen before start of the Analysis phase. Hence, communication with the business users is done upfront.

All the phases are firm, clearly separated and are executed in sequence. The Requirements are not allowed to change and the end product can only be tested, in the true sense, once the project goes into its testing phase as shown below.

Iterative model

The Iterative model, as used in Modified Waterfall, Rational Unified Process, Extreme Programming and Agile, tries to avoid the necessity for freezing of the requirements at the start of the project, and provides some level of flexibility in the process. As the name ‘Iterative’ implies, the general idea is to develop the software through multiple iterations. Working though iterations means that, in each iteration, a chunk of functionality is analyzed, designed, developed, and tested. Iteration cycles are repeated till the fully functional product is ready for production.

It is a common practice to demonstrate the developed product to stakeholders at end of each iteration. Feedback from the demonstration are input to the next iteration in order to add or correct the scope. Since this problem gives chance to stakeholders to look at the product early, problems can be corrected before they become too expensive to fix.

The key advantage of Iterative model is that it allows more flexibility in scope and requirement changes.

Agile-Scrum (Iterative Incremental) model

In year 2001, a group of engineers discussed lightweight development methods and published “Manifesto for Agile Software Development” to define the approach that is now known as Agile.

The Agile manifesto² reads as follows.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Scrum is one of the most commonly-used methodologies of Agile software development. Other Agile methodologies for software development are Lean, Kanban and eXtreme Programming (XP). Each agile methodology has its own practices, tactics and terminology. Kanban focuses on elimination of waste and limits the amount of work and does not prescribe to work in iterations. XP framework focuses heavily on ensuring the quality of delivered software. XP works towards a continuously improving, high quality product which can respond to changes in customer requirements even within the iteration. Scrum is more prescriptive than Kanban. Scrum focuses on the delivery of scoped work in time-boxed fashion and it does not allow requirement changes within an iteration.

Model comparison

What	Waterfall Methodology	Iterative Methodology	Scrum Methodology (Incremental and Iterative)
Responsiveness & Flexibility	Very Low	At each iteration cycle	Throughout
End product	Defined at beginning	Defined during project	Defined during project
Overall project cost	Defined at beginning	Defined during project	Defined during project
Success probability	Low	Medium	High
Cost of change	Very High	Medium	Low
Mindset	Project mindset	Product mindset	Product mindset
Customer involvement	Low	Medium	High

Why consider Agile?

Agile process is proven to produce higher productivity, quality in less time. Agile methodology results in productivity gains by better communication and being responsive to customers’ demands and adapting continuously through the project. Many companies have registered an increase of team productivity by 16% or even more. ^3,4,5,6

Advantages of a well-adapted Agile

1. Reduced risk
   • There are fewer surprises. Because the model is incremental and iterative, it can give indications of success and failure early in the project, allowing the Project Management Office (PMO) to take corrective actions to correct problems before they get out of hand.
   • At least a part of the working product is always available, so that the project can never end in complete failure
   • The product owners and sponsors know exactly what usable features are available at any point of time, regardless of the outcome of future sprints.
   • Project governance has the opportunity of providing constant feedback, mitigating communication gaps and helping in team morale constantly.
2. Predictable outcome
   • By knowing the work rate of each developer, the development team can help the PMO to predict timelines and budget for releases more accurately.
   • In-depth information from daily scrum meetings, burndown charts, task boards and retrospective meetings allows a more accurate forecast for future sprints.
3. Relevant project metrics
   • It is easier to predict overall project performance, timelines and budget from each team’s performance and outputs.
   • It is easier to estimate the timelines and budget for successive development projects where requirements are of a similar complexity.
   • Daily burndown charts provide relevant insight into day-to-day progress.
4. Better product quality
   • Requirements can be tweaked as business needs change, making for a more adaptable model
   • Continuous integration (CI) processes and daily sanity testing helps in resolving issues before they cause a snowball affect
   • Incorporation of automated testing improves quality further as it allows the delivery team to increase the scope and thoroughness of with currently-available resources
   • Sprint retrospectives help in improving the progress and quality of day-to-day activities
5. Higher customer satisfaction
   • Customers are engaged throughout the project lifecycle.
   • Effective communication is an important factor in Agile success. In non-Agile approaches, project manager is the source of information for project sponsors and stakeholders. In Agile, this silo is broken. All the project metrics and project data are available on click of a button for everyone to view, resulting in higher transparency and satisfaction.
   • Product owner is able to ‘keep tabs’ on requirements and can fine-tune the resources required to meet them.
   • Every Sprint review gives chance to customers to see working functionality
6. Higher control
   • The project stakeholders, the developers, the product owner and scrum master all can monitor progress throughout the project to learn and improve, thereby, creating better products.

Expectations

No technology leader wants a project to fail- let alone a large/transformational one. Although the benefits of Agile make it an obvious candidate when choosing a development methodology, the choice is dependent on the priorities and requirements of the stakeholders.

Expectations matrix:

What	Stakeholder expectation	Provided by
Responsiveness & Flexibility	Throughout	Scrum
Product definition	Fixed*. Define end product definition in planning stage	Waterfall
Project cost	Fixed. Define overall project cost at planning stage	Waterfall
Success probability	High	Scrum
Cost of change	Low	Scrum
Risk	Low	Scrum
Quality	High	Scrum
Overall timeline	Fixed	Waterfall
Requirements & Systems	Changes happen in many systems concurrently. Interdependent requirements can’t go live in isolation.	Waterfall
Documentation	Well documented	Waterfall
Skills & cost optimization	Leverage benefits of global delivery model with teams in many locations worldwide.	Waterfall
Approvals, Quality Gates	Requisite design approvals and quality gates should be in place.	Waterfall

*Even though fixed, leaders want some flexibility in requirements with changing business scenarios.

This matrix makes it obvious that, to leverage benefits of Agile without sacrificing the stakeholder priorities in their expectations, the benefits of Waterfall will have to be incorporated in Agile methodology. The rest of this article will explain how this can be done.

Tailored Agile Model

No single process fits every product development, and most Agile techniques can be tailored to the needs of the product. This tailored model is an example of the way that Agile can be adapted for an Iterative-Incremental development, where each sprint will be of three weeks.

In this approach, Analysis and Design will be completed before the start of coding of the sprint, and will be done concurrently with the Coding and Continuous Integration of the previous sprint.

A final UAT phase will help in Quality-Assurance of the completed yet unshipped functionality in which some stories are production-ready.

This approach may not be liked by Agile purists: However any project requires, more than anything, the successful project delivery with the right product quality, within the timeline and budget. Project stakeholders want a project delivery methodology that is coupled with a strong governance mechanism that is ethical, robust and which meets the end objectives. Also, stakeholders are aiming to transform an organization rather than just to succeed with adopting Agile for a single project; but this is easier said than done.

Acceptance of Tailored Agile

First and foremost, if an organization is transitioning from Waterfall, then, more effort will be needed to convince it why “transitioning to Agile” is the right choice.

The next issue faced by the project team is to convince the stakeholders why pure-play Agile can’t deliver as per the exceptions and secondly why the tailored methodology will not end in failure. Convincing Agile purists becomes the next problem at hand as the tailored methodology uses only some of the concepts of Agile unmodified.

Any plan to deploy all of the functionality into Production in a single huge single release will cause a justifiable level of concern from the QA leadership. The reason is quite understandable. Though code is continuously integrated and tested for its incremental functionality, the code is not immediately deployed to Production. Therefore, the scope of Regression testing will keep on increasing with number of completed sprints.

The final piece of the puzzle is to come up with a schedule that is acceptable to all, where all parties are responsible for the success of the project. In organizations that have been in the business for decades and follow a hierarchal organization structure with a low level of collaboration among teams and departments, it may prove to a herculean task to arrive at a common agreement. Be ready to have many meetings with various stakeholders to reconcile the differences.

Expected Issues and Resolutions

Despite all our best efforts, the team will be faced with several issues, including the following:

S.No.	Issue	Resolution
1	An integration requirement, with business logic in multiple system can’t be broken into User Stories that can be completed within one sprint due to dependencies.	Such stories should span a maximum of two sprints. Related dependent stories from other systems should be stopped from being delivered to the testing environment by mistake. All the interconnected stories should be deployed to the testing environment at the same time.
2	Some stories will be too complex and require a large effort sequentially and can’t be broken into stories to fit in 3-week time-box.	Same as above
3	Scope creep: The business will likely try to add new stories into the scope.	A well-oiled process should be in place to prevent scope creep while at the same time facilitating user-feedback at the end of every sprint.
4	Defects that span across more than one system. Testing for huge set of requirements where one requirement may touch multiple systems is time-consuming and difficult to manage.	A system must be in place that has the end-to-end requirements, affected system, related user stories, their daily progress and associated defects. This must be in a single system with reporting capabilities. Such reports must not take more than 30 minutes to generate daily.
5	Tracking the design documents and their delivery and approval	To meet the organization’s delivery methodology, all the designs must be approved prior to start of sprint. A collaboration and tracking system must be in place and teams should use it properly so that managers can do backward planning and use collaboration for document delivery, review cycles and online approvals. It is to be expected that at times key approvers may be unavailable. Alternate processes should be in place for mitigation. Such processes must be established in advance and approved in steering committee.
6	Code shipment for CI	Successful code shipment for continuous integration will require the co-ordination of- Process Issue tracking system Code shipment system Automatic deployment (preferable) Teams Sanity testing (preferably automated)
7	Come up with a schedule that is acceptable by all, where all parties are responsible for the success as well as for the failure	Socialize the methodology from the bottom upwards, and drive the decision from the top downwards.
8	End-to-End requirements, User Stories breakdown, issues and progress tracking	A system must be in place that has the E2E requirements, affected system, related user stories, their daily progress, associated defects must be in a single system with reporting capabilities. Such reports must not take more than 30 minutes to generate daily. In worst-case scenario, an additional daily meeting may be set up that can review the progress of the day and define priorities for next day.
9	Definition of Done	Track the “Done” at two levels. User Story Level E2E Requirement Level
10	Scrum of Scrums	Daily Scrum of Scrums must be instituted and followed in letter and spirit. These meetings can be applied at all levels and rolled up to next level.
11	Communication	Communication is one of the pillars of success. Communications effectiveness must be reviewed regularly and issues must be addressed proactively without delay.
12	While not in line with Agile methodology, some teams will work from remote location(s). Co-location is not possible for these teams.	While co-location is one of the key Agile demands, it is not always possible. It can be resolved with the combination of following two options. One or two team members must be co-located locally and represent them. Such team members should have worked with the extended off-location team. Daily scrum meetings should use Video-conferencing with such extended teams and their local representatives.
13	Issues prioritization – deciding which issues, defects should be tacked first.	Issues will be difficult to tackle and as count will increase beyond manual controllable number early in the CI cycle. A three prong approach will be helpful. A common tracking system should be used for User Stories, Business Requirements and Defects. The system must have the capability to connect these to one another. System must have a reporting capability that can roll up defects/issues to User story and then to Business Requirement. Separate daily meetings should be held if the issues seem to get out of hand, and developers should be informed which issues are a priority.
14	Design Approval, Quality Gates	If the organization is transitioning from a Waterfall methodology, project stakeholders may insist of having Design Approvals and UAT Entry and Exit Quality Gates in place. This situation will especially true in Transformation projects. Only a tailored Agile model will be able to satisfy these needs.
15	Less than planned output from initial sprints.	Output of initial sprints should not become a deal breaker. Negative sentiment is hard to tackle, especially if this is one of the first projects in Agile model. The Agile coach should gauge the team’s Agile knowledge in advance and coach appropriately at all levels.
16	Continuously changing requirements	Agile is not as a license to give half-baked requirements that will require multiple sprints. Early flags should be raised to align the expectations of all involved teams. If any requirement will genuinely require more time to get frozen, consider it in future Sprints.

The table above covers most of the issues such implementation will face and their resolutions.

In the next article of this series, I shall delve into finer aspects of these issues.

References:

• ¹ Agile Software Development with Scrum by K. Schwaber and M. Beedle
• ² Manifesto for Agile Software Development. Retrieved August 8, 2017, from www.agilemanifesto.org
• ³ Harvard Business Review. MAY 2016 ISSUE. Embracing Agile. Retrieved August 8, 2017, from https://hbr.org/2016/05/embracing-agile
• ⁴ IEEE. Agile software development: Impact on productivity and quality. Retrieved August 8, 2017, from http://ieeexplore.ieee.org/document/5492703/?reload=true
• ⁵ Agile Development Increases Productivity. Retrieved August 8, 2017, from http://www.softwareresults.us/2010/07/agile-development-increases.html
• ⁶ As Agile Goes Mainstream It’s Time for Metrics. Retrieved August 8, 2017, from http://nyspin.org/QSMA-Rally%20Agile%20Impact%20Report.pdf