agile adoption framework

Agile Adoption Readiness Framework

Indian Institute of Management Lucknow

Prabandh Nagar, Off Sitapur Road, Lucknow, Uttar Pradesh - 226013, INDIA.

Post Graduate Programme in Management

2010-2012

Framework for determination of organizational readiness to adopt agile

methodologies in software development

A Course of Independent Study Report

By

Vaibhav Sathe

PGP26182

Under guidance of

Dr. Bharat Bhasker

Information Technology and Systems Area

©2012. Indian Institute of Management Lucknow. All Rights Reserved.


APPROVED FOR SUBMISSION TO PGP OFFICE TOWARDS TERM VI REQUIREMENTS OF PGP COURSE

Signature:

Dr. Bharat Bhasker Professor, Information Technology & Systems Area, IIM Lucknow

Date: 22.02.2012


Acknowledgements

The author would like to thank Prof. Bharat Bhasker for the most valuable help and guidance he

provided throughout the course of this project, without which it was impossible to achieve the

completion.

The author acknowledges Mr. M. U. Raja and the staff of IIM Lucknow Library, who promptly

procured all the books required in this massive literature survey. Author also thanks library and

administration of IIM Lucknow and ESCP Europe, Paris campus for the rich collection of journals

and digital database subscriptions without which the project could not have been completed.

Author thanks numerous authors of books, articles, papers, blogs and other publications whose

references are cited in this project report.

The author acknowledges contribution of following individuals in making this project successful.

Aniket Mokashi, Sr. Software Engineer, Netflix, Inc.

Ashish Bhangale, Software Development Engineer in Test, Microsoft Corporation

Bhavik Vora, Sr. Software Engineer, Microsoft India R&D Pvt. Ltd.

G. Nagraj, Director, TeamDecode Software Pvt. Ltd.

Krunal Dedhia, Sr. Software Engineer, Accenture

Naveen Babu Monthri, Sr. Program Manager, Microsoft India R&D Pvt. Ltd.

Pranav Karkhanis, Software Development Lead, Microsoft India R&D Pvt. Ltd.

R. Venkata Konda Reddy, Staff R&D Engineer, IBM India

Rohit Ratnakar Mallya, Global System Engineering Lead, Microsoft Corporation

Sandhya Rithe, Program Office Manager, Barclays

Sanjay BK, PGDM Student, Indian Institute of Management Lucknow

Sudheesh S, Associate Consultant, MindTree Ltd.

Swati Patil, PGDM Student, Indian Institute of Management Lucknow

Vikas Gupta, General Manager and Global Practice Head (Cloud Computing), MindTree Ltd.

Vinayak Rakkasagi, PGDM Student, Indian Institute of Management Lucknow

Vivekananda Parepalli, PGDM Student, S.P. Jain Institute of Management & Research

Author also acknowledges the contribution of all survey participants including those who chose to

remain anonymous, while helping this project.


Executive Summary

The objective of this study was to identify factors that affect adoption of agile methodologies in

software organizations. The study also aimed at establishing relative importance of these factors.

The executive summary provides brief introduction of structure of this report organized based on

chapters dedicated to each topic as below.

Chapter 1

This study included a detailed literature survey in which we have taken overview of evolution of

various software engineering methods. Later on we have discussed how the principles of agile

manifesto formed foundation to various agile methods like Scrum, Kanban and Extreme

Programming.

Chapter 2, 3 and 4

Then we have discussed in brief the three agile methods mentioned above with detailed explanation

of terminologies, meetings, tracking methods, delivery cycles and various tools that are used. We

have analyzed these methods from perspectives of customer and developers.

Chapter 5 - 9

In later section, literature survey was carried out to identify list of possible variables that impact

adoption of agile methods. Various case studies, published papers, interviews and websites of

consultants were reviewed. A list of 51 such variables was finalized organized in 5 sections which are

different organizational aspects of software development – Software Design, Business Process, HR

Practices, Delivery Model and IT Management.

Chapter 10

Primary survey was conducted to gather expert opinion on cri ticality of these factors. Statistical

Exploratory Factor Analysis was performed to identify correlated factors together. A summarization

exercised reduced these 51 variables into 22 factors organized in 5 sections mentioned above. Also,

the variability explained by each factor was identified which indicates importance of factors in

adoption process.


Contents

1. Chapter-1: Agile Evolution 6

2. Chapter-2: The Scrum 12

3. Chapter-3: eXtreme Programming 17

4. Chapter-4: Lead Agile 22

5. Chapter-5: Software Design 27

6. Chapter-6: Business Process 33

7. Chapter-7: HR Practices 39

8. Chapter-8: Delivery Model 45

9. Chapter-9: IT Management 52

10. Chapter-10: The Framework 57

Web Companion

For additional updates, references, SPSS outputs and appendices, refer to project homepage:

http://agile.vaibhavsathe.com

Chapter 1: History of Agile Development


In this chapter…

Waterfall model and its shortfalls

Techniques from manufacturing

Toyota Production Systems (TPS)

Agile Manifesto, 2001

Waterfall software development model

Since pre-historic times, most projects were executed sequentially. For example, in that

era construction projects were most prominent. Hypotheses on construction of

Egyptian Pyramids suggest that the approach followed was – Specification of

requirements, designs and models, creation of building blocks, assembly, various

verifications and necessary modifications. The similar approach was followed in

manufacturing industry later on and then when software industry was born, naturally

this sequential approach was adopted as there were no new techniques available.

As explained by Maurer and

Melnik[1] in their white paper on

Agile Methods, Waterfall model

finds its roots in scientific

management principles of

Frederick Taylor. With objectives

of improving economic efficiency

and labor productivity, the theory

focused on devising analyzed and

synthesized workflows thereby

engineering processes,

encouraging standardization. It

mainly focusses on continuous

learning and improved efficiency

through repetitive work and

hence focusses also on labor work

division, where a particular worker

would work on same problem

again and again, thereby gaining

CChhaapptteerr 11::

AAggiillee EEvvoolluuttiioonn

Figure 1 Pressman (1994) Waterfall Software Model



expertise and improving efficiency through learning. Maurer and Melnik also state that key reason

why such methods are inapplicable to software development is because fundamentally it is non-

repeatable process.

Steps in Waterfall Model

Pressman[2] defines waterfall model for software engineering as follows. It consists of steps like

Requirements gathering, Analysis of the problem statement and various approaches of solution,

preparation of high level and detailed level design, Coding or development, testing or verification of

actual against expected specifications and finally acceptance or actual deployment of system into the

business. Important thing to note here is most of these activities happen in a strict sequence with very

little or no scope for backtracking more than two steps without restarting the whole process.

Problems with waterfall

The biggest issue is that the waterfall expects requirements to be frozen in order to begin analysis

and design phases. Project managers working on waterfall models expect requirement signoffs in

order to begin their effort on estimates and functional specifications. And once they freeze their

specifications, downstream developers begin coding work. All hell breaks when certain requirement is

invalidated, added or even modified. Reality is that it is impossible for business to freeze requirements

several months in advance (before they get delivery of entire project through above steps). Alan

Shalloway[3], in his book “Design Patterns Explained: A New perspective on Object-oriented Design”

states changing requirements throughout project life cycle is natural and those cannot be frozen in

advance. Software design and processes therefore, should mature in order to handle changing

requirements.

Other problem includes that working version of the project is available only in the end. It creates two

problems, one in terms of justifying investments without seeing returns and other is risk of increasing

gap from stakeholders’ expectations.

The waterfall processes do not encourage larger stakeholder participation in multiple stages. It rather

focusses on each party playing its role in each stage and handing over control to next on completion.

This leads to poor coordination. Iterations in waterfall models create confusion, leads to poor quality

of output as processes, people and design is not ready to handle such deviations. Software

development fundamentally differs from manufacturing activities in terms of huge time taken for

development and availability of option of reversal. These two differences result in dynamic

requirements and hence the thought process began on adopting processes to this phenomenon.

Techniques from Manufacturing

Manufacturing firms realized that the key competitive advantage lies in their efficiency which will

enable them to retain profit margins while becoming cost competitive in the market. Various new

techniques evolved to increase efficiency, throughput, quality and productivity of manufacturing and

supply chains. Software industry borrowed many of the ideas, concepts or methods and developed

several new methods to address problems of similar nature. We will look into some key

methodologies.



Six Sigma

Developed by Motorola in 1986, Six Sigma focusses on defect removal and variability reduction,

thereby creating quality based framework for people within organization. The key problems with Six

Sigma in Software are that since software development is non-repetitive, statistical methods are

ineffective and inability to link software metrics to direct economic or customer centric metrics for

most companies. As per Dr. Fehlmann[8], The software implementation of Six Sigma is based on three

principles. (1) Use customer centric metrics only. (2) Adjust to moving targets (3) Enforce

measurement.

The key similarity between Six Sigma and Agile Techniques is in its principle to recognize that change

is imminent and processes need to adapt. Also, both methods make project more transparent to the

management and the customer.

CMMI

Capability Maturity Model Integration in Software Engineering is process developed by Software

Engineering Institute (SEI) at Carnegie Melon University. It focusses on integrating separate

organizational functions, defines objectives for process improvements, defines organizational

priorities, provide guidance for quality processes and provide point of reference for improvements in

current processes. The CMMI defines various stages of maturity as Maturity Level 2-5 in Software

Development, Services and Acquisitions areas. This indicates systematic synergistic approach of

process evolution.

Broad opinion considers CMMI as complete opposite ideology of Agile methods. However, many

researchers differ. They find increasing commonalities and cross-influences of one another as both

processes have evolved. Some of notable work includes, presentation by Dr. Russwurm [7] from

Siemens AG. He states that estimation, lessons learned steps in Agile have commonalities with CMMI.

While CMMI focusses more on what and when to do leaving how portion to organizational processes,

Agile processes focus more on how those underlying processes are improved.

TSP/PSP

TSP stands for Team Software Process and PSP stands for Personal Software Process. Both were

developed by Software Engineering Institute of Carnegie Melon University. These processes guide

engineering teams in developing software intensive products and claim to produce secure and

reliable software in less time and lower cost.

Personal Software Process

PSP focusses on individual learning in steps – (1) Process Discipline and Measurements (2) Estimation

and Planning and (3) Quality Management and Design. Again, PSP is considered Predictive while Agile

is considered in contrast, Adaptive methodology. But, PSP focusses on individual developers and

hence can be adapted to suit needs of Agile development. Commonalities include focus on realistic

schedules, estimations and continuous modifications in schedules.



Team Software Process

The detailed information, cases and research papers on Team Software Process can be found

on TSP homepage on SEI site at http://www.sei.cmu.edu/tsp.

Consolidation of PSP process of entire team results in TSP. Key commonalities between scrum team

and the TSP team are that both believe in team members taking complete responsibility for their

work. They work on creating environment of trust and accountability and they work together on

realistic plans.

Toyota Production Systems

Toyota Motor Corporation consolidated its managerial philosophy in “The Toyota Way”[6] written by

Jeffrey Liker, which is based on two primary principles “Continuous Improvement” and “Respect for

people”. Dr. Liker explains the system in following 14 principles.

Section I: Long-term philosophy

1. Base your management decisions on a long-term philosophy, even at the expense of short-term

financial goals.

Section II: The right process will produce the right results

2. Create continuous process flow to bring problems to the surface.

3. Use the "pull" system to avoid overproduction.

4. Level out the workload (heijunka).

5. Build a culture of stopping to fix problems, to get quality right from the first.

6. Standardized tasks are the foundation for continuous improvement and employee empowerment.

7. Use visual control so no problems are hidden.

8. Use only reliable, thoroughly tested technology that serves your people and processes.

Section III: Add value to the organization by developing your people and partners

9. Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others.

10. Develop exceptional people and teams who follow your company's philosophy.

11. Respect your extended network of partners and suppliers by challenging them and helping them

improve.

Section IV: Continuously solving root problems drives organizational learning

12. Go and see for yourself to thoroughly understand the situation (Genchi Genbutsu)

13. Make decisions slowly by consensus, thoroughly considering all options (Nemawashi); implement

decisions rapidly;

14. Become a learning organization through relentless reflection (Hansei) and continuous

improvement (Kaizen).

Software industry has always borrowed various techniques from operations. The most recent is

bringing Kanban or Lean techniques which are largely influenced by TPS. Key ideological

commonalities between TPS and Agile methods are building continuous process, focus on visual

representations, increased coordination between all stakeholders, higher visibility to management at



all stages and decentralization of decision making. We will see Kanban implementation for software in

greater details in Chapter 4.

Agile Manifesto, 2001

The alternatives to waterfall model started surfacing in mid-1990s targeting different problems. This

includes Extreme Programming (1996), Scrum (1995), Feature Driven Development or Test Driven

Development. These methods were later rebranded under the agile umbrella after declaration of Agile

Manifesto in 2001.

In February 2001, 17 software developers met at Snowbird resort and published Manifesto for Agile

Software Development[4]. This was beginning of agile revolution in software world. These authors later

formed the Agile Alliance, a non-profit organization for promotion of development based on

principles outlined in manifesto.

