SlideShare a Scribd company logo
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.

                                           Page 1
                            Agile Adoption Readiness Framework
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




                                              Page 2
                               Agile Adoption Readiness Framework
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.




                                                  Page 3
                                   Agile Adoption Readiness Framework
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 criticality 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 a bove. Also,
the variability explained by each factor was identified which indicates importance of factors in
adoption process.




                                                   Page 4
                                    Agile Adoption Readiness Framework
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




                                                  Page 5
                                   Agile Adoption Readiness Framework
Chapter 1: History of Agile Development




      Chapter 1:
      Agile Evolution

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
Figure 1 Pressman (1994) Waterfall Software Model          again and again, thereby gaining

                                     Page 6
                      Agile Adoption Readiness Framework
Chapter 1: History of Agile Development
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 take n 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.




                                                    Page 7
                                     Agile Adoption Readiness Framework
Chapter 1: History of Agile Development
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.




                                                   Page 8
                                    Agile Adoption Readiness Framework
Chapter 1: History of Agile Development
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


                                                              Page 9
                                               Agile Adoption Readiness Framework
Chapter 1: History of Agile Development
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 10 th 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.


                                                   Page 10
                                     Agile Adoption Readiness Framework
Chapter 1: History of Agile Development



                                                          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.




                                                  Page 11
                                    Agile Adoption Readiness Framework
Chapter 2: The Scrum




     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]




                                  Page 12
                    Agile Adoption Readiness Framework
Chapter 2: The Scrum

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       At end of sprint, work should be potentially shippable, ready in hand to
Increment               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]


                                                   Page 13
                                     Agile Adoption Readiness Framework
Chapter 2: The Scrum
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 s ufficient
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




                                                   Page 14
                                     Agile Adoption Readiness Framework
Chapter 2: The Scrum
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 Mi crosoft 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]



                                                   Page 15
                                     Agile Adoption Readiness Framework
Chapter 2: The Scrum

               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.




                                                 Page 16
                                   Agile Adoption Readiness Framework
Chapter 3: eXtreme Programming




      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.
Figure 3 XP WorkFlow [2]




                                     Page 17
                       Agile Adoption Readiness Framework
Chapter 3: eXtreme Programming
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 tha t 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.




                                                  Page 18
                                    Agile Adoption Readiness Framework
Chapter 3: eXtreme Programming
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.




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

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.



                                                    Page 19
                                      Agile Adoption Readiness Framework
Chapter 3: eXtreme Programming
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.




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


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 bre ak
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




                                                     Page 20
                                       Agile Adoption Readiness Framework
Chapter 3: eXtreme Programming
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.




                                                                                                                 [6]
Figure 6 User Story Card; Source: Leigh Stringer
                                                   [5]
                                                           Figure 7 Task Board; Source: Mountain Goat Software


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.




                                                       Page 21
                                         Agile Adoption Readiness Framework
Chapter 4: Lean Agile




      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.




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




                                      Page 22
                        Agile Adoption Readiness Framework
Chapter 4: Lean Agile
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


                                                   Page 23
                                     Agile Adoption Readiness Framework
Chapter 4: Lean Agile
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 a t 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.




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


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

                                                   Page 24
                                     Agile Adoption Readiness Framework
Chapter 4: Lean Agile
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              During this meeting, kanban system’s empty queues are replenished at
Meeting                    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              Contrary to scrum, there is no need to check on three questions as looking at
Meetings                   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.
                                            [2]
Figure 10 Source: David Anderson - Kanban


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.



                                                     Page 25
                                       Agile Adoption Readiness Framework
Chapter 4: Lean Agile
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.




                                              Page 26
                                Agile Adoption Readiness Framework
Chapter 5: Software Design




      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.




                                   Page 27
                     Agile Adoption Readiness Framework
Chapter 5: Software Design
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



                                                   Page 28
                                     Agile Adoption Readiness Framework
Chapter 5: Software Design
                                                     [8]
critical issue in agile adoptions. Stoecklin et al         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 whic h
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.




                                                   Page 29
                                     Agile Adoption Readiness Framework
Chapter 5: Software Design
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.




                                                    Page 30
                                      Agile Adoption Readiness Framework
Chapter 5: Software Design
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 delays 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.

                                                   Page 31
                                     Agile Adoption Readiness Framework
Chapter 5: Software Design
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 2 nd
    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.




                                                  Page 32
                                    Agile Adoption Readiness Framework
Chapter 6: Business Processes




      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.




                                   Page 33
                     Agile Adoption Readiness Framework
Chapter 6: Business Processes
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
                                                                                 [1]
Various issues that impact agile process during interaction with customer are          :

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.




                                                   Page 34
                                     Agile Adoption Readiness Framework
Chapter 6: Business Processes
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 li mited 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                        Business Processes, Information Technology
                     Processes                        Organization, Information and Applications.
                                                      Business Processes refer to workflows in
                                                      business operations of the firm, they define
                                                      how firm operates and delivers products or
            IT                    Information         services to customer and receives revenue.
                                                      Information      Technology        refers    to
                                                      organizations that are catering to automate
                                                      these processes. Gartner says more than 85%
                    Applications                      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 o rganizations 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

                                                  Page 35
                                    Agile Adoption Readiness Framework
Chapter 6: Business Processes
businesses with same firm. However, if corresponding IT units operate in silos, customer will nee d 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 appro ach 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.

                                                  Page 36
                                    Agile Adoption Readiness Framework
Chapter 6: Business Processes




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


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.

                                                     Page 37
                                       Agile Adoption Readiness Framework
Chapter 6: Business Processes
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.




                                                  Page 38
                                    Agile Adoption Readiness Framework
Chapter 7: HR Practices




      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.




                                   Page 39
                     Agile Adoption Readiness Framework