Exact wording of manifesto[4] is 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.

While the manifesto is largely self-explanatory, the most important point is its focus on encouraging

dynamic changes, hard plans, interaction among stakeholders and identification of real deliverables.

The twelve guiding principles behind the agile manifesto can be found on manifesto’s site at

address http://agilemanifesto.org/principles.html.

10 years of Manifesto

In February 2011, on the day of 10th anniversary of manifesto, many senior agile development

professionals met once again at same location and presented new questions for discussion. [5]

1. What problems in software have we solved and therefore we should not keep simply re-

solving?

2. What problems are fundamentally unsolvable so we should not keep solving them?

3. What problems we can sensibly address or mitigate with money, effort or innovation and

therefore focus our attention on?

During the discussion, the framework posted by Michael Hugos [5] from “Center for Systems

Innovation” is worth mentioning here. It mentions how the Agile IT practices are going to drive agility

in the business thereby creating larger value in the future.



Agile IT would be employed to drive three

simultaneous feedback loops which would

make real time operations possible. First loop,

called Awareness, identifies threats and

opportunities in changing environment. The

second loop, called Balance, continuously

adjusts existing operations and processes to

fit changing circumstances. The third loop,

called Agility, enables companies to create

new products and processes in order to seize

new opportunities.

Based on WHAT from loop 1 and HOW from

loop 2 and 3, real-time organization in this

century can continuously navigate through its

environment and can adjust itself as its

situation changes. This framework is useful to

discuss how Agile can expand into wider business world with cloud, social media and consumer IT.

References

1. Maurer, Frank and Melnik, Grigori, (2006) Agile Methods: Moving towards the Mainstream of the

software industry downloaded from ACM Digital Library on Jan 2, 2012.

2. Pressman, Roger S. (2001), Software Engineering: A Practitioner’s Approach, Fifth Edition, Mcgraw-

Hill.

3. Shalloway, Alan and Trott, James R. (2004), Design Patterns Explained: A New perspective on

Object Oriented Design, Second Edition, Addison-Wesley.

4. The Agile Manifesto, Actual wording and the principles, Official Website of the Agile Manifesto,

http://agilemanifesto.org, retrieved on Jan 2, 2012.

5. 10th anniversary of Agile Manifesto, weblog of discussion by eminent agile professionals, retrieved

from http://10yearsagile.org on Jan 2, 2012.

6. Liker, Jeffrey K. (2004), The Toyota Way: 14 Management Principles from the world’s greatest

manufacturer, First Edition, Tata McGraw-Hill.

7. Russwurm, Winfried (2010), Hidden Treasure: The Implementation of CMMI practices by Agile

Methods, Siemens AG retrieved from http://www.sei.cmu.edu on Jan 2, 2012.

8. Fehlmann, Thomas M., Six Sigma For Software. Euro Project Office AG, Switzerland.

Chapter 2: The Scrum


In this chapter…

Scrum framework

Scrum Team

Scrum Process

Scrum tools and documentation

Introduction

Scrum is an iterative, incremental framework for project management classified under

the Agile techniques umbrella. Scrum principles are based on Agile Manifesto.

Although scrum was defined originally from product development point of view, its

most common usage is for managing software development and/or maintenance

projects. The scrum process was developed by Jeff Sutherland in 1993. The method

evolved over a decade by work of many and was formalized through release of

Schwaber’s book named Agile Software Development with Scrum in 2001.

As per scrum alliance website[1], the scrum can be extended even to any non-software

development but complex and innovative project. In this chapter, the technicalities of

methodology are explained in brief.

Figure 2 ScrumAlliance® The Scrum Framework[1]

CChhaapptteerr 22::

TThhee SSccrruumm



Product Backlog Product Owner creates prioritized outstanding list of work items or features.

Sprint Backlog From top of the wish list, the team picks up small chunk of the work items

based on its bandwidth and prepares plan to implement them.

Sprint Sprint is the unit block of work. One sprint runs usually for 2-4 weeks. It is

duration in which selected features are targeted completion for delivery.

Daily Standup Meet During the sprint, daily reviews are conducted called as daily standup

meetings.

Shippable Product

Increment

At end of sprint, work should be potentially shippable, ready in hand to

customer, put on store or show to stakeholder. Sprint ends with review and

retrospective.

The Scrum Team

Roles in scrum are defined as Pigs and Chickens. Pigs are working or core members. Chickens are

ancillary or non-working members. Scrum requires regular coordination among these members.

Pigs

ScrumMaster: The team’s process leader is called as Scrum Master, usually ScrumAlliance® Certified

ScrumMaster. He ensures that scrum process is followed as intended. He may also be member of

working team. Schwaber says that the authority of ScrumMaster is indirect and comes from his

knowledge of the process. He increases success probability by helping Product Owner select most

valuable backlog and helping team to turn that into functionality.[2]

Product Owner: Representative of customer is called product owner. He/she provides and prioritizes

requirements and has authority to alter/control changes. Generally, product owners are not team

members and may belong to client organization.

Team: All other members of scrum team carry out various tasks like documentation, communication,

coding, testing, deployment, review etc.

Chickens

Managers: Managers are people or project managers who control the work environment and

possibly budget for the teams. They are also responsible for performance reviews of the team

members.

Stakeholders: Stakeholders include customers and vendors other than Product Owner who is active

member of scrum team. These are potential suppliers or benefactors of the project work and are

generally involved only during sprint reviews.

The Scrum Process

The scrum process includes following key activities.[6]



Plan the Project

Planning process sets expectations of stakeholders, who are beneficiaries, sponsors or someone who

is affected by delivery or non-delivery of the project. Amount of budget, time duration, expected

deliverables and identified risks are included in the plan. The minimum plan consists of a vision and a

product backlog. Vision is the motive, desired end state and impact of project on various

stakeholders.

User Stories

User stories highlight scrum’s customer centric focus. It is functionality explained from point of view

of user or purchaser of software under development. Product Backlog includes user stories. Example:

Technical requirement: Ability of system to retain login and activity history for registered users.

User Story: As a returning customer, I want to find a meal that I have ordered before.

Scrum team estimates size of each user story point by point or step by step. It helps in achieving

higher accuracy in estimations and work division.

Team Velocity

Team velocity is number of story point it can complete it given duration of sprint. This is obtained

based on historical data or rough estimations in absence of history. This is more generalized estimate

which helps in planning how many stories to include in given sprint or decide team size. Accurate

estimations of tasks are only considered in individual sprint planning.

Release Plan

Iterative release plan is made based on which user stories are dependent on each other, and how

much value they add to end user. Also, for each sprint, new stories can be added or removed. Groups

of user stories are made, which represent releasable feature, something that can provide sufficient

business value to customer.

Sprint

Team starts work in sprints of fixed duration.

Sprint Planning Meeting

During Sprint Planning meeting which runs for a day, team breaks down stories to identify exact tasks

and develops estimates. Commonly used estimation methodology is Planning Poker which is based

on consensus between team members on sizes of each work item. Team then commits to this agreed

upon user stories for delivery during that sprint. This is similar to baseline stage in waterfall.

To know more about Planning Poker, you can check this Wikipedia article at:

http://en.wikipedia.org/wiki/Planning_poker



Daily Stand-up meetings

Team members meet daily for short time (hence stand up) and share their accomplishments of last

day, plan for today, and any possible issues they foresee.

Finishing the Sprint

Sprint Review Meeting

In the end, Sprint Review is conducted where team presents deliverables. Customers accept the

stories if expectations are met. Incomplete and new stories are added back to product backlog.

Retrospective

In alignment to Agile principle of self-organization, team tries to identify success factors and failures.

Based on feedback from all members, it tries to readapt processes for next sprints. It gauges general

effectiveness, productivity and quality of the teamwork. Solutions identified are incorporated in

planning meeting of next sprint. They are also recorded in organizational KM systems for feedback to

other teams.

Scrum tools and documentation

Scrum does not focus on creation of excessive documentation. There are various tools available for

tracking scrum projects like Microsoft Project, Microsoft Visual Studio, IBM rational have add-ins. Let’s

review one of the simplest among them, an Excel based worksheet which is part of Microsoft Scrum

Kit.

Microsoft Scrum Kit

Microsoft Scrum Kit[5] includes Excel templates for product backlog, sprint backlog, burndown

tracking and various charts, which give visual representation of project status for consumption of

management. One excel document per sprint is prepared. It has following parts:

You can download the Microsoft Scrum Kit Excel template for strictly academic purpose from

http://www.vaibhavsathe.com/blog/?page_id=246 (Redistribution Forbidden)

Planning: Planning tab records team configuration, and availability for given scrum.

Sprint: Sprint tab tracks all work items which are part of backlog for current sprint. It has columns

corresponding to each day in sprint. Team member has to record time spent and time left on each

work item every day. This data is used to compute all required graphs and charts to report project

status.

Analysis: Analysis tab provides view what is to be discussed in Daily Stand up meetings. It gives view

of Not Started, In Progress and Completed work items. It gives idea to team if they are lagging

behind. It also shows burn down chart.

Burn down Chart[4]



A burn down chart gives view of work remaining (Y axis) against time (X axis).

Generally Actual burn down plot is compared against Planned burn down chart. It

gives idea to reviewers if project work is lagging behind or ahead of schedule. It is

valuable tool in deciding continuous work adjustments during Sprint or project

development cycle.

Retrospective: On this tab, cumulative sprint report is generated which shows, Planned vs. Actual,

Work hours and Load factor. It gives idea to team about variability in their earlier estimations and

help plan better to achieve higher predictability in future. It also records member comments on What

Went Well and Areas of Improvement.

References

1. Scrum Basics, ScrumAlliance® website retrieved from http://scrumalliance.org on Jan 3, 2012.

2. Schwaber Ken, Agile Project Management with Scrum, First Edition 2004, Microsoft Press.

3. Schwaber Ken, The Enterprise and Scrum, First Edition 2007, Microsoft Press.

4. Joel Wenzel’s blog on In Point Form, Burn Down Chart Tutorial, retrieved from

http://joel.inpointform.net on Jan 6, 2012.

5. Microsoft Scrum Kit Excel Template for strictly academic use from http://vaibhavsathe.com

6. Sutherland Jeff, Schwaber Ken et al, Microsoft Corp., MSF For Agile Software Development v5.0,

MSDN Library, Visual Studio 2010, online publication, retrieved from http://msdn.com on Jan 6,

2012.

Chapter 3: eXtreme Programming


In this chapter…

XP framework

XP practices

XP team

XP artifacts

Introduction

Extreme Programming (hereafter referred as XP) is a type of agile software

development technique focused on improving software quality while increasing

responsiveness to changing customer requirements. Contrary to popular claim in

software industry, XP claims “It’s possible to keep the cost of changing software from

rising dramatically with time.” [1] It is one of the methods that focus on customer

delivering what and when customer wants.

The methodology takes agile programming one step nearer to lean techniques by

emphasizing on Just In Time (JIT), i.e. build software features only when they are

required and not in advance, to reduce uncertainty of changing requirements. This of

course, require unprecedented amount of courage and coordination on team’s part .

Like all agile methods, XP has feature backlogs.

Based on budget & time, most important ones are

prioritized. This planning process then continues with

identifying honest estimates about selected stories.

As team works on those deliverables, a daily

communication is made to required stakeholders.

Organization ensures team is empowered with

required skills and resources in order to deliver on

commitment. Team develops in such a way that they

have the final software in deliverable state all time.

Whenever they finish with one cycle, the planning

starts for next.

CChhaapptteerr 33::

eeXXttrreemmee PPrrooggrraammmmiinngg

Figure 3 XP WorkFlow [2]



Basic Variables

XP identifies that software projects can be managed with four variables [1]: time, scope, resource,

quality. Change in any of them naturally affects others. To maintain one variable constant despite

change in other, remaining two variables will need to make sacrifice. E.g. If scope increases and

delivery date i.e. time needs to be kept constant, then naturally either resources or quality or both

need to take the heat.

XP suggests that agree on acceptable level of quality with customer and management. During the

duration keep time unit and resources fixed. Hence, only variable that remains is the scope. What and

when will be decided by customer. Team will deliver on that.

Extreme Programming Values

The four basic values of XP are [1]:

Communication barriers are removed between developer and customer.

Feedback from customer during testing, allowing immediate changes in the design if any.

Simplicity means building only what is needed. Solve today’s problems today.

Courage to take hard decisions. Deliver bad news before it is late. Meet challenge as one team.

The XP Team

Following are core and supplementary roles in Extreme Programming methodology. [1]

Core Roles

The Customer

The XP recognizes rights of customer to (1) Ensure ROI maximization (2) Change the project scope to

deal with schedule change (3) To determine and alter feature prioritization (4) Measure progress of

project any time and (5) Stop the project without losing his investment.

The XP also identifies customer’s responsibilities as (1) Trust developers’ technical decisions (2)

Analyze risks correctly (3) Choose stories that maximize business value (4) Provide precise and clear

stories and (5) Work in team providing guidelines and receive feedback.

The Developer

The XP recognizes rights of developers as (1) Estimate own work (2) Work on sensible schedule (3)

Produce code that meets customer needs and (4) Avoid need to make business decisions.

The XP identifies responsibilities of developers as (1) Follow team guidelines (2) Implement what is

necessary and (3) Communicate constantly with customer.



Supplementary Roles

The Coach

The coach is an expert from whose example team learns. By virtue of experience, he provides his

wisdom to guide team through occasional obstacles and subtleties.

The Tracker

The tracker tracks the progress of the team and other numerical measures like % of test cases passed,

team velocity. He reports this information to the team and management as required.

The XP Process

Rules of Extreme Programming

Extreme Programming methodology defines basic rules for 5 stages of development. They are as

follows:

7. Planning: Create iteration cycles and decide user stories to be implemented.

8. Managing: Run the process on sustainable basis. Create required work environment.

9. Designing: Bring simplicity and design features only when they are needed.

10. Coding: Stress on customer communication, pair programming and unit testing.

11. Testing: Acceptance tests are run on regular basis and all code to pass unit testing.

You can find complete list of the Rules of Extreme Programming (Released in 1999 by Don

Wells) at: http://www.extremeprogramming.org/rules.html

Project Life Cycle

Below self-explanatory diagram shows end-to-end release cycle of an XP project.

Figure 4 Extreme Programming Project; Source: extremeprogramming.org [2]

Spike solution is implemented when a tough technical problem is encountered and solved by putting

pair of developers who are dedicated to solve that problem ignoring all other concerns.



Iterative Development

Following diagram depicts single iteration of development in an extreme programming cycle.

Important point to be noted is it is against rules to look ahead and do something not scheduled in

this iteration.

Figure 5 An Iteration; Source: extremeprogramming.org [2]

Pair Programming

In Pair programming technique, two programmers work together on single piece of code or module

on one workstation. While one types other does review. They switch roles frequently.

To know more about Pair Programming practice of Extreme Programming refer to wikipedia

article at: http://en.wikipedia.org/wiki/Pair_programming

Logically, this method doubles the cost of development and various experiments have yielded

contradictory results. However, Microsoft Research’s Andrew Begel and Nachiappan Nagappan [4]

conclude based on survey conducted among Microsoft developers that benefits of pair programming

outweigh the cost and other disadvantages. Key benefits are listed as bug reduction, shorter quality

code which is more maintainable.

Test Driven Development

XP projects follow TDD or Test Driven Development. Unit tests are written before code is written.

Code is set to complete when programmer cannot come up with further conditions which will break

the code.

To know more about Test Driven Development practice of Agile Development refer to

wikipedia article at: http://en.wikipedia.org/wiki/Test-driven_development



XP artifacts

Core XP does not prescribe any documentation but the code itself. It asks code to be self-explanatory

and up-to-date.[3] This includes adhering to simple rules of OO programming like naming classes,

creating routines and functions and remove commented code, use of source control software.

However, variants of XP prescribe distinct artifacts to aid team in the process. Let’s review some of

them.

User Story Cards

These are tools of customer to specify what, how and when he wants the deliverable. Advantage of

cards is that they help developers visualize and organize each story easily. They can be put up on wall.

Task Board

During planning of iteration, user stories are translated to task cards, which are given to programmer

to whom the task is assigned. These task cards are put up on task board in different phases. Anyone

looking at board gets clear idea of progress made by team.

Figure 6 User Story Card; Source: Leigh Stringer [5]

Figure 7 Task Board; Source: Mountain Goat Software [6]

References

1. Extreme Programming Pocket Guide – Team Based Software Development, O’reilly Canada 2003.

2. Agile Process – Extreme Programming website, http://www.extremeprogramming.org/, retrieved

on Jan 10, 2012.

3. Hedin Gorel, Bendix Lars, Magnusson Boris, Lund University, Sweden, Introducing Software

Engineering by means of Extreme Engineering, published by IEEE, 2003.

4. Begel Anfrew and Nagappan Nachiappan, Microsoft Research, Pair Programming: What’s in it for

Me?, published by ACM as proceedings of second ACM-IEEE symposium ESEM’08.

5. Stringer Leigh, Blog on Agile Software Development, retrieved from http://www.leighstringer.com/

on Jan 11, 2012.

6. Cohn Mike, Consultant and Agile Coach, Mountain Goat Software website, retrieved from

http://www.mountaingoatsoftware.com on Jan 11, 2012.

Chapter 4: Lean Agile


In this chapter…

Lean Principles

Kanban in Software

Kanban Practices

Milestones and Meetings

Introduction

Adapted from Toyota Production Systems, Lean Agile is the translation of Lean

manufacturing principles into field of software development. The term originated in

book Lean Software development written by Poppendieck Mary & Tom.

Enterprise Agility

Agile process applied in Scrum or XP focusses largely on software development

project. But latest trend in agility is to look at entire value stream, stream of delivered

software flowing from delivering organization to customer or consumers of solutions,

driven by business need.[1] Enterprise Agility focusses on applying lean principles of

minimizing cycle time, eliminating waste in this end-to-end delivery flow.

Below diagram depicts scope of Scrum/Agile vs. Lean/Agile on organization’s value

chain.

Figure 8 Application of Agile methods on value chain, Source: Alan Shalloway - Lean/Agile [1]

CChhaapptteerr 44::

LLeeaann AAggiillee



Necessity of adopting Lean principles

Various implementations of Scrum and/or XP across organizations resulted in some common

problems over period of time. As Frank Vega [3] shares his experience, these are – (1) Business need to

integrate and collaborate in various applications, however various team operate in silos, (2) Over

period of time long backlog gets generated due to starvation of secondary items and (3) Velocity of

team fluctuates based on technical complexity, hence predictability becomes an issue.

Principles of Lean Development

The borrowing of Lean principles from TPS tries to address these problems. As described by

Poppendiecks, these principles are as follows [4].

1. Eliminate Waste: Extra features, requirement churn. Identify and eliminate them.

2. Build Quality In: Build quality from start. Defect avoidance than fixing later disturbs less code.

3. Create Knowledge: Predictions don’t make it predictable. No designs in advance. Decisions on

facts.

4. Defer Commitment: No hard commitments much in advance. Flexibility in process required.

5. Deliver Fast: Deliver software so fast that customers don’t have time to change their minds.

6. Respect People: No interference. From point of view of your work, complete ownership and trust.

7. Optimize the Whole: Minimize measurements to critical ones. Optimize whole value chain.

Lean Kanban

What is Kanban?

TPS [5] defines Kanban as signal of some kind e.g. sign, card, billboard, poster etc. Toyota’s Kanban

system means managing and ensuring flow and production of materials in just-in-time production

system. What this means is process flows are controlled through completion signal by preceding and

successive stages based on their availabilities statuses. This means overheads like complex

computerized schedules and processes to track inventory/progress are no more needed.

To know more on what Kanban is and how is it implemented by Toyota Production Systems,

refer to wiki article http://en.wikipedia.org/wiki/Kanban

Pull Replenishment System

Do you fill gas in your car prescribing to some schedule decided in advance? No. You f ill it once the

indicator on your car’s dashboard approaches empty. In simple words, this is Kanban or simple pull

replenishment system.

In Toyota plant, which manufactures automobiles, which is essentially a very large scale assembly

project of thousands of part. Typical stakeholders include suppliers, workers and dealers. Dealers

based on demand in market place orders to plant by placing kanban order cards. While such cards

exist in order boards, Toyota workers continue to build cars of those types. For particular car, they

start using spare parts to be assembled from stores. As they use parts, they place kanban order

supplies card in mailbox to supplier. As supplier receives such kanban card, he refills those stores with



spare parts. As explained, whole system works end-to-end on trigger points and not on pre-decided

schedule.

Kanban in Software

David Anderson [2] defines Kanban in software as “virtual” system. The signal cards are replaced by

work items. There are no physical signal cards to function as signal to pull more work. Signal to pull

more work is inferred from visual quantity of work-in-progress subtracted from capacity (limit) at each

stage in development.

Kanban Process

There are many flavors of kanban process. But following objectives exist at core.

Visualize the workflow

The card wall is the most popular form of coordination. Each stage is marked as column with limit

written on top. Work items are marked as “Ongoing” or “Done” in that particular stage. If there is any

capacity available (capacity – Ongoing is positive), card (work item) from previous stage’s “Done” will

move into next stage. There are no other long queues waiting due to starvation. Priority will be

applied while moving card to next level.

Figure 9 Kanban card wall. Source: crisp. [6]

Limit Work In Progress

Working simultaneously on multiple work items especially in software development, reduces

efficiency and is error prone, due to context switches. Kanban believes in reducing this by putting

strict limits as indicated in above figure. Anderson [2] insists on limiting one request per developer at

any given time as a policy. Kanban, however, allows flexibility to alter this if team agrees.

Cycle Time measurement

Cycle time or lead time measures how quickly item moved from order to production. This is critical

metric from predictability point of view. Graphs are plotted for lead time against Service Level

Agreements (SLA). Average Lead time is not very useful as it neither indicates predictability nor

improvement opportunity. Spectral analysis is done to identify outliers and items that just failed to



meet the target. Root cause analysis of cluster of such “just failed” category provides improvement

opportunity.

Kaizen – Continuous Improvement

Kaizen demands workforce to be empowered and motivated to dig deep into problems, discuss

options and free to do the right thing. It is important that organization has very less inertia.

Management must be tolerant of experimental failures. Matured change management capabilities are

required. Logically, only large scale organizations are capable of conducting such experiments. But,

such organizations have greater inertia or resistance to change. It needs executive commitment to

foster culture of ownership.

Key Milestones and Meetings

Replenishment

Meeting

During this meeting, kanban system’s empty queues are replenished at

different stages through prioritization of completed items in previous stage.

Backlog Triage To address problem of growing backlogs in scrum, Anderson recommends

backlog triage in Kanban. Purpose of such meeting is to go through each

item on backlog and decide on whether to keep it or remove it. Items which

are starved for long due to prioritization are given special attention. Smaller

backlog increases efficiency of prioritization at later stages in kanban

implementations.

Daily Standup

Meetings

Contrary to scrum, there is no need to check on three questions as looking at

visual card wall addresses them. During standup meeting of kanban focusses

on flow of work. Facilitator, typically project manager, walks the board

backwards i.e. from right to left through tickets on board. Emphasis is put on

items which are blocked.

After Meetings “After meeting” is spontaneous meeting of people after daily standup to

discuss on quality improvement or technical hurdle. These are process

equivalents of “Quality Circles” in lean manufacturing.

Sticky Buddies Corbis introduced the concept of sticky buddies, a system to

telecommunicate at least a week. If a person is absent for particular meeting

then he syncs his status with his sticky buddy, who in turn represents him in

the actual meeting.

Figure 10 Source: David Anderson - Kanban [2]

References

1. Shalloway Alan, Beaver Guy, Trott James, Lean-Agile Software Development – Achieving Enterprise

Agility, Net Objectives Lean Agile Series, published by Addison-Wesley, USA, 2010.

2. Anderson David J, Kanban – Successful Evolutionary Change for Your Technology Business,

published by Blue Hole Press, USA, 2010.



3. Vega Frank, Scrum, XP and Beyond – One Development Team’s Experience adding Kanban to the

Mix, published in Proceedings of Lean Software and Systems Conference, Atlanta USA 2010

retrieved from http://atlanta2010.leanssc.org/proceedings/ on Jan 11, 2012.

4. Poppendieck Mary & Tom, Implementing Lean Software Development – From Concept to Cash,

Addison-Wesley Professional, USA, 2006.

5. Liker Jeffrey K., The Toyota Way, Tata McGraw-Hill Edition, New Delhi, India, 2004.

6. Kanban for Software, crisp, retrieved from http://www.crisp.se/kanban on Jan 12, 2012.

Chapter 5: Software Design


In this chapter…

OO Design and Design Patterns

Unit testing

Refactoring Old Code

Architectural Strategy

Introduction

In this chapter, we will focus on technicalities of software designs (not documentations)

and impact of them on various agile techniques. This will help us decide on the role of

priorities of developers, technical soundness and organizational trainings on software

design process. We will look at how the Object Orientated Languages proved to be

boon for agile development and how design patterns helped achieve objectives of

managing change. We will also look at how code should be maintained through

refactoring in order to be more agile.

Priorities while Coding

What is important? Is it the number of lines of code or is it the performance or the

cosmetics like comments and naming conventions? The organizations all over the

world have different priorities set for their developers when it comes to writing code.

And most important is what matters when you need to develop fast and accept

change.

Maintainability vs. Performance

It is widely considered that a design is a tradeoff of Performance vs. Maintainability. A

high performing code is perceived to be difficult to understand, hence hard to

maintain. This is true to certain extent. With advent of high computing and memory

hardware, in typical IT setup, the performance need not be achieved at cost of

maintainability. A well written, self-explanatory and modular code is basic necessity for

agile adoption. Maintainable code is the one which is easy to understand, analyze and

modify by person other than author.

CChhaapptteerr 55::

SSooffttwwaarree DDeessiiggnn



New Lines of Code vs. Reusability

Methodologies like TSP rely on LOC or Lines of Code for quantitative measurement of productivity.