Chapter 7: HR Practices




                                                        [2]
                          Figure 12 Crocitto, Youssef         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.




                                                     Page 40
                                       Agile Adoption Readiness Framework
Chapter 7: HR Practices
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                   Agile Team Managers’ Competencies

1.    Required Technical Skills                        12.   Innovation Management
2.    Required Business Knowledge                      13.   Fostering Diversity*
3.    Customer Focus*                                  14.   Understanding Company Culture*
4.    Dealing with Ambiguity                           15.   Develop and Grow People
5.    Problem Solving
6.    Creativity                                       Agile   Team           Members’         Individual
7.    Respecting Differences                           Competencies
8.    Positive Conflict
9.    Change Management                                16.   Communication Skills
10.   Decision Making                                  17.   Interpersonal Skills/Team Skills
11.   Collective Ownership                             18.   Integrity and Trustworthiness
                                                       19.   Accomplishment Orientation or passion
* also, Agile Leadership Qualities                     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].




                                                   Page 41
                                     Agile Adoption Readiness Framework
Chapter 7: HR Practices
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.




                                                  Page 42
                                    Agile Adoption Readiness Framework
Chapter 7: HR Practices
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 ultima tely 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 organizati ons.




                                                   Page 43
                                     Agile Adoption Readiness Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework
Agile Adoption Framework

More Related Content

What's hot

5352 Week 4 Assignment
5352 Week 4 Assignment5352 Week 4 Assignment
5352 Week 4 Assignment
ckscott
 
Edld 5352 Week 4 Assignment
Edld 5352 Week 4 AssignmentEdld 5352 Week 4 Assignment
Edld 5352 Week 4 Assignment
leighking
 
Technology Action Plan
Technology Action PlanTechnology Action Plan
Technology Action Plan
Wendy Ensley
 
Edld 5352 Week 4 Assignment
Edld 5352 Week 4 AssignmentEdld 5352 Week 4 Assignment
Edld 5352 Week 4 Assignment
tinyteacher2006
 
Action Plan Assignment
Action Plan AssignmentAction Plan Assignment
Action Plan Assignment
sderuso
 
Edld 5352 Week 4 Assignment
Edld 5352 Week 4 AssignmentEdld 5352 Week 4 Assignment
Edld 5352 Week 4 Assignment
Lamar
 
4-1 Flow Chart & Action Plan
4-1 Flow Chart & Action Plan4-1 Flow Chart & Action Plan
4-1 Flow Chart & Action Plan
Dodie M
 
EDLD 5352 Week 4 Assignment
EDLD 5352 Week 4 AssignmentEDLD 5352 Week 4 Assignment
EDLD 5352 Week 4 Assignment
lvalenz
 
Dsdm
DsdmDsdm
Technology Organizational Chart and Action Plan
Technology Organizational Chart and Action PlanTechnology Organizational Chart and Action Plan
Technology Organizational Chart and Action Plan
deanhofer
 
Instructional Leadership week 4 assignment
Instructional Leadership week 4 assignmentInstructional Leadership week 4 assignment
Instructional Leadership week 4 assignment
Linda DiVall
 
An Agile Software Development Framework
An Agile Software Development FrameworkAn Agile Software Development Framework
An Agile Software Development Framework
Waqas Tariq
 
Mapping of traditional software development methods to agile methodology
Mapping of traditional software development methods to agile methodologyMapping of traditional software development methods to agile methodology
Mapping of traditional software development methods to agile methodology
csandit
 
MAPPING OF TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO AGILE METHODOLOGY
MAPPING OF TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO AGILE METHODOLOGYMAPPING OF TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO AGILE METHODOLOGY
MAPPING OF TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO AGILE METHODOLOGY
cscpconf
 
EDLD 5352 Week 4 Assignment
EDLD 5352 Week 4 AssignmentEDLD 5352 Week 4 Assignment
EDLD 5352 Week 4 Assignment
edumiddle
 
Action Plan
Action PlanAction Plan
Action Plan
KrisAShipp
 

What's hot (16)

5352 Week 4 Assignment
5352 Week 4 Assignment5352 Week 4 Assignment
5352 Week 4 Assignment
 
Edld 5352 Week 4 Assignment
Edld 5352 Week 4 AssignmentEdld 5352 Week 4 Assignment
Edld 5352 Week 4 Assignment
 
Technology Action Plan
Technology Action PlanTechnology Action Plan
Technology Action Plan
 
Edld 5352 Week 4 Assignment
Edld 5352 Week 4 AssignmentEdld 5352 Week 4 Assignment
Edld 5352 Week 4 Assignment
 
Action Plan Assignment
Action Plan AssignmentAction Plan Assignment
Action Plan Assignment
 
Edld 5352 Week 4 Assignment
Edld 5352 Week 4 AssignmentEdld 5352 Week 4 Assignment
Edld 5352 Week 4 Assignment
 
4-1 Flow Chart & Action Plan
4-1 Flow Chart & Action Plan4-1 Flow Chart & Action Plan
4-1 Flow Chart & Action Plan
 
EDLD 5352 Week 4 Assignment
EDLD 5352 Week 4 AssignmentEDLD 5352 Week 4 Assignment
EDLD 5352 Week 4 Assignment
 
Dsdm
DsdmDsdm
Dsdm
 
Technology Organizational Chart and Action Plan
Technology Organizational Chart and Action PlanTechnology Organizational Chart and Action Plan
Technology Organizational Chart and Action Plan
 
Instructional Leadership week 4 assignment
Instructional Leadership week 4 assignmentInstructional Leadership week 4 assignment
Instructional Leadership week 4 assignment
 
An Agile Software Development Framework
An Agile Software Development FrameworkAn Agile Software Development Framework
An Agile Software Development Framework
 
Mapping of traditional software development methods to agile methodology
Mapping of traditional software development methods to agile methodologyMapping of traditional software development methods to agile methodology
Mapping of traditional software development methods to agile methodology
 