The defects per LOC, LOC per man hours etc. are computed. However, it is very easy to manipulate. As

developers try to maximize lines of code in order to inflate their estimates, they also get license for

more defects. These both are in contrast with the Agile principles. Organizations should not mandate

their LOC based measures for agile teams.

Reusability is likelihood that already written, time-tested piece of code can be reused in the new

software. This requires code organization in modules or classes. These are unit tested and preserved

in repository. Developers requiring similar functionality can reuse or extend these. This saves time and

improves maintainability and quality of code.

Object Oriented Design

Object Oriented Design

Object oriented programming is a programming paradigm using objects which are data structures

consisting of data fields and methods together with their interactions.

For OO design tutorials, refer to 3 video lectures by Prof. B. Harvey, University of California at

Berkley at: http://www.youtube.com/results?search_query=CS+61A+Object+Oriented

Let’s look at four major principles of Object Oriented Design and how they ease Agile adoption

process.

Principle Description

Encapsulation Bundle data with methods. Bring related code together. It helps in improving

maintainability and modularity of the code.

Abstraction Real time representation of objects. Data patterns dissociated from actual storage. It

helps relating code segments more closely to real scenarios in terms of behaviors.

Inheritance Inheritance allows reuse and extension of existing code. Interface is modern form of

inheritance which protects calling object from changes in called module

code/version.

Polymorphism Overriding and overloading. It helps improve code readability by extending function

signatures with same names. E.g. Use of + operator to add two strings.

Doing it right

Simply having knowledge of Object Oriented Programming is not sufficient. The design process

should reflect the object oriented thought process. If designs prepared fail to address changes in

future, developers have tendency to patch the design as workaround. The system with such

patchworks, very common in IT systems today defeats the Object orientation purpose and becomes



critical issue in agile adoptions. Stoecklin et al [8]

defines strict criteria for writing well formed OO

method as:

High Cohesive: Similar functionality must be clubbed together. Avoid redundancy.

Low Coupling: Least dependencies for execution on other objects. Independently testable.

Low Complexity: Less than 10 paths in given method. This reduces risks of missing scenarios.

Appropriately Sized: Improve readability through declarations, sections and blank lines.

Well Documented: Self-explanatory code. Use of XML comments for auto-generating

documents.

Design Patterns

Design patterns are reusable designs based mainly on Object Oriented concepts which are generic

solutions to many common problems. Modern patterns were introduced by “Gang of Four” through

their legendary book [2], which is authority on this topic today. Some of popular patterns include

singleton, factory, bridge, memento and builder.

You can obtain brief information on design patterns with examples from Go4Experts

technical forum at http://www.go4expert.com/forums/showthread.php?t=5127

Alan Shalloway [3] strongly argues that Design Patterns form foundation for Agile Development if used

properly. As Mikio Aoyama [4] also agrees, we can identify key benefits of Design patterns as – (1) It

makes software design “Change Resistant”. What it means is that as requirements change, the design

is impacted minimally as there are no ripple effects of change in design through strict adherence to

Object oriented features described in above section. (2) Designs are developed faster. Several design

patterns are generic solutions to common problems. These are time tested. Use of patterns save time

to find logical solutions and improve quality. (3) It also increases maintainability of the program as

patterns are standard. (4) Learning design patterns help shape developers design skills and thinking

positively for agile adoption. They do not hate changes as most can be accommodated with minimal

design impact.

Unified Modeling Language

Unified Modeling Language, popularly called UML, is standardized general purpose language which

represents object oriented designs. There are 14 standard diagrams in UML representing structural

(static) and behavioral (dynamic) aspects.

Effective minimal documentation is necessity in agile adoption. The most effective way of maintaining

up-to-date knowledge base of designs is UML diagrams. Some key advantages are: (1) Developers are

trained to read these standard diagrams. So, no additional explanations are needed. (2) They are most

concise way of representing almost all issues regarding design. (3) Most of these diagrams can be

auto-generated from code. Hence, developers need not actually create them. That also ensures

diagrams are always up-to-date. (4) Sometimes code also can be generated directly from these

diagrams. E.g. Class definitions and function signatures are directly generated by most IDEs from UML

class diagram.



Unit Testing

IEEE [6] defines Unit Testing as testing of individual hardware or software units or groups of related

units. This is a type of White Box testing, i.e. the tester is aware of intricacies of the unit and is testing

using interfaces to validate them.

Test Driven Development

The Extreme Programming requires developers to write their automated unit tests first and then write

code modules that satisfy those cases. Developers refactor the code later to prescribed standards

while ensuring that unit tests continue to pass. Since, this requires repeated running of same unit

tests, the automation is recommended.

Technical Specifications

Although not widely accepted, Agile methodology can consider well developed unit test suite as

alternative to technical documentation. This requires structuring of unit tests based on broken down

events from user stories. And then unit test suite in combination with UML diagrams can substitute

tedious task of developing technical documentation sand maintaining these current during iterative

development cycle. Extreme Programming with Test Driven Development approach favors this.

Refactoring Old Code

The developers don’t always work on new code. A major part of their work is modification or

extension. The structure of old code has large impact on the performance of agile teams. Across

organizations, it is the problem that most of the old code is procedural and written without unit tests.

It is also not aligned with enterprise architectural guidelines. Such code is primary sources of defects

and delays.

Refactoring is the activity of restructuring old code to follow Object oriented or design pattern

guidelines, without altering its external functionality. Modular structures and automated unit tests are

developed. As refactoring course tutor, Yoder [7] says, refactoring is the disciplined approach and adds

importance of regression testing. Refactoring can be considered as software equivalent of lean

principle “kaizen”.

Resistance from Business

Business owners and sponsors often see code refactoring initiatives as waste of resources. Refactoring

does not alter any business functionality. Hence, it does not yield any tangible benefit for them. Many

even see this activity as developer’s obsession for cleaner code [9]. This is where the role of product

owners who represent business sponsors of project is important. Being part of team they have higher

visibility into success factors of agile processes. And from sustainability point of view, the refactoring

activities must be viewed as investments rather than expenses. Also, business may fear that new

defects may be introduced as a result of refactoring activity. Hence, a comprehensive regression and

unit testing suite must be ready before venturing into refactoring space.



Refactoring Types

Classic Fowlerian Approach

As described by Stoecklin [8], in this approach a working code is improved for clarity and design

quality.

Open Close Principle

Meyer [11] defines Open Close Principle as “software entities (classes, modules, functions, etc.) should

be open for extension, but closed for modification”. Bain [9] applies it to code as the code which is

more Cohesive, less Coupled and the one that does not have redundant segments.

Refactoring for Open Close means, code is fine but not open-close for adding new requirement.

Making it open-close as descried above makes it less risky and generates less waste while it

undergoes imminent change. In this way, business value can be derived from the refactoring.

Emergent Design

Emergent or continuous or evolutionary design is a process of continuous refactoring resulting in

improvement of program’s overall design. Jim Shore [13], a XP consultant, recommends with (1)

Automated Unit Test (2) Team based approach of collective code ownership and (3) Continuous

Improvement commitment in face of schedule pressure. He cautions however not to mix it with

design extension goals and defeat each other’s objectives by creating de lays and adding defects.

As authors Alan Harriman [11]

et al narrate their experience with database development with XP, they

scrapped pre-designed database and instead worked on incremental design. This allowed them to

use their evolving domain skills to come up with more efficient design than they would have at

beginning with limited skills and domain knowledge.

Architectural Strategy

There is ongoing debate on role of architects in agile development setting. This is due to highly

requirement oriented nature of agile processes. XP and Kanban methods even perform the change

only when it is necessary. On other hand, enterprise architecture focusses on large picture and takes

long term view through roadmaps. While it is perceived that Agile methods take more short term

view to avoid impact of changes.

Cisco’s Steve Fraser [10]

says in order to capture benefits of economics of scale and scope, architecture

is necessary. The feedback loop of Agile development can be integrated with Architectural learning

and both processes can work hand-in-hand. Microsoft’s Randy Miller [10] argues that Architecture is

not “Big Design Up Front” as many developers confuse the two. Hence, it is not necessary for

architecture to complete before development starts. Architecture is slow evolving process like agile

development is. However, it takes view of larger picture and is beneficial to both small as well as large

scale projects.

From organization setting, Agile demands Architecture to work closely with Agile teams and ensure

teams are developing aligned to enterprise architecture roadmap. But such architecture must not be

at micro-level. Clear demarcation between architecture and design needs to be highlighted.



References

1. Ramsin Raman and Paige Richard F., Process-Centered Review of Object Oriented Software

Development Methodologies, published by ACM Computing Surveys Vol. 40, No. 1, Article 3 on

February 2008.

2. Gamma et al. “Gang of Four”, Design Patterns: Elements of Reusable Object-Oriented Software,

published by Addison-Wesley Professional, 1994, USA.

3. Alan Shalloway, Design Patterns Explained: A New perspective on Object Oriented Design 2nd

Edition, published by Addison-Wesley Professional, “Net Objectives Series”, 2004, USA.

4. Mikio Aoyama, Evolutionary Patterns of Design and Design Patterns, published in proceedings of

International Symposium on Principles of Software Evolution, 2000. Available on IEEE Explore.

5. Runeson, P., A survey of unit testing practices, Software, IEEE , vol.23, no.4, pp.22-29, July-Aug.

2006.

6. IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 610.12-1990, 1990. Current

Version 2002.

7. Yoder Joseph, Refactoring at the core of agile software development, published in proceedings of

AOSD’11. Retrieved from ACM digital library.

8. Sara Stoecklin et al, Teaching Students to Build Well Formed Object-oriented Methods through

Refactoring, proceedings of SIGCSE’07, USA. Retrieved from ACM digital library.

9. Bain, Scott L., Emergent Design: The Evolutionary Nature of Professional Software Development,

Pearson, 2008, USA.

10. Fraser Haden et al, Panel Discussion, Architecture in Agile World, proceedings of OOPSLA’09 –

ACM SIGPLAN conference. Retrieved from ACM Digital Library.

11. Meyer, Bertrand, Object-Oriented Software Construction, 1988, Prentice Hall, USA.

12. Harriman Alan, Hodgetts Paul, Leo Mike, Emergent Database Design: Liberating Database

Development with Agile Practices, proceedings of Agile Development Conference 2004, retrieved

from IEEE Computer Society.

13. Jim Shore, Continuous Design, published in IEEE Software, Vol. 21, Issue 1, Jan-Feb 2004 by IEEE

Computer Society.

Chapter 6: Business Processes


In this chapter…

Customer

Function vs. Process orientation

Business IT alignment

Service Oriented Architecture

Introduction

Agile process adoption requires a mindset than just skills. In business context, agility

means capability of organization to readily adapt to changes in market and

environmental changes in productive and cost-effective ways. But in practical there are

very few examples of truly agile organizations. Most organizations, in which agile

development projects will be undertaken, are themselves highly bureaucratic and

hierarchical. They will be resistant to change. This situation actually becomes hindering

factor for truly agile process on IT side as agile processes demand IT to have close

interaction with business throughout lifecycle of project.

Today, a lot of businesses worldwide are undergoing transformations. This is due to

larger adoption of IT, Management Information Systems, Analytics, Enterprise Resource

Planning (ERP) and Customer Relationship Management (CRM) like initiatives, which

give them competitive advantage over their rivals. Businesses have also realized that

unless they are dynamic, they will perish. However, they are at different stages of

transformation. It also should be noted that IT teams (organization of CIO) have limited

control on modifications in business processes to make them suitable for IT adoption.

It is therefore imperative for IT managers to take pragmatic approach when situation

results in business processes limiting agile adoption.

In this chapter, we will look at various drivers of agility in business environment and

how they impact IT’s agile adoption initiatives. We will look at how business teams

(clients) manage change and prioritize their work.

CChhaapptteerr 66::

BBuussiinneessss PPrroocceesssseess



Customer

Let’s first define who is customer for IT. ITIL [3] defines customer as someone who buys goods or

Services. The Customer of an IT Service Provider is the person or group who defines and agrees to the

Service Level Targets. The term Customers is also sometimes informally used to mean Users.

Customer Involvement

Agile processes demand regular involvement of customers in the development phase of the project.

Xiaohua Wang et al [1] argue “On-site customer” is needed to facilitate zero-distant, face to face

communication with developers. In XP, customer activities include (1) Creating customer team to

represent requirements (2) Provide development environment (3) Review project plan (4) Feedback (5)

Requirement management (6) Consult throughout (7) Testing and demonstrations (8) Accepting

working software (signoff) (9) Trace and measure the developer’s process for ROI.

It is said, “Great Scrum needs great product owners” [6]. Judy highlights in his paper that close

collaboration beyond standard definition of roles of customers and developers is needed in order to

promote organizational efficiency and innovation that is expected out of scrum.

Common Issues

Various issues that impact agile process during interaction with customer are [1]:

Participation: Low level of customer participation as they think it’s a waste of time and unproductive

activity. This comes due to traditional mindset on IT (waterfall model). Though IT teams are going

agile, most business processes still follow sequential waterfall model. Participation in agile processes

is additional burden for customers. Especially during peak business cycles like quarter close, they will

not prioritize time for developers. This impacts agile process.

Requirements Gaps: It’s difficult for customers to think of all scenarios in requirement phase. They

can’t visualize IT outputs. Only during testing or demonstrations, they realize certain pitfalls and want

to amend their user stories. This requires recoding those modules ultimately impacting Developer

teams.

Training: Sometimes customers are enthusiastic about interacting with developers but then they

should be provided with enough training so they understand the process better.

Data issues: Customers may not be able to test all scenarios due to certain deficiencies in test data

and data flows. In test environment, end-to-end data generation is not mostly possible. Also, for agile

iterative releases, the focus is more on testing individual modules. Since, business customers are not

acquainted to such unit testing; they can’t perform exhaustive scenarios during test phase. All such

issues get leaked to the production.

Communication: Customers and development teams sometimes do not communicate each other

transparently or on time. This is especially true for bad news or delays.



Function vs. Process Orientation

As Majchrzak defines [4], functional units are those which have limited responsibility specific to their

function. These units are largely dependent on one or more units for performing upstream and

downstream tasks. While process complete units are defined as those units which control larger value

chain including most manufacturing tasks, support tasks and customer interface.

As Majchrzak concludes, cycle times are higher in case of process complete teams. This is mainly due

to reduction in effort of aggregating efforts of autonomous units. When agile processes like

Lean/Kanban are to be implemented, the transformation can’t be limited to IT organization. As

already explained in chapter on kanban, the business processes must be reengineered for such

transformation. Otherwise, agile adoption of kanban will not be able to produce desired results.

Functional Mindset

Majchrzak [4] also argues that just implementing process completeness through integrations in

responsibilities is not sufficient. The employees and managers need to develop mindset that is

process complete and not functional i.e. think about larger picture and beyond the team. It increases

organizational focus on collaboration, helps reduce bureaucratic approach. It also helps develop

common goals for front-end and back-end employees which are more closely aligned to business

goals.

In terms of Agile software development, this approach helps as agile demands customer focus and

larger business interaction from software developers.

Business IT alignment

Business IT alignment is defined in terms of

Business Processes, Information Technology

Organization, Information and Applications.

Business Processes refer to workflows in

business operations of the firm, they define

how firm operates and delivers products or

services to customer and receives revenue.

Information Technology refers to

organizations that are catering to automate

these processes. Gartner says more than 85%

Fortune 500 companis are fully operating on

ERP. There is also constant increase in ERP

adoption by small and medium businesses and

miscellaneous organizations like schools, NGOs and hospitals. Most of these organizations have

dedicated IT teams of varying size. Information refers to the business data that is generated, shared

and churned by IT systems as part of various business processes. Applications refer to various

platforms, UIs and tools that help business users and customers to carry out their operations. Many

applications may act at different stage in data pipeline.

For faster agile development cycles, the alignment of various teams in IT organization must be with

corresponding business units from operations. However, IT needs to account for shared dependencies

in terms of application platforms and data. For e. g. a customer may be enrolled for two different

Business Processes

Information

Applications

IT



businesses with same firm. However, if corresponding IT units operate in silos, customer will need to

manage two separate accounts with the firm, which increases redundancy in data and costs for the

company.

ERP integration – a driver for change

Most organizational structures underwent changes once they embraced ERP. ERP aggregates

information spread across organizations. This highlights redundancies and inefficiencies in the

organization structures. For obtaining true ROI out of ERP integration and gain competitive

advantage, the businesses have to realign themselves. ERP integration creates efficient Business-IT

organization structure. Such structure favors adoption of agile development processes by IT

organizations.

Types of Alignment

Chen defines Business-IT alignment is of following types –

Alignment by Architecture

This alignment is mostly driven by Enterprise Architecture team which provides cross-functional and

cross-discipline collaboration to deliver complex business processes. This ensures application and

information systems are designed along with data flows in order to eliminate redundancy costs.

Alignment by Governance

IT Service management works on value propositions and aligning business-IT operations. Delivery,

performance, risks and resource management is aligned across Business and IT. Regulatory

compliances are ensured and IT audit handles managerial control.

Alignment by Communication

The communication gap between customer and developers exists due to cultural gaps. In this

method, organization provides trainings to bridge this gap. IT strategy is aligned to business strategy.

Effort is taken to develop common terminology to address business applications.

What Agile Development wants?

Alignment by Application is most desired and naturally most difficult to achieve. But from agile

development process point of view, for techniques like scrum and XP, a communication alignment is

sufficient as minimum condition. But, if organization is aiming for Lean/Kanban implementation, then

it needs to achieve governance alignment as basic minimum. In the long run, architectural roadmap

should include Architectural alignment as strategy.

Service Oriented Architecture (SOA)

Haki and Forte [7]

define SOA from business perspective as set of services that business wants to

expose to its customers or partners or other portions of organization. The SOA approach for

organizational functioning gives interoperability, flexibility, transparency, cost-effectiveness and

innovation. Following diagram depicts the architecture proposed by Chen [8]. For detailed information

on various features of schematic, refer to the paper.



Figure 11 Chen's IT Alignment with SOA schematic [8]

Implications for Agile Development

The SOA in business have following implications on agile development process in IT organizations.

Enabling the communication: This architecture enables communication within various parts of

organization including various business stakeholders and IT management or developers. This is

critical requirement for agile teams.

Responding to Change: Businesses can respond to changes in market scenarios effectively. This

flexibility in business processes reduces impact of change on the agile development teams.

Support for innovation: The innovation delivery is simplified in SOA organizations. Creative use

of IT resources can result in innovative customer strategies. The role of CIO expands into

innovation leader and IT becomes trusted business partner. Examples of such innovations can be

changing business processes due to implementation of cloud or social networking technologies.

References

1. Xiaohua Wang et al, The Relationship between Developers and Customers in Agile Methodology,

published in proceedings of Int’l conference on Computer Science and Information Technology,

retrieved from IEEE Computer Society.

2. Salhofer Peter, Ferbas David, A pragmatic approach to the introduction of e-government, published

in proceedings of dg.o’07. Retrieved from ACM digital library.

3. IT Infrastructure Library v3, An Introductory Overview of ITIL® V3, IT Service Management Forum.



4. Ann Majchrzak, Qianwei Wang, Breaking the functional mindset in process organizations, Harvard

Business Review.

5. Oualid Ktata, Ghislain Lévesque, Agile development: issues and avenues requiring a substantial

enhancement of the business perspective in large projects, published in proceedings of C3S2E '09

retrieved from ACM Digital Library.

6. Judy, K.H., Great scrums need great Product owners: Unbounded collaboration and collective

Product Ownership, Proceedings of the 41st Hawaii International Conference on system sciences,

2008

7. Haki, M.K., Forte, M.W., Proposal of a service oriented architecture governance model to serve as a

practical framework for business-IT Alignment, New Trends in Information Science and Service

Science (NISS), 2010 4th International Conference on, 2010. Retrieved from IEEE library.

8. Chen, Hong-Mei, “Towards Service Engineering: Service Orientation and Business-IT Alignment,”

Proceedings of the 41st Hawaii International Conference on System Sciences, 2008.

Chapter 7: HR Practices


In this chapter…

Recruitment

Performance Management

Trainings

HR policies

Introduction

Software organizations aiming adoption of agile methods for large projects need

holistic transformation. Vital change is required in firm’s Human Resource practices. As

David Moran [1] says the industry trend is generally towards “Doing more with less”,

and “Doing More” involves innovation. Moran [1] further adds that onus is on managers

of knowledge workers in order to create motivated, productive and innovative work

environment.

Toyota Production Systems (TPS) [3] highlights “developing people through Respect,

Challenge and Grow” as one of the key principal reasons of Toyota’s success. Liker [3]

elaborates these principles as –

Growing your leaders rather than purchasing them

Toyota grows leaders internally as they live in firm for longer time and understands its

day to day culture thoroughly i.e. genchi genbutsu, means deeply observing actual

situation.

Develop excellence in individual work while promoting effective team work

Toyota puts tremendous time in hiring right candidates as it focusses on effective team

work where a group work does not compensate for lack of individual excellence.

In this chapter, we will look at how various HR practices like recruitment, performance

management, trainings and other HR policies impact on adoption of agile processes.

CChhaapptteerr 77::

HHRR PPrraaccttiicceess



Figure 12 Crocitto, Youssef [2]

Model of organizational agility

Recruitment

The recruitment policies of the firm are responsible for bringing right talent required for agile

adoptions.

Workplace Diversity

As Andrea Tapia [4] mentions, IT industry faced a sudden explosive growth during .com bubble. The

gold rush of hiring talent resulted in homogeneous employee population with following

characteristics.

(1) Unconventional hiring processes resulted in exclusion of women and older people.

(2) Values like heroic behaviors, internal competition, crisis-based work environments and living at

work were promoted.

(3) Non-technical staff was devalued. Technical staff (mostly men) enjoyed unconventional freedoms

while non-tech staff (mostly women) was bound into strict bureaucratic rules. This created divide.

This made IT workplaces almost impossible places to work for women. Although most IT behemoths

have agreed in recent past to transform their processes to correct this situation, most initiatives

have remained on paper maintaining ground reality unaltered to great extent.

If we look at proven principles of Lean or Agile, we find gross violations with this type of culture

predominant in Software organizations. Any work organization must be representative of the

population from which it is derived. No company survives on “template” employees. Especially agile

adoption requires multitalented and dynamic employees at workplace. The diversity of hiring in terms

of gender, race, religion, age, culture, color, physical abilities and sexual orientation is imminent for IT

organizations.



Desired Competencies

As explained with Toyota’s principles, individual excellence and effective team work are of utmost

importance while hiring employees for agile development teams. Below table highlights what

competencies are needed from collective agile team. Every member need not or can’t have all of

them and hence diversity at workplace is needed. It also highlights competencies of manager and

minimum competencies of individual members required for effective agile adoption.

Agile Team’s Collective Competencies

1. Required Technical Skills

2. Required Business Knowledge

3. Customer Focus*

4. Dealing with Ambiguity

5. Problem Solving

6. Creativity

7. Respecting Differences

8. Positive Conflict

9. Change Management

10. Decision Making

11. Collective Ownership

* also, Agile Leadership Qualities

Agile Team Managers’ Competencies

12. Innovation Management

13. Fostering Diversity*

14. Understanding Company Culture*

15. Develop and Grow People

Agile Team Members’ Individual

Competencies

16. Communication Skills

17. Interpersonal Skills/Team Skills

18. Integrity and Trustworthiness

19. Accomplishment Orientation or passion

20. One or more of the collective competencies

In one way, software teams differ from lean manufacturing is, lean manufacturing relies on

standardization of tasks for improving productivity of employees. This is not true for software as there

are no standardized tasks that a developer does over period of time. Developers improve productivity

through varying experiences, developing strong problem solving skills.

Staffing levels

As explained in lean principles and extreme programming principles, agile teams adjust change in one

variable by making change in other variables from time, scope, resource, quality [5]. As described in

case study on Menlo [6], overtime is strict NO for agile teams. This means, agile teams need to increase

resources in order to deliver increased scope in given time without quality compromise.

Does this mean agile firms should maintain excess workforce, a concept of “bench” in typical service

organizations? No, that is inefficiency. As evident from the case of Menlo [6], it means building a highly

mobile workforce. This means based on requirement resources should be both increased or

decreased from given agile team on weekly basis. This requires separation of functional and technical

skills. Assign workforce on skill basis to various projects. The members switch between projects based

on skill requirement for particular period and not project duration.

To find some interesting examples of hiring techniques employed to identify right

candidates for agile methodologies like XP/Pair Programming, refer to Menlo’s case in [6].



Performance Management

Review Process

Peer Review

Agile emphasizes on team performance. Hence, individual’s performance review should comprise of

feedback from team members. Some companies follow anonymous feedback or in some feedbacks

are sent to managers alone. Effective agile teams should be more open on such feedbacks.

Transparency also improves accuracy of these feedbacks. What this means is individual should be

aware of what each of his peer thinks about him. Google [8] even conducts performance review

interviews with peers.

Review Cycles

There should be at least two (ideally 3-4) performance review cycles, as this gives ample opportunities

to employees to correct his shortcomings. Google [8] conducts two such official cycles, but also

remains open for any feedback/review sessions anytime in the year. As per continuous improvement

principle of agile, frequent review cycles are desirable.

Compensation

Salary and Performance Bonus

A competitive base salary (fixed) which translates into monthly pay, followed by performance linked

cash bonus (variable, approx. 10%) is very standard pay package that software employees receive.

Most software companies also review their base packages and provide increments based on market

conditions. Some companies provide merit increments based on performance even without

promotions. Some companies like Google [8] factor employee performance and company performance

as multiplier in determining increments.

For effective agile adoption, team work needs to be rewarded. As evident in Menlo’s example [6], the

performance bonus and increments should factor the team performance as additional component.

This creates motivating environment for individual excellence with effective team work.

Stock Options

Public listed firms reward performance of their employees by awarding stock options. Some

companies provide Employee Stock Options (ESOPs) or some provide Stock Awards. This is pay