MAPPING OF TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO AGILE METHODOLOGY
MAPPING OF TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO AGILE METHODOLOGYMAPPING OF TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO AGILE METHODOLOGY
MAPPING OF TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO AGILE METHODOLOGY
 
EDLD 5352 Week 4 Assignment
EDLD 5352 Week 4 AssignmentEDLD 5352 Week 4 Assignment
EDLD 5352 Week 4 Assignment
 
Action Plan
Action PlanAction Plan
Action Plan
 

Viewers also liked

Agile adoption patterns and antipatterns
Agile adoption patterns and antipatternsAgile adoption patterns and antipatterns
Agile adoption patterns and antipatterns
Greg Hutchings
 
Enterprise Agile Adoption
Enterprise Agile AdoptionEnterprise Agile Adoption
Enterprise Agile Adoption
Saurav Mukherjee
 
9 steps to agile adoption – a proposal
9 steps to agile adoption – a proposal9 steps to agile adoption – a proposal
9 steps to agile adoption – a proposal
Naveen Indusekhar
 
18 al 24 de enero
18 al 24 de enero18 al 24 de enero
18 al 24 de enero
San José Ares
 
filosofias de la calidad
filosofias de la calidadfilosofias de la calidad
filosofias de la calidad
Roberto' Mtz Torre
 
Data warehousing features in oracle
Data warehousing features in oracleData warehousing features in oracle
Data warehousing features in oracle
Jinal Shah
 
final resume
final resumefinal resume
final resume
Tejas Pawar
 
Fb alopecia in a bulldog
Fb alopecia in a bulldogFb alopecia in a bulldog
งานโลหะแผ่น5 3
งานโลหะแผ่น5 3งานโลหะแผ่น5 3
งานโลหะแผ่น5 3Pannathat Champakul
 
Aprendiendo java
Aprendiendo javaAprendiendo java
Aprendiendo java
Orlando Escudero
 
06 regression
06 regression06 regression
06 regression
Mohammad Tawfik
 
Practica normalizacion
Practica normalizacionPractica normalizacion
Practica normalizacion
info162
 
Paginas ampliadas
Paginas ampliadasPaginas ampliadas
Paginas ampliadas
Gabriel Steindorff
 
Evaluation
EvaluationEvaluation
Evaluation
Huntwah
 
Mercados laborales trabajo de grado - 25.04.16
Mercados laborales   trabajo de grado -  25.04.16Mercados laborales   trabajo de grado -  25.04.16
Mercados laborales trabajo de grado - 25.04.16
Innovacion Gerencial
 