component linked to overall performance of the firm in the market. Though individual’s work has

hardly any relation to stock performance, it helps in creating sense of collective ownership in the

employees. Companies like Microsoft [7] award stocks which mature over stipulated period, which

helps it retain employees for longer period and reduce turnover.



Career Growth

Aspirations

Google [8] provides 20% time for Innovation. This is one great practice which provides employees

dedicated time to pursue their professional interests, which ultimately help company. When diverse

employees are hired, companies should show sensitivity to their own aspirations at workplace.

Deloitte Touche Tohmatsu [9] provides easy rotations and transfers across its global member firm

network. This helps address employees’ aspirations for breadth of experience. It also contributes to

create global mobile workforce for required organizational agility.

Promotions

Accomplishment oriented people require increasing career growth graph [10]. Company should

identify right talent and promote them on regular basis, linked to performance and the experience. An

employee should see his career path, have clarity on requirements of next stage, plan on acquiring

those skills and experiences and then deliver on those goals in order to reach to the next level.

Special Awards

Team Success must be rewarded but individual contributions should not be forgotten. Extraordinary

individual commitment and excellence result in overall team success. Organizations should recognize

and publicly reward individuals and teams both separately for their contributions. This becomes

motivating factor for accomplishment oriented individuals working on agile development teams [10].

Training

Holistic Development

As wide range of competencies are expected from agile team employees, companies should provide

trainings on required technical, business, organizational and interpersonal skills to all their employees.

Dissemination of Know-How

Agile teams learn valuable know-how on job. The process evolves based on experience of team

members. These experiences must be shared with others. Companies should encourage teams to

write white papers on each project experiences or present in forums like internal conferences or

events.

Mentorship Program

For career guidance, companies provide mentorship programs where employee and mentors have

freedom to choose their respective mentors and mentees of choice based on topics of discussion.

This helps employees to build networks and trusted relationships outside their work organizations.



Other Human Resource Policies

Flexible Timings and Holidays

As Menlo case [6] indicates, flexible timings are important so that employees can work based on their

convenience. This also improves collaboration and specifically required for teams which a re globally

distributed or in scenarios like pair programming in XP practices.

Perk Friendly Workplaces

SAS Institute, which figures consistently as No. 1 in best employer list in the world, provides recreation

centers, spa, babysitting, sports facility and food courts on its campus. Leaving out SAS or Google

which are more liberal, standard software employee perks include free drinks, work from home, free

parking, phone/internet reimbursement. However, such perks are norm at any software firms, there is

no specific requirement from agile adoption point of view.

References

1. David Moran, the challenges of managing knowledge workers, Supervision; May 2010, Vol. 71 Issue

5, retrieved from Business Source Complete.

2. Madeline Crocitto, Mohamed Youssef, The Human side of organizational agility, Industrial

Management and Data Systems, Emerald 2003.

3. Liker, Jeffrey K. (2004), The Toyota Way: 14 Management Principles from the world’s greatest

manufacturer, First Edition, Tata McGraw-Hill.

4. Andrea Hoplight Tapia, Hostile Work Environment.Com: Increasing Participation of

Underrepresented Groups, Lessons Learned from the Dot-Com Era, The DATA BASE for Advances

in Information Systems Fall 2006 (Vol. 37, No. 4).

5. Extreme Programming Pocket Guide – Team Based Software Development, O’reilly Canada 2003.

6. Clement James Goebel III, PMP, Menlo Innovations, How Being Agile Changed Our Human

Resources Policies, proceedings of Agile Conference 2009, retrieved from IEEE Computer Society.

7. Microsoft Employee Stock Award and Executive Compensation plan retrieved on Jan 23, 2012

from

http://www.microsoft.com/investor/reports/ar11/financial_review/employee_stock_savings.html

8. Google performance review experience, retrieved on Jan 23, 2012 from

http://www.quora.com/How-are-performance-reviews-done-at-Google-What-are-they-used-for

9. Deloitte Touche Tohmatsu’s International Mobility program, retrieved on Jan 23, 2012 from

http://careers.deloitte.com/united-states/experienced-

professionals/learndev_globalprograms.aspx

10. Giovanni Aspron, Motivation, Teamwork, and Agile Development, Agile Times, Volume 4, 2004.

Chapter 8: Delivery Models


In this chapter…

Distributed Teams

Outsourcing

Offshoring

Software As Service model

Open Source Delivery Model

Introduction

We have seen so far that agile methods like scrum, kanban or eXtreme Programming

are well suited for the development teams and customers are collocated together. But,

for obvious economic reasons, globally distributed teams for software development is

imminent. Organizations are increasingly relying on outsourcing and offshoring in

order to drive down costs, access larger talent pools and provide support round the

clock. If agile team members are spread across locations, then there are challenges

with respect to work timings, coordination and communication. Outsourcing on other

hand creates heterogeneous teams consisting of members from different

organizations, and hence poses challenges due to difference in organizational culture

and HR practices like performance reviews, incentives etc.

Software-as-a-Service (SaaS) model is developing very fast, where companies instead

of selling customized software, are hosting the applications themselves and licensing

based on usage to clients. Surveys indicate [2] SaaS companies are increasingly

adopting agile methodologies. In this chapter, we will also look at agile adoption

factors for companies relying on SaaS based software delivery.

Open source development model is one emerging model used by companies like GE

or IBM where certain middleware or frameworks are developed on open source

principles, which are sponsored by these firms. It is interesting to note how such teams

are following principles like extreme programming.

CChhaapptteerr 88::

DDeelliivveerryy MMooddeellss



Distributed Teams

Distributed team means when members working on same project while they are not located under

one roof. This involves various team configurations as explained below.

Terminologies

Some terminologies in distributed teams for software development are [1]:

Offshoring: Offshoring means when company opens facilities outside home country, typically in

developing countries like India or China and hire local talent as employees of its subsidiary in order to

carry out software development.

Outsourcing: Outsourcing means when company (client) hires services of third party organization

(vendor) to completely or partially develop software for its own consumption. The client firm and not

the vendor retains complete ownership over the developed product. There exists a short term or long

term contract specifying resources and price.

These can be summarized by the table:

Table 1 Distributed Team delivery models

Onshore Offshore

Insource Same firm/same country Same firm/different country

Outsource Different firm/same country Different firm/different country

We will now see various success factors for these delivery models from agile development

perspective.

Offshore Teams

Ramasubbu [8] identifies that dispersion has negative impact on productivity of software projects but

can be mitigated by structured engineering practices. Mindtree Ltd. has identified some critical

success factors for distributed teams in order to work on agile [7]. Based on that study, we have

derived some factors as below.

Base Camp

Selected individuals from distributed teams should spend some time together at central location.

Activities included in base camp are drafting initial high level requirements, initial user stories, plan on

coding standards and communication methods. This is also recommended by Banerjee et al of NIIT [9]

from their experience of executing distributed agile project from India.

Flat Structure

It is important that teams located globally are equal and not reporting into particular location. The flat

hierarchy is important characteristic of agile teams. This should be facilitated by having leads or

representatives at each level which enjoy equal decision making power.



Crisp Handovers

Daily standups require time flexibility and should be restricted to each location. The handovers and

coordination should be done by daily meetings between leads or representatives at time zone

overlap.

Query Tracking

Any queries or clarifications should not be tracked over emails or chat as it is difficult to track them.

The best way is to track them using query tracking tool like Visual Studio which can help with work

items which can be assigned to concerned people and easily tracked for completion.

Plan Test Drives

Test drives should be planned at sufficient frequency at each location. The representatives from other

locations should participate in this activity.

Internal Quality

Since development team does not sit together while working on same project, it is important that

internal quality is provided sufficient attention. This includes coding standards, naming conventions,

test procedures etc. It also should focus on proactive assessment of progress, quality and

performance [8].

Effort variance

Redistribution of work overseas may be problematic. Hence, effort variance should be computed first

at local level, make required adjustments and then it should be adjusted globally. Since, handovers

across locations are not very easy, it should be kept at local level.

Outsourced Teams

When the teams are composed of members from different organization, i.e. outsourced work,

location difference specific problems may still apply if these are different. But, even at same location,

due to organizational differences, following additional success factors are important.

Fixed Price Contracts

Most outsourcing vendors work on fixed price contracts. Under such contracts, vendor may not

accept frequent changes as expected from agile teams [10]. It is also biggest point of contention. Client

can derive the benefit of changing requirements only if client is ready to absorb the additional costs

of change without burdening vendor or else ready to exchange requirements as mutually agreed by

vendor. This must be captured in the agreements signed for outsourcing.

Equal Training Levels

Generally vendor organizations are responsible for training of their employees and not client. This can

result in inadequate training for vendors compared to client employees. Client organizations should

therefore provide required training themselves or make it contractual obligation.

Equal Skill/competency level



Heterogeneous teams of client and vendor employee should be at par with competency and skill

levels. If there are drastic differences, then those members dominate decision processes creating sort

of hierarchy.

Incentive systems

We have seen importance of performance measurement and HR policies on agile projects. Vendor

employees working on the project should have same level of motivation. It can be ensured only with

similar performance based incentive system. The client should bind vendors with contractual

obligation on same. It is critical for success of agile process.

Vendor Leads

Vendors working with client in a mixed team should have lead of their own (ambassador as

recommended by Batra [10]

) to represent them. The vendor lead also should enjoy decision making at

par with the client lead. This creates feeling of ownership and trust among vendor teams.

SaaS Model

Software-as-a-Service or popularly called as SaaS, is a software delivery model in which applications

and/or data is stored centrally on internet or cloud, which is consumed by users which are thin clients.

Gartner [5] predicts strong growth of this business model as companies worldwide look upon bringing

their IT infrastructure costs down. The SaaS solution itself represents lean approach of just in time

consumption of required resources. This allows companies to focus on where they excel i.e. doing

their business and not in maintaining huge IT infrastructure.

The main SaaS vendors include IBM, Microsoft, Amazon, Google, Oracle, SAP. With SaaS model, the

vendors have found that the frequency of releasing major version updates is much higher than it was

in earlier desktop based applications.

Why Agile is Good for SaaS?

Agile methodologies help achieve some of key objectives for SaaS vendors and hence are increasingly

becoming popular among them. The alignment is as below [2]:

Dynamism: There is tough competition between SaaS vendors to roll out features that client

wants. Agile allows them to release short frequent updates capturing requirements on ad-hoc

basis.

ROI: Agile allows release of usable features immediately, hence companies can realize quick

returns on their investment without waiting for 2-3 years of development time.

Open Design: The essence of SaaS is in interface based design allowing clients to consume those

services, which is also goal of agile achieved typically through design patterns based practices.

Integration: Agile processes demand good integration between systems in order to facilitate early

demos. The similar integration has to exist for effective delivery of SaaS, as all client systems

consume services through interfaces. And each such service should be black-box testable always.

Working Software: Both agile and SaaS needs software to be in working shape at all time.



How Agile differs for SaaS?

Main differences in implementation are as follows:

Customer Requirements: There is no one customer for which SaaS software is developed. It is

more generic approach of software development which exposes all functionality through services.

From SaaS development teams, customer are the product managers and account managers who

interact with main clients and compile generic requirements for each release.

Ownership: The customer is not product owner in SaaS environment, he is a consumer. Hence,

increased participation as expected by Agile is not possible throughout development cycle.

Typically SaaS updates are released for consumers only after signed-off internally. The vendor

company will own the software and is responsible for maintaining it to extent as promised

through SLAs. Consumers are free to subscribe or unsubscribe to the service.

Customer Process: The customers of SaaS can’t consume services without making changes to their

processes. For e.g. various customers of billing SaaS service will ultimately converge their

processes in order to match the interface. This has resulted in more standard and interoperable

software development among customer organizations. This will further enable them to adopt

agile processes for their internal usage.

Open Source Model

Open source model is when a community of volunteers takes up tasks of developing particular

software and perfects the software through continuous peer reviews, alterations and discussions. This

is considered most democratic way of developing software. Many commercial companies are

exploring this model through sponsorships where they actively participate in specifying requirements

and driving the project but neither employ the volunteers nor own the code developed by them. They

instead use these frameworks to develop applications on top of them, to monetize their efforts. Most

common example is development of Linux kernel. Thousands of developers contribute to these

updates including Linux creator Linus Torvalds. The Open source delivery principles share several

values with Agile manifesto. Even many agile implementations in open source projects have been

successful.

Shared Values

Table 2 Shared Values [3]

by Open Source and Agile

Agile Methodology Open Source Methodology

Short period cycles, continuous delivery “Release Early, release often” motto

Customers and Developers work together Participating users/moderators serve the role

Motivated team members, trusted with their

expertise

Motivated team members, trusted with their

expertise

Working software as measurement of progress Well documented code is the only artifact

Continuous improvement, refactoring and

technical excellence

Constant peer reviews, innovation and

improvement through frequent releases



Self-managed teams Open source teams manage themselves as

community (democratic approach)

Regular reviews, feedback and postmortems Continuous reviews and alterations/suggestions

Success Factors

Tsirakidis [4] has identified following factors for successful implementation of agile techniques in an

open source model:

Constant, synchronous and transparent communication: Through use of advanced ICTs, the team

members are constantly informed about any changes in the project specifications. It is also

important that such members can communicate to each other though blogs, notifications and

personal messages. It is also critical that customers trust these development members and

provide all of them with required information.

Consistency in methodological development: A standardization of development methods is

needed in order to bring consistency. This may include coding standards, testing standards,

check-in and review procedures.

Geographical dispersion management: Dispersion management techniques like right selection of

volunteers, peer reviews, result orientation, feedback mechanism are needed for effective agile

implementation in such teams.

Understanding and Accepting environmental limitations: Customers should not expect similar

maturity in development environment. E.g. perform more unit tests than end-to-end testing.

Customers should understand that the benefits of this model are outweighing the drawbacks.

General Electric VTK project – a case study

Goldman [3] states that Visualization Toolkit (VTK) open-source project has integrated open-source

and extreme-programming practices to satisfy GE's need to express to customers its commitment to

quality, even in projects only partially controlled by GE. Furthermore, GE has tapped into a larger

development community to assist its own small team, so that its customers get the benefits of a high-

functionality, high-quality system infused with GE values. For more details, refer to DreamSongs URL

in reference [3].

References

1. Jalali Samireh, Wohlin Claes, Agile Practices in Global Software Engineering – A Systematic Map,

published in proceedings of 2010 International Global Software Engineering Conference, retrieved

from IEEE Explore.

2. Rajesh Ranjan, SaaS and Agile – Match made in heaven, Mindtree Programming Blogs, retrieved

from www.mindtree.com on Feb 1, 2012.

3. Ron Goldman & Richard P. Gabriel, Innovation Happens Elsewhere - Open Source and Agile

Methodologies, retrieved from http://dreamsongs.com/IHE/IHE-28.html on Feb. 1, 2012.

4. Tsirakidis, P., Kobler, F., Krcmar, H., Identification of Success and Failure Factors of Two Agi le

Software Development Teams in an Open Source Organization, proceedings of ICGSE 2009,

retrieved from IEEE.



5. Gartner Says “Worldwide Software as a Service Revenue Is Forecast to Grow 21 Percent in 2011”

retrieved from Gartner.com on Feb 2, 2012.

6. Rick’s blog on SaaS, http://softletter.com retrieved on Feb 2, 2012.

7. Bavani Raja, Critical Success Factors in Distributed Agile for Outsourced Product Development,

Mindtree Ltd.

8. Narayan Ramasubbu, Rajesh Krishna Balan, Globally Distributed Software Development Project

Performance: An Empirical Analysis, Proceedings of ESEC-FSE’07. Retrieved from ACM.

9. Udayan Banerjee, Eswaran Narasimhan, Kanakalata N, Experience of Executing Fixed Price Off-

shored Agile Project, NIIT Technologies Ltd, proceedings of ISEC’11. Retrieved from ACM.

10. Dinesh Batra, Modified Agile Practices for Outsourced Software Projects, Communications of the

ACM – September 2009. Retrieved from ACM.

Chapter 9: IT Management


In this chapter…

Project Management Office

Project Governance

Management Policies

Support Teams

Introduction

Agile teams are self-organizing. So a manager’s role is no more traditional. Practices

like Lean require holistic transformations in organizations as evident from examples of

Toyota. The Agile is no different. If organization expects to derive larger benef its from

such engagements then it needs to adapt its IT project management practices too.

The ScrumAlliance® defines role of Agile management as following diagram [1]. We

have already covered some functions. In this chapter, we will look at how IT

governance, funding, support teams, organizational structure and management

policies like conflict management, change management impact success of agile

methods.

Figure 13 Role of Management, Source: ScrumAlliance® [1]

CChhaapptteerr 99::

IITT MMaannaaggeemmeenntt



Project Governance

Project Management Office

The role of Program Management Office (PMO) is to manage resources to maximize returns while

balancing risks. Many successful organizations like VeriSign, Microsoft, Barclays have created PMOs

which oversee critical projects. Following are success factors from IT Project Governance point of view

for effective agile implementations.

Roadmaps

When there are backlogs in agile processes, why do we need roadmaps? VeriSign [2] credits success of

its agile programs to PMO roadmaps which helped it –

1. Help in prioritizing backlog items

2. Ensure IT is delivering in-line with organizational strategy

3. Facilitate architectural evolution due to visualization of future probable requirements

4. Provide customers near term commitments and long term point of view

Requirement Control

In line with agile lean principles, all possible waste should be reduced. This includes avoidance of

documents, meetings and discussions unless absolutely necessary. The PMO of VeriSign [1] also

facilitated a process to manage changes requested in requirements in order to ensure they are

accommodated and teams are not impacted. This is as described below.

Business Case Track

For complex requirements a

detailed case/stories/BRD is

needed. It follows standard track

of stories->Backlog->planning.

Fast Track

If newly requested functionality

is aligned to previously defined

roadmap then, it moves to user

stories and into agile process.

Inquiry Track

If newly requested functionality

does not have enough clarity, it

needs to be investigated further

in order to define the scope.

Project and Team Size

PMO needs to ensure that the project and team size does not grow beyond manageable limits. Each

company, based on its expertise and resources can effectively manage certain size of project. Beyond

that the risks start outweighing benefits. PMO needs to proactively detect such breakeven points and

break such projects into multiple teams and releases in order to balance the risks.

Project Funding

The key principle of agile is to welcome change. Accommodating change results in changing budgets

or requirements. So, the way in which projects are funded is important to determine success of agile

projects. This is especially true when there are tight cost controls or you are dealing with vendors on

fixed price contracts. But, even for internal relaxed funded IT teams, any variance in budgets is always

important issue.



Budget Process

The budgeting process begins very early in most of organizations which define high level

requirements for various projects and allocate funds for them based on priority order. These methods

are generally not suitable to agile way. The organizations must implement quick IT investment change

management processes for effective agile implementation [3]. This can include formation of funding

bandwidths for each project and delegating change control to PMO or General Managers.

Measure of delivery

For effective agile deliveries, the measure of delivery should not be set of requirements but amount of

functionality. This means, business and development teams should define way of quantifying

functionality and decide upon them for given budget. If any particular requirements change, the

development team can trade for something of equal functionality measure from next sprint without

altering budget.

Management Policies

Business Policies

Conflict Management

As concluded by Domino et al [7], a positive conflict helps drive innovation. Managers’ crucial task is to

encourage such conflicts enabling employees to break through hierarchies and challenge the status-

quo. However, they need to ensure that it does not cross such thresholds to impediment the project

progress. Employees should therefore be trained on crucial conversational and business negotiation

abilities to find way through creating win-win situation for all.

Vision, Mission and Organizational Goals

Employees with clarity on organization’s vision, mission and short-term or long term goals can

contribute better to organizations. Surveys indicate that it is motivating for employees to see direct

connection between his work and organizational strategy or goals. Organizational leaders therefore

should communicate organizational challenges, goals, policies, decisions and overall progress on

regular basis to all employees reporting into them.

Virtual Program Management

Organizations like Microsoft [6]

follow parallel hierarchy of Program Managers to Developers and

Testers. This means they do not report to PM. Also, PM is not directly responsible for their reviews,

only feedback applies similar to peer feedback. They report to their respective leads or managers. This

ensures that their interests are secured and longer career paths are provided without changing

functions. The flatter structure helps drive innovation. But this makes job of program managers little

difficult as he needs to rely on his persuasion skills as he lacks direct authority over project resources.



Employee Oriented Policies

Work Life Balance

Manifesto indicates agile process promotes sustainable development [5]. Agile process emphasizes on

neither any ad-hoc work nor stressed out weekends. To remain motivated and committed to

excellence, the employee’s work life balance is crucial. It is recommended that organizations have

institutionalized Work Life Balance policies like flexible timings, paid holidays and work from home.

Open Door policy

Managers should be available all time for immediate resolution of any concern employees may have.

Employees should be able to discuss any conflicts during project immediately with his managers. This

ensures that projects are not impacted due to such disturbances.

Support Organizations

The Support groups in IT organizations primarily consists of (1) Infrastructure Support (2) Data

Support and (3) Application Support. These groups own applications in their run time unlike

development teams who own them during design time. While applications are under usage to run

business operations, users or customer require a variety of assistance. This is typically covered under

Application and Data support. Also, the applications and data are monitored in order to ensure they

are up and running and consistent. The corporate data is not static and stored at one location. The

huge data flows exist due to various sources and consumers of the data. Also the organization needs

to look after its servers and data centers, which comes under infrastructure support.

Any development team needs to work closely with support teams in order to deliver their products. In

many companies, sign offs from support teams are included as part of process before a newly

developed software is released to production.

Following are success factors from support organizations point of view for effective agile

implementation.

Regression Testing

Frequent agile releases require frequent regression testing which is generally done by support teams.

It is not practical to execute entire regression suite every time a release goes in. In order to optimize

the work, it should either be automated or support teams should identify impacted areas for each

release and run a portion of regression suite.

SLAs

There are service level agreements in place while handling production issues. This puts expectation on

development teams to fix any code issues within stipulated time. Support teams should provide

separate test environments for such quick fixes as development environments can’t be disturbed.

Test Data



Support teams also maintain recent test data for pre-production environments. These should be

refreshed frequently considering corporate data flows and agile release frequencies to ensure test

environments are as close to production. This simplifies business testing process greatly.

Involvement

Ideally the support team should maintain a point of contact with agile development team. He should

at least attend product planning, sprint planning meetings. This will give idea to support

organizations what they can expect and what they should provide for each sprint release.

References

1. ScrumAlliance, The Manager’s role in Agile, retrieved from http://scrumalliance.org on Feb. 3, 2012.

2. Peter Hodgkins, Luke Hohmann, Agile Program Management: Lessons Learned from the VeriSign

Managed Security Services Team, Agile 2007 Conference, IEEE Computer Society.

3. Thomas Joseph, Baker Steven, Establishing an Agile Portfolio to Align IT Investments with Business

Needs, Agile 2008 Conference, IEEE Computer Society.

4. Bhaven Sheth, Scrum 911! Using Scrum to Overhaul a Support Organization, Agile 2009

conference, IEEE Computer Society

5. Agile Manifesto Principles, Retrieved from http://agilemanifesto.org/principles.html on Feb 4,

2012.

6. Steven Sinofsky, Microsoft Corp., PM at Microsoft, retrieved from

http://blogs.msdn.com/b/techtalk on Feb 4, 2012.

7. Domino M, Collins R, Hevner A, Cohen C, Conflict in Collaborative Software Development, SIGMIS

Conference 2003, retrieved from ACM.

Chapter 10: The Framework


In this chapter…

Initial list of Factors Identified

Research Method

Factor Analysis

Conclusion

Looking Back

This research report was structured to serve as complete guide to organization looking

for agile software development methodology adoption. In this study, we looked at

three methods – Scrum, Extreme Programming and Kanban. Then we looked at various

factors under 5 areas – Software Design, Business Processes, Human Resource

Practices, Delivery Model and IT Management. A massive literature survey was carried

out to list down the factors. A total of 12 books, 20 online sources and 38 published

papers from sources like ACM, IEEE, Business Source Complete and Emerald were

reviewed in order to extract initial list of factors. The papers were selected based on

relatively higher citation count. Paper containing surveys or case studies describing

experiences of users were preferred. Any paper discussing same topic i.e. factors

affecting adoption were ignored to avoid any bias from different experiments

conducted by those authors.

In previous 9 chapters we have seen in detail various factors that affect the agile

software development methodology’s successful adoption in organization. As

discussed in below section we have identified 51 such factors from various literature

papers surveyed. In this chapter we explain how the exploratory study was conducted.

First, the research method will be explained and then results will be analyzed in detail.

We will finally reduce these 51 factors by grouping correlated factors together.

Initial List of Variables Identified

Following variables were identified from literature survey. These variables are divided among 5

sections.

CChhaapptteerr 1100::

TThhee FFrraammeewwoorrkk



Section Variable ID Variable Name

Software Design

VAR00001 Maintainability

VAR00002 Measurement of Output

VAR00003 Reusability

VAR00004 Object Oriented Design principles

VAR00005 Knowledge of Design patterns

VAR00006 Automated Documentation

VAR00007 Unit Test suite as documentation

VAR00008 Automated Unit Testing

VAR00009 Refactoring

VAR00010 Refactoring Commitment

VAR00011 Architectural Strategy

VAR00012 Evolutionary Design

Business Process

VAR00013 Customer Availability

VAR00014 Customer Knowledge on Agile

VAR00015 Customer Communication

VAR00016 Customer Transparency

VAR00017 Self Sufficient Team

VAR00018 Knowledge about client usage

VAR00019 Business Alignment

VAR00020 Process Reengineering

Human Resource Practices

VAR00021 Wider competencies

VAR00022 Diverse Teams

VAR00023 Mobile Workforce

VAR00024 Peer Reviews

VAR00025 Team Performance over Individual

VAR00026 Encourage Innovation

VAR00027 Mentorship

VAR00028 Soft skills training