Utilizing Social Media to Promote Your Speaking Engagements (ILTA Speakers We...
Utilizing Social Media to Promote Your Speaking Engagements (ILTA Speakers We...Utilizing Social Media to Promote Your Speaking Engagements (ILTA Speakers We...
Utilizing Social Media to Promote Your Speaking Engagements (ILTA Speakers We...
InsideLegal
 
Prematuridad y bajo peso al nacer
Prematuridad y bajo peso al nacerPrematuridad y bajo peso al nacer
Prematuridad y bajo peso al nacer
Antonio Fernandez
 
2007 urok greek cafee
2007 urok greek cafee2007 urok greek cafee
2007 urok greek cafee
Szymon Konkol - Publikacje Cyfrowe
 
Articulo del 42 al 52
Articulo del 42 al 52Articulo del 42 al 52
Articulo del 42 al 52
PAulo Borikua
 

Viewers also liked (20)

Agile adoption patterns and antipatterns
Agile adoption patterns and antipatternsAgile adoption patterns and antipatterns
Agile adoption patterns and antipatterns
 
Enterprise Agile Adoption
Enterprise Agile AdoptionEnterprise Agile Adoption
Enterprise Agile Adoption
 
9 steps to agile adoption – a proposal
9 steps to agile adoption – a proposal9 steps to agile adoption – a proposal
9 steps to agile adoption – a proposal
 
18 al 24 de enero
18 al 24 de enero18 al 24 de enero
18 al 24 de enero
 
filosofias de la calidad
filosofias de la calidadfilosofias de la calidad
filosofias de la calidad
 
Data warehousing features in oracle
Data warehousing features in oracleData warehousing features in oracle
Data warehousing features in oracle
 
final resume
final resumefinal resume
final resume
 
Fb alopecia in a bulldog
Fb alopecia in a bulldogFb alopecia in a bulldog
Fb alopecia in a bulldog
 
งานโลหะแผ่น5 3
งานโลหะแผ่น5 3งานโลหะแผ่น5 3
งานโลหะแผ่น5 3
 
Aprendiendo java
Aprendiendo javaAprendiendo java
Aprendiendo java
 
06 regression
06 regression06 regression
06 regression
 
easy Vocabulary
easy Vocabulary easy Vocabulary
easy Vocabulary
 
Practica normalizacion
Practica normalizacionPractica normalizacion
Practica normalizacion
 
Paginas ampliadas
Paginas ampliadasPaginas ampliadas
Paginas ampliadas
 
Evaluation
EvaluationEvaluation
Evaluation
 
Mercados laborales trabajo de grado - 25.04.16
Mercados laborales   trabajo de grado -  25.04.16Mercados laborales   trabajo de grado -  25.04.16
Mercados laborales trabajo de grado - 25.04.16
 
Utilizing Social Media to Promote Your Speaking Engagements (ILTA Speakers We...
Utilizing Social Media to Promote Your Speaking Engagements (ILTA Speakers We...Utilizing Social Media to Promote Your Speaking Engagements (ILTA Speakers We...
Utilizing Social Media to Promote Your Speaking Engagements (ILTA Speakers We...
 
Prematuridad y bajo peso al nacer
Prematuridad y bajo peso al nacerPrematuridad y bajo peso al nacer
Prematuridad y bajo peso al nacer
 
2007 urok greek cafee
2007 urok greek cafee2007 urok greek cafee
2007 urok greek cafee
 
Articulo del 42 al 52
Articulo del 42 al 52Articulo del 42 al 52
Articulo del 42 al 52
 

Similar to Agile Adoption Framework

Agile Project Management Methods of IT Projects
Agile Project Management Methods of IT ProjectsAgile Project Management Methods of IT Projects
Agile Project Management Methods of IT Projects
Glen Alleman
 
Agile Metrics article
Agile Metrics articleAgile Metrics article
Agile Metrics article
dheimann5
 
A Comparative Analysis Of Various Methodologies Of Agile Project Management V...
A Comparative Analysis Of Various Methodologies Of Agile Project Management V...A Comparative Analysis Of Various Methodologies Of Agile Project Management V...
A Comparative Analysis Of Various Methodologies Of Agile Project Management V...
Brittany Allen
 
Epf composer overviewpart1
Epf composer overviewpart1Epf composer overviewpart1
Epf composer overviewpart1
Abdelkader Larbi
 
ETPM5
ETPM5ETPM5
ETPM5
PMI2011
 
A Systematic Study On Agile Software Development Methodlogies And Practices
A Systematic Study On Agile Software Development Methodlogies And PracticesA Systematic Study On Agile Software Development Methodlogies And Practices
A Systematic Study On Agile Software Development Methodlogies And Practices
Sean Flores
 
Project Requriement Management Vs Agile software development
Project Requriement Management Vs  Agile software developmentProject Requriement Management Vs  Agile software development
Project Requriement Management Vs Agile software development
bizpresenter
 
Technology Integration Pattern For Distributed Scrum of Scrum
Technology Integration Pattern For Distributed Scrum of ScrumTechnology Integration Pattern For Distributed Scrum of Scrum
Technology Integration Pattern For Distributed Scrum of Scrum
IOSR Journals
 
DEVOPS ADOPTION IN INFORMATION SYSTEMS PROJECTS; A SYSTEMATIC LITERATURE REVIEW
DEVOPS ADOPTION IN INFORMATION SYSTEMS PROJECTS; A SYSTEMATIC LITERATURE REVIEWDEVOPS ADOPTION IN INFORMATION SYSTEMS PROJECTS; A SYSTEMATIC LITERATURE REVIEW
DEVOPS ADOPTION IN INFORMATION SYSTEMS PROJECTS; A SYSTEMATIC LITERATURE REVIEW
ijseajournal
 
10.1.1.87.8236
10.1.1.87.823610.1.1.87.8236
10.1.1.87.8236
Md Chowdhury
 
Can “Feature” be used to Model the Changing Access Control Policies?
Can “Feature” be used to Model the Changing Access Control Policies? Can “Feature” be used to Model the Changing Access Control Policies?
Can “Feature” be used to Model the Changing Access Control Policies?
IJORCS
 
Agile development
Agile developmentAgile development
Agile development
Buddhika Rathnayaka
 
The_Role_of_the_Product_Owner_in_Scrum-comparison_.pdf
The_Role_of_the_Product_Owner_in_Scrum-comparison_.pdfThe_Role_of_the_Product_Owner_in_Scrum-comparison_.pdf
The_Role_of_the_Product_Owner_in_Scrum-comparison_.pdf
RafaelSalamanca11
 
A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...
A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...
A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...
ijseajournal
 
A novel risk management model in the Scrum and extreme programming hybrid me...
A novel risk management model in the Scrum and extreme  programming hybrid me...A novel risk management model in the Scrum and extreme  programming hybrid me...
A novel risk management model in the Scrum and extreme programming hybrid me...
IJECEIAES
 
Perspectives on the adherance to scrum rules in software project management
Perspectives on the adherance to scrum rules in software project managementPerspectives on the adherance to scrum rules in software project management
Perspectives on the adherance to scrum rules in software project management
nooriasukmaningtyas
 
Evolvea Frameworkfor SelectingPrime Software DevelopmentProcess
Evolvea Frameworkfor SelectingPrime Software DevelopmentProcessEvolvea Frameworkfor SelectingPrime Software DevelopmentProcess
Evolvea Frameworkfor SelectingPrime Software DevelopmentProcess
IJMER
 
A case study of using the hybrid model of scrum and six sigma in software dev...
A case study of using the hybrid model of scrum and six sigma in software dev...A case study of using the hybrid model of scrum and six sigma in software dev...
A case study of using the hybrid model of scrum and six sigma in software dev...
IJECEIAES
 
Lightweight Processes: A Definition
Lightweight Processes: A DefinitionLightweight Processes: A Definition
Lightweight Processes: A Definition
Glen Alleman
 
A sustainable procedural method of software design process improvements
A sustainable procedural method of software design process improvementsA sustainable procedural method of software design process improvements
A sustainable procedural method of software design process improvements
nooriasukmaningtyas
 

Similar to Agile Adoption Framework (20)

Agile Project Management Methods of IT Projects
Agile Project Management Methods of IT ProjectsAgile Project Management Methods of IT Projects
Agile Project Management Methods of IT Projects
 
Agile Metrics article
Agile Metrics articleAgile Metrics article
Agile Metrics article
 
A Comparative Analysis Of Various Methodologies Of Agile Project Management V...
A Comparative Analysis Of Various Methodologies Of Agile Project Management V...A Comparative Analysis Of Various Methodologies Of Agile Project Management V...
A Comparative Analysis Of Various Methodologies Of Agile Project Management V...
 
Epf composer overviewpart1
Epf composer overviewpart1Epf composer overviewpart1
Epf composer overviewpart1
 
ETPM5
ETPM5ETPM5
ETPM5
 
A Systematic Study On Agile Software Development Methodlogies And Practices
A Systematic Study On Agile Software Development Methodlogies And PracticesA Systematic Study On Agile Software Development Methodlogies And Practices
A Systematic Study On Agile Software Development Methodlogies And Practices
 
Project Requriement Management Vs Agile software development
Project Requriement Management Vs  Agile software developmentProject Requriement Management Vs  Agile software development
Project Requriement Management Vs Agile software development
 
Technology Integration Pattern For Distributed Scrum of Scrum
Technology Integration Pattern For Distributed Scrum of ScrumTechnology Integration Pattern For Distributed Scrum of Scrum
Technology Integration Pattern For Distributed Scrum of Scrum
 
DEVOPS ADOPTION IN INFORMATION SYSTEMS PROJECTS; A SYSTEMATIC LITERATURE REVIEW
DEVOPS ADOPTION IN INFORMATION SYSTEMS PROJECTS; A SYSTEMATIC LITERATURE REVIEWDEVOPS ADOPTION IN INFORMATION SYSTEMS PROJECTS; A SYSTEMATIC LITERATURE REVIEW
DEVOPS ADOPTION IN INFORMATION SYSTEMS PROJECTS; A SYSTEMATIC LITERATURE REVIEW
 
10.1.1.87.8236
10.1.1.87.823610.1.1.87.8236
10.1.1.87.8236
 
Can “Feature” be used to Model the Changing Access Control Policies?
Can “Feature” be used to Model the Changing Access Control Policies? Can “Feature” be used to Model the Changing Access Control Policies?
Can “Feature” be used to Model the Changing Access Control Policies?
 
Agile development
Agile developmentAgile development
Agile development
 
The_Role_of_the_Product_Owner_in_Scrum-comparison_.pdf
The_Role_of_the_Product_Owner_in_Scrum-comparison_.pdfThe_Role_of_the_Product_Owner_in_Scrum-comparison_.pdf
The_Role_of_the_Product_Owner_in_Scrum-comparison_.pdf
 
A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...
A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...
A MAPPING MODEL FOR TRANSFORMING TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO ...
 
A novel risk management model in the Scrum and extreme programming hybrid me...
A novel risk management model in the Scrum and extreme  programming hybrid me...A novel risk management model in the Scrum and extreme  programming hybrid me...
A novel risk management model in the Scrum and extreme programming hybrid me...
 
Perspectives on the adherance to scrum rules in software project management
Perspectives on the adherance to scrum rules in software project managementPerspectives on the adherance to scrum rules in software project management
Perspectives on the adherance to scrum rules in software project management
 
Evolvea Frameworkfor SelectingPrime Software DevelopmentProcess
Evolvea Frameworkfor SelectingPrime Software DevelopmentProcessEvolvea Frameworkfor SelectingPrime Software DevelopmentProcess
Evolvea Frameworkfor SelectingPrime Software DevelopmentProcess
 
A case study of using the hybrid model of scrum and six sigma in software dev...
A case study of using the hybrid model of scrum and six sigma in software dev...A case study of using the hybrid model of scrum and six sigma in software dev...
A case study of using the hybrid model of scrum and six sigma in software dev...
 
Lightweight Processes: A Definition
Lightweight Processes: A DefinitionLightweight Processes: A Definition
Lightweight Processes: A Definition
 
A sustainable procedural method of software design process improvements
A sustainable procedural method of software design process improvementsA sustainable procedural method of software design process improvements
A sustainable procedural method of software design process improvements
 

More from Vaibhav Sathe

Ip issues in global software outsourcing
Ip issues in global software outsourcingIp issues in global software outsourcing
Ip issues in global software outsourcing
Vaibhav Sathe
 
Near Field Communication
Near Field CommunicationNear Field Communication
Near Field Communication
Vaibhav Sathe
 
Sharepoint proposal as Collaborative system
Sharepoint proposal as Collaborative systemSharepoint proposal as Collaborative system
Sharepoint proposal as Collaborative system
Vaibhav Sathe
 
Aaruba vs Cape Verde Business Environment Comparison
Aaruba vs Cape Verde Business Environment ComparisonAaruba vs Cape Verde Business Environment Comparison
Aaruba vs Cape Verde Business Environment Comparison
Vaibhav Sathe
 
Cross Culture Course Proposal at IIML
Cross Culture Course Proposal at IIMLCross Culture Course Proposal at IIML
Cross Culture Course Proposal at IIML
Vaibhav Sathe
 
Kodak vs Fuji Case
Kodak vs Fuji CaseKodak vs Fuji Case
Kodak vs Fuji Case
Vaibhav Sathe
 
Investment Patterns in India
Investment Patterns in IndiaInvestment Patterns in India
Investment Patterns in India
Vaibhav Sathe
 
Emerging World Trade Regime
Emerging World Trade RegimeEmerging World Trade Regime
Emerging World Trade Regime
Vaibhav Sathe
 
Literature survey on identity management
Literature survey on identity managementLiterature survey on identity management
Literature survey on identity management
Vaibhav Sathe
 
Network Structure For Social Network
Network Structure For Social NetworkNetwork Structure For Social Network
Network Structure For Social Network
Vaibhav Sathe
 
Idea Cellular IIM Lucknow Strategy
Idea Cellular IIM Lucknow StrategyIdea Cellular IIM Lucknow Strategy
Idea Cellular IIM Lucknow Strategy
Vaibhav Sathe
 
Leadership’s Online Labs
Leadership’s Online LabsLeadership’s Online Labs
Leadership’s Online Labs
Vaibhav Sathe
 
ECJ west tankers case
ECJ west tankers caseECJ west tankers case
ECJ west tankers case
Vaibhav Sathe
 

More from Vaibhav Sathe (13)

Ip issues in global software outsourcing
Ip issues in global software outsourcingIp issues in global software outsourcing
Ip issues in global software outsourcing
 
Near Field Communication
Near Field CommunicationNear Field Communication
Near Field Communication
 
Sharepoint proposal as Collaborative system
Sharepoint proposal as Collaborative systemSharepoint proposal as Collaborative system
Sharepoint proposal as Collaborative system
 
Aaruba vs Cape Verde Business Environment Comparison
Aaruba vs Cape Verde Business Environment ComparisonAaruba vs Cape Verde Business Environment Comparison
Aaruba vs Cape Verde Business Environment Comparison
 
Cross Culture Course Proposal at IIML
Cross Culture Course Proposal at IIMLCross Culture Course Proposal at IIML
Cross Culture Course Proposal at IIML
 
Kodak vs Fuji Case
Kodak vs Fuji CaseKodak vs Fuji Case
Kodak vs Fuji Case
 
Investment Patterns in India
Investment Patterns in IndiaInvestment Patterns in India
Investment Patterns in India
 
Emerging World Trade Regime
Emerging World Trade RegimeEmerging World Trade Regime
Emerging World Trade Regime
 
Literature survey on identity management
Literature survey on identity managementLiterature survey on identity management
Literature survey on identity management
 
Network Structure For Social Network
Network Structure For Social NetworkNetwork Structure For Social Network
Network Structure For Social Network
 
Idea Cellular IIM Lucknow Strategy
Idea Cellular IIM Lucknow StrategyIdea Cellular IIM Lucknow Strategy
Idea Cellular IIM Lucknow Strategy
 
Leadership’s Online Labs
Leadership’s Online LabsLeadership’s Online Labs
Leadership’s Online Labs
 
ECJ west tankers case
ECJ west tankers caseECJ west tankers case
ECJ west tankers case
 

Recently uploaded

Artificial Intelligence for XMLDevelopment
Artificial Intelligence for XMLDevelopmentArtificial Intelligence for XMLDevelopment
Artificial Intelligence for XMLDevelopment
Octavian Nadolu
 
Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!
Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!
Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!
SOFTTECHHUB
 
UiPath Test Automation using UiPath Test Suite series, part 6
UiPath Test Automation using UiPath Test Suite series, part 6UiPath Test Automation using UiPath Test Suite series, part 6
UiPath Test Automation using UiPath Test Suite series, part 6
DianaGray10
 
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
James Anderson
 
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Albert Hoitingh
 
PCI PIN Basics Webinar from the Controlcase Team
PCI PIN Basics Webinar from the Controlcase TeamPCI PIN Basics Webinar from the Controlcase Team
PCI PIN Basics Webinar from the Controlcase Team
ControlCase
 
Monitoring Java Application Security with JDK Tools and JFR Events
Monitoring Java Application Security with JDK Tools and JFR EventsMonitoring Java Application Security with JDK Tools and JFR Events
Monitoring Java Application Security with JDK Tools and JFR Events
Ana-Maria Mihalceanu
 
By Design, not by Accident - Agile Venture Bolzano 2024
By Design, not by Accident - Agile Venture Bolzano 2024By Design, not by Accident - Agile Venture Bolzano 2024
By Design, not by Accident - Agile Venture Bolzano 2024
Pierluigi Pugliese
 
Uni Systems Copilot event_05062024_C.Vlachos.pdf
Uni Systems Copilot event_05062024_C.Vlachos.pdfUni Systems Copilot event_05062024_C.Vlachos.pdf
Uni Systems Copilot event_05062024_C.Vlachos.pdf
Uni Systems S.M.S.A.
 
GraphSummit Singapore | Graphing Success: Revolutionising Organisational Stru...
GraphSummit Singapore | Graphing Success: Revolutionising Organisational Stru...GraphSummit Singapore | Graphing Success: Revolutionising Organisational Stru...
GraphSummit Singapore | Graphing Success: Revolutionising Organisational Stru...
Neo4j
 
みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...
みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...
みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...
名前 です男
 
Elizabeth Buie - Older adults: Are we really designing for our future selves?
Elizabeth Buie - Older adults: Are we really designing for our future selves?Elizabeth Buie - Older adults: Are we really designing for our future selves?
Elizabeth Buie - Older adults: Are we really designing for our future selves?
Nexer Digital
 
Securing your Kubernetes cluster_ a step-by-step guide to success !
Securing your Kubernetes cluster_ a step-by-step guide to success !Securing your Kubernetes cluster_ a step-by-step guide to success !
Securing your Kubernetes cluster_ a step-by-step guide to success !
KatiaHIMEUR1
 
How to Get CNIC Information System with Paksim Ga.pptx
How to Get CNIC Information System with Paksim Ga.pptxHow to Get CNIC Information System with Paksim Ga.pptx
How to Get CNIC Information System with Paksim Ga.pptx
danishmna97
 
RESUME BUILDER APPLICATION Project for students
RESUME BUILDER APPLICATION Project for studentsRESUME BUILDER APPLICATION Project for students
RESUME BUILDER APPLICATION Project for students
KAMESHS29
 
Video Streaming: Then, Now, and in the Future
Video Streaming: Then, Now, and in the FutureVideo Streaming: Then, Now, and in the Future
Video Streaming: Then, Now, and in the Future
Alpen-Adria-Universität
 
Large Language Model (LLM) and it’s Geospatial Applications
Large Language Model (LLM) and it’s Geospatial ApplicationsLarge Language Model (LLM) and it’s Geospatial Applications
Large Language Model (LLM) and it’s Geospatial Applications
Rohit Gautam
 
UiPath Test Automation using UiPath Test Suite series, part 5
UiPath Test Automation using UiPath Test Suite series, part 5UiPath Test Automation using UiPath Test Suite series, part 5
UiPath Test Automation using UiPath Test Suite series, part 5
DianaGray10
 
“I’m still / I’m still / Chaining from the Block”
“I’m still / I’m still / Chaining from the Block”“I’m still / I’m still / Chaining from the Block”
“I’m still / I’m still / Chaining from the Block”
Claudio Di Ciccio
 
GridMate - End to end testing is a critical piece to ensure quality and avoid...
GridMate - End to end testing is a critical piece to ensure quality and avoid...GridMate - End to end testing is a critical piece to ensure quality and avoid...
GridMate - End to end testing is a critical piece to ensure quality and avoid...
ThomasParaiso2
 

Recently uploaded (20)

Artificial Intelligence for XMLDevelopment
Artificial Intelligence for XMLDevelopmentArtificial Intelligence for XMLDevelopment
Artificial Intelligence for XMLDevelopment
 
Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!
Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!
Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!
 
UiPath Test Automation using UiPath Test Suite series, part 6
UiPath Test Automation using UiPath Test Suite series, part 6UiPath Test Automation using UiPath Test Suite series, part 6
UiPath Test Automation using UiPath Test Suite series, part 6
 
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
 
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
 
PCI PIN Basics Webinar from the Controlcase Team
PCI PIN Basics Webinar from the Controlcase TeamPCI PIN Basics Webinar from the Controlcase Team
PCI PIN Basics Webinar from the Controlcase Team
 
Monitoring Java Application Security with JDK Tools and JFR Events
Monitoring Java Application Security with JDK Tools and JFR EventsMonitoring Java Application Security with JDK Tools and JFR Events
Monitoring Java Application Security with JDK Tools and JFR Events
 
By Design, not by Accident - Agile Venture Bolzano 2024
By Design, not by Accident - Agile Venture Bolzano 2024By Design, not by Accident - Agile Venture Bolzano 2024
By Design, not by Accident - Agile Venture Bolzano 2024
 
Uni Systems Copilot event_05062024_C.Vlachos.pdf
Uni Systems Copilot event_05062024_C.Vlachos.pdfUni Systems Copilot event_05062024_C.Vlachos.pdf
Uni Systems Copilot event_05062024_C.Vlachos.pdf
 
GraphSummit Singapore | Graphing Success: Revolutionising Organisational Stru...
GraphSummit Singapore | Graphing Success: Revolutionising Organisational Stru...GraphSummit Singapore | Graphing Success: Revolutionising Organisational Stru...
GraphSummit Singapore | Graphing Success: Revolutionising Organisational Stru...
 
みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...
みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...
みなさんこんにちはこれ何文字まで入るの?40文字以下不可とか本当に意味わからないけどこれ限界文字数書いてないからマジでやばい文字数いけるんじゃないの?えこ...
 
Elizabeth Buie - Older adults: Are we really designing for our future selves?
Elizabeth Buie - Older adults: Are we really designing for our future selves?Elizabeth Buie - Older adults: Are we really designing for our future selves?
Elizabeth Buie - Older adults: Are we really designing for our future selves?
 
Securing your Kubernetes cluster_ a step-by-step guide to success !
Securing your Kubernetes cluster_ a step-by-step guide to success !Securing your Kubernetes cluster_ a step-by-step guide to success !
Securing your Kubernetes cluster_ a step-by-step guide to success !
 
How to Get CNIC Information System with Paksim Ga.pptx
How to Get CNIC Information System with Paksim Ga.pptxHow to Get CNIC Information System with Paksim Ga.pptx
How to Get CNIC Information System with Paksim Ga.pptx
 
RESUME BUILDER APPLICATION Project for students
RESUME BUILDER APPLICATION Project for studentsRESUME BUILDER APPLICATION Project for students
RESUME BUILDER APPLICATION Project for students
 
Video Streaming: Then, Now, and in the Future
Video Streaming: Then, Now, and in the FutureVideo Streaming: Then, Now, and in the Future
Video Streaming: Then, Now, and in the Future
 
Large Language Model (LLM) and it’s Geospatial Applications
Large Language Model (LLM) and it’s Geospatial ApplicationsLarge Language Model (LLM) and it’s Geospatial Applications
Large Language Model (LLM) and it’s Geospatial Applications
 
UiPath Test Automation using UiPath Test Suite series, part 5
UiPath Test Automation using UiPath Test Suite series, part 5UiPath Test Automation using UiPath Test Suite series, part 5
UiPath Test Automation using UiPath Test Suite series, part 5
 
“I’m still / I’m still / Chaining from the Block”
“I’m still / I’m still / Chaining from the Block”“I’m still / I’m still / Chaining from the Block”
“I’m still / I’m still / Chaining from the Block”
 
GridMate - End to end testing is a critical piece to ensure quality and avoid...
GridMate - End to end testing is a critical piece to ensure quality and avoid...GridMate - End to end testing is a critical piece to ensure quality and avoid...
GridMate - End to end testing is a critical piece to ensure quality and avoid...
 

Agile Adoption Framework

  • 1. 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. Page 1 Agile Adoption Readiness Framework
  • 2. 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 Page 2 Agile Adoption Readiness Framework
  • 3. 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. Page 3 Agile Adoption Readiness Framework
  • 4. 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 criticality 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 a bove. Also, the variability explained by each factor was identified which indicates importance of factors in adoption process. Page 4 Agile Adoption Readiness Framework
  • 5. 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 Page 5 Agile Adoption Readiness Framework
  • 6. Chapter 1: History of Agile Development Chapter 1: Agile Evolution 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 Figure 1 Pressman (1994) Waterfall Software Model again and again, thereby gaining Page 6 Agile Adoption Readiness Framework
  • 7. Chapter 1: History of Agile Development 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 take n 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. Page 7 Agile Adoption Readiness Framework
  • 8. Chapter 1: History of Agile Development 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. Page 8 Agile Adoption Readiness Framework
  • 9. Chapter 1: History of Agile Development 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 Page 9 Agile Adoption Readiness Framework
  • 10. Chapter 1: History of Agile Development 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 10 th 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. Page 10 Agile Adoption Readiness Framework
  • 11. Chapter 1: History of Agile Development 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. Page 11 Agile Adoption Readiness Framework
  • 12. Chapter 2: The Scrum 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] Page 12 Agile Adoption Readiness Framework
  • 13. Chapter 2: The Scrum 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 At end of sprint, work should be potentially shippable, ready in hand to Increment 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] Page 13 Agile Adoption Readiness Framework
  • 14. Chapter 2: The Scrum 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 s ufficient 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 Page 14 Agile Adoption Readiness Framework
  • 15. Chapter 2: The Scrum 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 Mi crosoft 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] Page 15 Agile Adoption Readiness Framework
  • 16. Chapter 2: The Scrum 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. Page 16 Agile Adoption Readiness Framework
  • 17. Chapter 3: eXtreme Programming 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. Figure 3 XP WorkFlow [2] Page 17 Agile Adoption Readiness Framework
  • 18. Chapter 3: eXtreme Programming 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 tha t 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. Page 18 Agile Adoption Readiness Framework
  • 19. Chapter 3: eXtreme Programming 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. [2] Figure 4 Extreme Programming Project; Source: extremeprogramming.org 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. Page 19 Agile Adoption Readiness Framework
  • 20. Chapter 3: eXtreme Programming 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. [2] Figure 5 An Iteration; Source: extremeprogramming.org 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 bre ak 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 Page 20 Agile Adoption Readiness Framework
  • 21. Chapter 3: eXtreme Programming 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. [6] Figure 6 User Story Card; Source: Leigh Stringer [5] Figure 7 Task Board; Source: Mountain Goat Software 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. Page 21 Agile Adoption Readiness Framework
  • 22. Chapter 4: Lean Agile 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. [1] Figure 8 Application of Agile methods on value chain, Source: Alan Shalloway - Lean/Agile Page 22 Agile Adoption Readiness Framework
  • 23. Chapter 4: Lean Agile 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 Page 23 Agile Adoption Readiness Framework
  • 24. Chapter 4: Lean Agile 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 a t 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. [6] Figure 9 Kanban card wall. Source: crisp. 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 Page 24 Agile Adoption Readiness Framework
  • 25. Chapter 4: Lean Agile 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 During this meeting, kanban system’s empty queues are replenished at Meeting 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 Contrary to scrum, there is no need to check on three questions as looking at Meetings 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. [2] Figure 10 Source: David Anderson - Kanban 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. Page 25 Agile Adoption Readiness Framework
  • 26. Chapter 4: Lean Agile 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. Page 26 Agile Adoption Readiness Framework
  • 27. Chapter 5: Software Design 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. Page 27 Agile Adoption Readiness Framework
  • 28. Chapter 5: Software Design 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 Page 28 Agile Adoption Readiness Framework
  • 29. Chapter 5: Software Design [8] critical issue in agile adoptions. Stoecklin et al 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 whic h 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. Page 29 Agile Adoption Readiness Framework
  • 30. Chapter 5: Software Design 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. Page 30 Agile Adoption Readiness Framework
  • 31. Chapter 5: Software Design 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 delays 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. Page 31 Agile Adoption Readiness Framework
  • 32. Chapter 5: Software Design 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 2 nd 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. Page 32 Agile Adoption Readiness Framework
  • 33. Chapter 6: Business Processes 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. Page 33 Agile Adoption Readiness Framework
  • 34. Chapter 6: Business Processes 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 [1] Various issues that impact agile process during interaction with customer are : 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. Page 34 Agile Adoption Readiness Framework
  • 35. Chapter 6: Business Processes 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 li mited 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 Business Processes, Information Technology Processes Organization, Information and Applications. Business Processes refer to workflows in business operations of the firm, they define how firm operates and delivers products or IT Information services to customer and receives revenue. Information Technology refers to organizations that are catering to automate these processes. Gartner says more than 85% Applications 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 o rganizations 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 Page 35 Agile Adoption Readiness Framework
  • 36. Chapter 6: Business Processes businesses with same firm. However, if corresponding IT units operate in silos, customer will nee d 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 appro ach 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. Page 36 Agile Adoption Readiness Framework
  • 37. Chapter 6: Business Processes [8] Figure 11 Chen's IT Alignment with SOA schematic 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. Page 37 Agile Adoption Readiness Framework
  • 38. Chapter 6: Business Processes 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. Page 38 Agile Adoption Readiness Framework
  • 39. Chapter 7: HR Practices 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. Page 39 Agile Adoption Readiness Framework
  • 40. Chapter 7: HR Practices [2] Figure 12 Crocitto, Youssef 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. Page 40 Agile Adoption Readiness Framework
  • 41. Chapter 7: HR Practices 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 Agile Team Managers’ Competencies 1. Required Technical Skills 12. Innovation Management 2. Required Business Knowledge 13. Fostering Diversity* 3. Customer Focus* 14. Understanding Company Culture* 4. Dealing with Ambiguity 15. Develop and Grow People 5. Problem Solving 6. Creativity Agile Team Members’ Individual 7. Respecting Differences Competencies 8. Positive Conflict 9. Change Management 16. Communication Skills 10. Decision Making 17. Interpersonal Skills/Team Skills 11. Collective Ownership 18. Integrity and Trustworthiness 19. Accomplishment Orientation or passion * also, Agile Leadership Qualities 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]. Page 41 Agile Adoption Readiness Framework
  • 42. Chapter 7: HR Practices 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. Page 42 Agile Adoption Readiness Framework
  • 43. Chapter 7: HR Practices 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 ultima tely 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 organizati ons. Page 43 Agile Adoption Readiness Framework