VAR00029 Best practice sharing

VAR00030 Employee Perks

VAR00031 Flexible timing

Delivery Models

VAR00032 Base camp meeting

VAR00033 Parallel hierarchy across location

VAR00034 Simplified Coordination

VAR00035 Formal communication tools

VAR00036 Minimum Internal Quality Criteria

VAR00037 Minimize global task transfers

VAR00038 Vendor Contract structuring for change

VAR00039 Vendor skill assessment

VAR00040 Vendor training requirement

VAR00041 Vendor Performance expectation alignment

VAR00042 Vendor Leadership

IT Management

VAR00043 PMO roadmap alignment

VAR00044 Requirement classification and roadmap check

VAR00045 Resource Limit

VAR00046 IT Investment change management

VAR00047 Contractual measurements

VAR00048 Parallel Dev, Test, PM hierarchy

VAR00049 Automated Regression

VAR00050 Recent data in test environment

VAR00051 Support team participation



Research Methodology

In order to reduce these factors by Exploratory Factor Analysis (EFA) method, a primary research

survey was conducted.

Questionnaire

Questions

A survey questionnaire was designed with one question corresponding to each of the 51 variables.

Audience was asked to rate importance of the factor as output. In addition, basic information on user

profile was collected including their agile exposure and role in organization. Also, the users were

asked optional subjective questions in the end to narrate particular experience. Some of the inputs

have been listed anonymously in later section of this chapter. All questions were positive in nature i.e.

importance of presence of factor will always be indicated by 7 for successful agile adoption.

Scale

All responses were gathered on Likert’s 7 point scale from “Not Important” to “Very Important”. All

questions had same response scale, so no standardization of responses was required.

Sampling Method

It was decided to conduct the survey as Expert survey. The method used was Snowball sampling

which is non-probability sampling method. Invitations were sent out to known practitioners of agile

methodologies. Individuals were also asked to forward invitations to people they know who have

experience in agile methods. We have received considerable number of responses from such

secondary level of contacts.

Based on responses received, individuals were found to be of different profiles like developers, test

engineers, business analysts, program managers, architects, resource managers and consultants.

These individuals have varying backgrounds from fields like product development, supply chain, cloud

computing, financial services and telecommunication services. These individuals belong to different

organizations like Microsoft, Accenture, Amazon, MindTree, Barclays, IBM, Netflix etc.

A total of 26 valid survey inputs were considered after eliminating incomplete responses.

Analysis Tool

Software used for analysis was IBM SPSS version 16.0 available with IIM Lucknow. The tool supports

out-of-box functionality for statistical analysis using Factor reduction method. This helps summarizing

large factors into more compact components. The tool also supports Varimax rotation.

Factor Analysis

Following are various details regards to Exploratory Factor Analysis method conducted.



Descriptives

We will use following descriptives to check validity of factor reduction analysis.

(1) Kaiser-Meyer-Olkin Measure (KMO) of sampling adequacy: This measures partial correlations

between variables. If > 0.5, it indicates that the given sample is sufficient for factor reduction.

Otherwise, it may indicate that the factor analysis is satisfactory. Due to limitation of time, we were

able to gather just sufficient responses. Hence, we will perform the factor analysis even if this

number is less than 0.5.

(2) Bartlett’s Test of Sphericity: The null hypothesis that factors are uncorrelated must be rejected

in order to proceed with the factor analysis. If significant is less than 0.05, it indicates there is

sufficient evidence to reject null hypothesis and the factors have strong correlation among

themselves, hence factor analysis can be conducted.

Extraction Method

The motive is to extract minimum number of factors that explain variation. Hence, we will use

Principle Component Method for extraction.

No. of factors to be extracted

There is no requirement to extract fixed number of factors. We will extract all those factors which have

Eigen Value higher than 1.0.

Rotation Method

Since we want to reduce number of variables with high loading on a factor, we use orthogonal

rotation. The particular method used here is Varimax rotation with Kaiser Normalization.

Interpretation Method

We will interpret loading of variables on factor using rotated component matrix. We will follow

general thumb rule of identifying loadings which are >=0.5. In some cases, where variable did not

load on any factor, we have taken factor loadings which are close to 0.5, due to inadequacy of sample

size.

Factor Analysis Results

The 5 sections – Software Design, Business Process, Human Resource Practices, Delivery Model and IT

Management are not factors but aspects of software development. Hence, factor analysis was

performed separately for each section. There is sufficient literature available to say that these five

aspects are independent. This would avoid any random pattern to emerge among variables from

different sections. This is also in line with survey design, where questions were classified among these

sections. Let’s look at EFA results one-by-one.

To download complete SPSS outputs for Exploratory Factor Analysis on variables in each 5

sections, log on to project homepage at: http://agile.vaibhavsathe.com



Software Design

SSPS Output

Descriptive Value Remark

KMO sampling adequacy 0.378 Sample may not be sufficient for factor analysis

Barlett’s Test of sphericity sig. 0.004 Null Hypothesis rejected, Factor Analysis possible

Rotated Component Matrixa

Component

Variables 1 2 3 4 5 6

Maintainability -.140 .086 .040 .119 .951 .124

Measurement of Output -.063 .003 .907 .180 -.034 .095

Reusability .608 .010 -.063 -.092 .719 -.116

Object Oriented Design principles .727 .301 .061 -.409 .019 .095

Knowledge of Design patterns .840 -.070 -.093 .151 -.049 .286

Automated Documentation .039 -.104 -.002 .927 .094 -.094

Unit Test suite as documentation .350 .121 -.318 .485 -.078 .370

Automated Unit Testing .093 -.035 .076 -.072 .076 .959

Refactoring .235 .868 -.030 -.053 .081 .102

Refactoring Commitment .000 .925 .053 -.032 .014 -.116

Architectural Strategy .722 .262 .173 .323 .044 -.144

Evolutionary Design .115 .038 .797 -.273 .041 -.040 Extraction Method: Principal Component Analysis. Rotation Method: Varimax with Kaiser Normalization. Rotation converged in 7 iterations.

Interpretation

The factors are interpreted as follows.

Factor Factor Interpretation Variance

Explained Loading Variables in Factor

F1 Object Orientation Mastery

19.57% 0.608 Reusability

0.727 Object Oriented Design principles

0.840 Knowledge of Design patterns

0.722 Architectural Strategy

F2 Refactoring 15.08% 0.868 Refactoring

0.925 Refactoring Commitment

F3 Non-conventional design 13.48% 0.907 Measurement of Output

0.797 Evolutionary Design

F4 Alternate documentation 12.73% 0.927 Automated Documentation

0.485 Unit Test suite as documentation

F5 Modular Code 12.14% 0.951 Maintainability

0.719 Reusability

F6 Unit Test Automation 10.33% 0.959 Automated Unit Testing



Business Process

SSPS Output


KMO sampling adequacy 0.572 Sample size sufficient for factor analysis



Component

Variables 1 2 3

Customer Availability .815 .115 .003

Customer Knowledge on Agile .378 .298 .724

Customer Communication .121 -.291 .689

Customer Transparency .696 -.060 .261

Self Sufficient Team .128 .795 -.171

Knowledge about client usage .735 .396 -.096

Business Alignment .083 .859 .123

Process Reengineering .466 -.028 -.648

Extraction Method: Principal Component Analysis. Rotation Method: Varimax with Kaiser Normalization. Rotation converged in 5 iterations.

Interpretation


Factor Factor Interpretation Variance Explained

Loading Variables in Factor

F7 Customer Involvement 31.51% 0.815 Customer Availability

0.696 Customer Transparency

0.735 Knowledge about client usage

F8 Reduced Dependencies 19.87% 0.795 Self Sufficient Team

0.859 Business Alignment

F9 Customer Knowledge 15.42% 0.724 Customer Knowledge on Agile

0.689 Customer Communication

-0.648 Process Reengineering


SSPS Output







Component

Variables 1 2 3 4 5

Wider competencies .125 -.051 .093 .925 -.037

Diverse Teams .036 .549 -.261 .400 .473

Mobile Workforce .065 .111 .881 .155 .056

Peer Reviews .497 .025 .715 -.325 .066

Team Performance over Individual -.008 -.066 .074 -.058 .875

Encourage Innovation .767 -.072 .357 .013 .250

Mentorship .732 .426 .040 -.321 -.030

Soft skills training .894 .065 .028 .309 -.081

Best practice sharing .349 -.136 .218 -.464 .458

Employee Perks .298 .843 -.025 -.033 .031

Flexible timing -.158 .821 .285 -.024 -.236


Interpretation




F10 Employee Development 28.63% 0.767 Encourage Innovation

0.732 Mentorship

0.894 Soft skills training

F11 Employee Morale 17.42% 0.549 Diverse Teams

0.843 Employee Perks

0.821 Flexible timing

F12 Workforce Dynamics 13.36% 0.881 Mobile Workforce

0.715 Peer Reviews

F13 Skillset diversity 11.42% 0.925 Wider competencies

-0.464 Best practice sharing

F14 Team Performance 9.82% 0.875 Team Performance over Individual

Delivery Model

SSPS Output







Component

Variables 1 2 3 4

Base camp meeting .201 .044 .086 .844

Parallel hierarchy across location .139 .837 -.129 .096

Simplified Coordination -.284 -.006 -.416 .551

Formal communication tools .175 -.615 -.500 .138

Minimum Internal Quality Criteria .174 -.137 .855 .062

Minimize global task transfers .580 .162 -.096 -.081

Vendor Contract structuring for change .849 .100 -.010 .213

Vendor skill assessment -.077 .203 .591 .640

Vendor training requirement .312 .776 -.020 .107

Vendor Performance expectation alignment .828 .184 .211 -.059

Vendor Leadership .803 -.050 .150 .016

Extraction Method: Principal Component Analysis. Rotation Method: Varimax with Kaiser Normalization Rotation converged in 7 iterations.

Interpretation


Factor Factor Interpretation Variance Explained

Loading Variables in Factor

F15 Contractual Expectations 28.13% 0.580 Minimize global task transfers

0.849 Vendor Contract structuring for change

0.828 Vendor Performance expectation alignment

0.803 Vendor Leadership

F16 Equivalency of teams 15.68% 0.837 Parallel hierarchy across location

-0.615 Formal communication tools

0.776 Vendor training requirement

F17 Teamwork Evaluation 13.51% 0.855 Minimum Internal Quality Criteria

0.591 Vendor skill assessment

F18 Communication Protocol 12.12% 0.844 Base camp meeting

0.551 Simplified Coordination

IT Management

SSPS Output


KMO sampling adequacy 0.503 Sample size sufficient for factor analysis





Component

Variables 1 2 3 4

PMO roadmap alignment -.135 -.558 .664 -.042

Requirement classification and roadmap check -.226 .796 .106 .062

Resource Limit -.379 .334 .508 .521

IT Investment change management .108 -.108 .818 .274

Contractual measurements .172 .842 -.160 -.340

Parallel Dev, Test, PM hierarchy .194 -.139 .034 .843

Automated Regression .150 -.256 -.593 .380

Recent data in test environment .904 -.137 -.039 .046

Support team participation .883 .091 -.037 .123


Interpretation




F19 Application Support 25.04% 0.904 Recent data in test environment

0.883 Support team participation

F20 Delivery Planning 24.51% 0.796 Requirement classification and roadmap check

0.842 Contractual measurements

F21 IT Planning 15.54% 0.664 PMO roadmap alignment

0.508 Resource Limit

0.818 IT Investment change management

-0.593 Automated Regression

F22 Resource Management 11.61% 0.521 Resource Limit

0.843 Parallel Dev, Test, PM hierarchy

Conclusion

Based on the literarature survey and primary research conducted, we can conclude that we were able

to arrive at model for important factors that determine software agile adoption. The summerized

factors can be broken into original variables using interpretation section of this document.

The model framework can be summarized as follows. The factors are in decreasing order of

importance in each category. The categories are independent of each other.



Limitations and further scope

The main limitation is sample size. We focussed more on literature review than the primary expert

survey. The survey can be extended to systematically include PMs from various backgrounds and

working on diverse variety of projects. The survey also had poor participation of women.

In this framework, due to lack of sufficient responses, we could not classify factors based on type of

agile method adopted. With larger survey, the framework can further be extended for different agile

frameworks like Scrum, Kanban and Extreme Programming. For future reference, the SPSS outputs,

additional links and appendices are available on project homepage at

http://agile.vaibhavsathe.com for download.

Thank you.

•Object Oriented Mastery

•Refactoring

•Non-conventional design

•Alternate Documentation

•Modular Code

•Unit Test Automation

Software Design

•Customer Involvement

•Reduced Interdependencies

•Customer Knowledge

Business Process

•Employee Development

•Employee Morale

•Workforce Dynamics

•Skill Diversity

•Team Performance


•Contractual Expectations

•Equivalency of Teams

•Teamwork Evaluation

•Communication Protocol

Delivery Models

•Application Support

•Delivery Planning

•IT Planning

•Resource Management

IT Management

agile adoption framework

Technology

various agile methods

software development

agile evolution6

software development

teamdecode software

software design27

project report

microsoft india rd