Beruflich Dokumente
Kultur Dokumente
Prabandh Nagar, Off Sitapur Road, Lucknow, Uttar Pradesh - 226013, INDIA.
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
APPROVED FOR SUBMISSION TO PGP OFFICE TOWARDS TERM VI REQUIREMENTS OF PGP COURSE Signature:
Dr. Bharat Bhasker Professor, Information Technology & Systems Area, IIM Lucknow Date: 22.02.2012
Acknowledgements
The author would like to thank Prof. Bharat Bhasker for the most valuable help and guidance he provided throughout the course of this project, without which it was impossible to achieve the completion. The author acknowledges Mr. M. U. Raja and the staff of IIM Lucknow Library, who promptly procured all the books required in this massive literature survey. Author also thanks library and administration of IIM Lucknow and ESCP Europe, Paris campus for the rich collection of journals and digital database subscriptions without which the project could not have been completed. Author thanks numerous authors of books, articles, papers, blogs and other publications whose references are cited in this project report. The author acknowledges contribution of following individuals in making this project successful. Aniket Mokashi, Sr. Software Engineer, Netflix, Inc. Ashish Bhangale, Software Development Engineer in Test, Microsoft Corporation Bhavik Vora, Sr. Software Engineer, Microsoft India R&D Pvt. Ltd. G. Nagraj, Director, TeamDecode Software Pvt. Ltd. Krunal Dedhia, Sr. Software Engineer, Accenture Naveen Babu Monthri, Sr. Program Manager, Microsoft India R&D Pvt. Ltd. Pranav Karkhanis, Software Development Lead, Microsoft India R&D Pvt. Ltd. R. Venkata Konda Reddy, Staff R&D Engineer, IBM India Rohit Ratnakar Mallya, Global System Engineering Lead, Microsoft Corporation Sandhya Rithe, Program Office Manager, Barclays Sanjay BK, PGDM Student, Indian Institute of Management Lucknow Sudheesh S, Associate Consultant, MindTree Ltd. Swati Patil, PGDM Student, Indian Institute of Management Lucknow Vikas Gupta, General Manager and Global Practice Head (Cloud Computing), MindTree Ltd. Vinayak Rakkasagi, PGDM Student, Indian Institute of Management Lucknow Vivekananda Parepalli, PGDM Student, S.P. Jain Institute of Management & Research Author also acknowledges the contribution of all survey participants including those who chose to remain anonymous, while helping this project.
Executive Summary
The objective of this study was to identify factors that affect adoption of agile methodologies in software organizations. The study also aimed at establishing relative importance of these factors. The executive summary provides brief introduction of structure of this report organized based on chapters dedicated to each topic as below. Chapter 1 This study included a detailed literature survey in which we have taken overview of evolution of various software engineering methods. Later on we have discussed how the principles of agile manifesto formed foundation to various agile methods like Scrum, Kanban and Extreme Programming. Chapter 2, 3 and 4 Then we have discussed in brief the three agile methods mentioned above with detailed explanation of terminologies, meetings, tracking methods, delivery cycles and various tools that are used. We have analyzed these methods from perspectives of customer and developers. Chapter 5 - 9 In later section, literature survey was carried out to identify list of possible variables that impact adoption of agile methods. Various case studies, published papers, interviews and websites of consultants were reviewed. A list of 51 such variables was finalized organized in 5 sections which are different organizational aspects of software development Software Design, Business Process, HR Practices, Delivery Model and IT Management. Chapter 10 Primary survey was conducted to gather expert opinion on 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.
Contents
1. Chapter-1: Agile Evolution 2. Chapter-2: The Scrum 3. Chapter-3: eXtreme Programming 4. Chapter-4: Lead Agile 5. Chapter-5: Software Design 6. Chapter-6: Business Process 7. Chapter-7: HR Practices 8. Chapter-8: Delivery Model 9. Chapter-9: IT Management 10. Chapter-10: The Framework 6 12 17 22 27 33 39 45 52 57
Web Companion
For additional updates, references, SPSS outputs and appendices, refer to project homepage: http://agile.vaibhavsathe.com
Waterfall model and its shortfalls Techniques from manufacturing Toyota Production Systems (TPS) Agile Manifesto, 2001
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 nonrepeatable process.
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.
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. 3. 4. 5. 6. 7. 8.
Create continuous process flow to bring problems to the surface. Use the "pull" system to avoid overproduction. Level out the workload (heijunka). Build a culture of stopping to fix problems, to get quality right from the first. Standardized tasks are the foundation for continuous improvement and employee empowerment. Use visual control so no problems are hidden. Use only reliable, thoroughly tested technology that serves your people and processes.
Section III: Add value to the organization by developing your people and partners
9. Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others. 10. Develop exceptional people and teams who follow your company's philosophy. 11. Respect your extended network of partners and suppliers by challenging them and helping them improve.
Section IV: Continuously solving root problems drives organizational learning
12. Go and see for yourself to thoroughly understand the situation (Genchi Genbutsu) 13. Make decisions slowly by consensus, thoroughly considering all options (Nemawashi); implement decisions rapidly; 14. Become a learning organization through relentless reflection (Hansei) and continuous improvement (Kaizen). Software industry has always borrowed various techniques from operations. The most recent is bringing Kanban or Lean techniques which are largely influenced by TPS. Key ideological commonalities between TPS and Agile methods are building continuous process, focus on visual representations, increased coordination between all stakeholders, higher visibility to management at
all stages and decentralization of decision making. We will see Kanban implementation for software in greater details in Chapter 4.
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
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 Practitioners Approach, Fifth Edition, McgrawHill. 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 worlds 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.
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 Schwabers 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.
Product Backlog Sprint Backlog Sprint Daily Standup Meet Shippable Product Increment
Product Owner creates prioritized outstanding list of work items or features. 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 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. During the sprint, daily reviews are conducted called as daily standup meetings. At end of sprint, work should be potentially shippable, ready in hand to customer, put on store or show to stakeholder. Sprint ends with review and retrospective.
Pigs
ScrumMaster: The teams 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.
User Stories
User stories highlight scrums 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.
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.
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. 2. 3. 4. Scrum Basics, ScrumAlliance website retrieved from http://scrumalliance.org on Jan 3, 2012. Schwaber Ken, Agile Project Management with Scrum, First Edition 2004, Microsoft Press. Schwaber Ken, The Enterprise and Scrum, First Edition 2007, Microsoft Press. Joel Wenzels 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.
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 Its 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 teams 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]
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.
The XP Team
Following are core and supplementary roles in Extreme Programming methodology. [1]
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.
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
[2]
Spike solution is implemented when a tough technical problem is encountered and solved by putting pair of developers who are dedicated to solve that problem ignoring all other concerns.
Iterative Development
Following diagram depicts single iteration of development in an extreme programming cycle. Important point to be noted is it is against rules to look ahead and do something not scheduled in this iteration.
[2]
Pair Programming
In Pair programming technique, two programmers work together on single piece of code or module on one workstation. While one types other does review. They switch roles frequently. To know more about Pair Programming practice of Extreme Programming refer to wikipedia article at: http://en.wikipedia.org/wiki/Pair_programming Logically, this method doubles the cost of development and various experiments have yielded contradictory results. However, Microsoft Researchs 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.
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. Lets 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.
[5]
[6]
References
1. Extreme Programming Pocket Guide Team Based Software Development, Oreilly 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: Whats in it for Me?, published by ACM as proceedings of second ACM-IEEE symposium ESEM08. 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.
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 organizations value chain.
Figure 8 Application of Agile methods on value chain, Source: Alan Shalloway - Lean/Agile
[1]
Lean Kanban
What is Kanban?
TPS [5] defines Kanban as signal of some kind e.g. sign, card, billboard, poster etc. Toyotas 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
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.
[6]
meet the target. Root cause analysis of cluster of such just failed category provides improvement opportunity.
After Meetings
Sticky Buddies
References
1. Shalloway Alan, Beaver Guy, Trott James, Lean-Agile Software Development Achieving Enterprise Agility, Net Objectives Lean Agile Series, published by Addison-Wesley, USA, 2010. 2. Anderson David J, Kanban Successful Evolutionary Change for Your Technology Business, published by Blue Hole Press, USA, 2010.
3. Vega Frank, Scrum, XP and Beyond One Development Teams 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.
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.
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.
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
[8]
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.
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.
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.
Emergent Design
Emergent or continuous or evolutionary design is a process of continuous refactoring resulting in improvement of programs 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 others 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. Ciscos 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. Microsofts 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
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 AOSD11. Retrieved from ACM digital library. 8. Sara Stoecklin et al, Teaching Students to Build Well Formed Object-oriented Methods through Refactoring, proceedings of SIGCSE07, 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 OOPSLA09 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.
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 ITs agile adoption initiatives. We will look at how business teams (clients) manage change and prioritize their work.
Customer
Lets 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 developers process for ROI. It is said, Great Scrum needs great product owners [6]. Judy highlights in his paper that close collaboration beyond standard definition of roles of customers and developers is needed in order to promote organizational efficiency and innovation that is expected out of scrum.
Common Issues
Various issues that impact agile process during interaction with customer are
[1]
Participation: Low level of customer participation as they think its 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: Its difficult for customers to think of all scenarios in requirement phase. They cant 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 cant 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.
Functional Mindset
Majchrzak [4] also argues that just implementing process completeness through integrations in responsibilities is not sufficient. The employees and managers need to develop mindset that is process complete and not functional i.e. think about larger picture and beyond the team. It increases organizational focus on collaboration, helps reduce bureaucratic approach. It also helps develop common goals for front-end and back-end employees which are more closely aligned to business goals. In terms of Agile software development, this approach helps as agile demands customer focus and larger business interaction from software developers.
Business IT alignment
Business IT alignment is defined in terms of Business Processes, Information Technology Business 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% Fortune 500 companis are fully operating on Applications 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
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.
[8]
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 Intl 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.o07. 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
4. Ann Majchrzak, Qianwei Wang, Breaking the functional mindset in process organizations, Harvard Business Review. 5. Oualid Ktata, Ghislain Lvesque, Agile development: issues and avenues requiring a substantial enhancement of the business perspective in large projects, published in proceedings of C3S2E '09 retrieved from ACM Digital Library. 6. Judy, K.H., Great scrums need great Product owners: Unbounded collaboration and collective Product Ownership, Proceedings of the 41st Hawaii International Conference on system sciences, 2008 7. Haki, M.K., Forte, M.W., Proposal of a service oriented architecture governance model to serve as a practical framework for business-IT Alignment, New Trends in Information Science and Service Science (NISS), 2010 4th International Conference on, 2010. Retrieved from IEEE library. 8. Chen, Hong-Mei, Towards Service Engineering: Service Orientation and Business-IT Alignment, Proceedings of the 41st Hawaii International Conference on System Sciences, 2008.
Chapter 7: HR Practices
Chapter 7: HR Practices
In this chapter
Introduction
Software organizations aiming adoption of agile methods for large projects need holistic transformation. Vital change is required in firms 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 Toyotas 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.
Chapter 7: HR Practices
[2]
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.
Chapter 7: HR Practices
Desired Competencies
As explained with Toyotas 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 cant 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 Teams Collective Competencies 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Required Technical Skills Required Business Knowledge Customer Focus* Dealing with Ambiguity Problem Solving Creativity Respecting Differences Positive Conflict Change Management Decision Making Collective Ownership Agile Team Managers Competencies 12. 13. 14. 15. Innovation Management Fostering Diversity* Understanding Company Culture* Develop and Grow People Members Individual
Communication Skills Interpersonal Skills/Team Skills Integrity and Trustworthiness Accomplishment Orientation or passion 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 Menlos case in [6].
Chapter 7: HR Practices
Performance Management
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.
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 individuals 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.
Chapter 7: HR Practices
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.
Chapter 7: HR Practices
References
1. David Moran, the challenges of managing knowledge workers, Supervision; May 2010, Vol. 71 Issue 5, retrieved from Business Source Complete. 2. Madeline Crocitto, Mohamed Youssef, The Human side of organizational agility, Industrial Management and Data Systems, Emerald 2003. 3. Liker, Jeffrey K. (2004), The Toyota Way: 14 Management Principles from the worlds greatest manufacturer, First Edition, Tata McGraw-Hill. 4. Andrea Hoplight Tapia, Hostile Work Environment.Com: Increasing Participation of Underrepresented Groups, Lessons Learned from the Dot-Com Era, The DATA BASE for Advances in Information Systems Fall 2006 (Vol. 37, No. 4). 5. Extreme Programming Pocket Guide Team Based Software Development, Oreilly Canada 2003. 6. Clement James Goebel III, PMP, Menlo Innovations, How Being Agile Changed Our Human Resources Policies, proceedings of Agile Conference 2009, retrieved from IEEE Computer Society. 7. Microsoft Employee Stock Award and Executive Compensation plan retrieved on Jan 23, 2012 from http://www.microsoft.com/investor/reports/ar11/financial_review/employee_stock_savings.html 8. Google performance review experience, retrieved on Jan 23, 2012 from http://www.quora.com/How-are-performance-reviews-done-at-Google-What-are-they-used-for 9. Deloitte Touche Tohmatsus International Mobility program, retrieved on Jan 23, 2012 from http://careers.deloitte.com/united-states/experiencedprofessionals/learndev_globalprograms.aspx 10. Giovanni Aspron, Motivation, Teamwork, and Agile Development, Agile Times, Volume 4, 2004.
Distributed Teams Outsourcing Offshoring Software As Service model Open Source Delivery Model
Introduction
We have seen so far that agile methods like scrum, kanban or eXtreme Programming are well suited for the development teams and customers are collocated together. But, for obvious economic reasons, globally distributed teams for software development is imminent. Organizations are increasingly relying on outsourcing and offshoring in order to drive down costs, access larger talent pools and provide support round the clock. If agile team members are spread across locations, then there are challenges with respect to work timings, coordination and communication. Outsourcing on other hand creates heterogeneous teams consisting of members from different organizations, and hence poses challenges due to difference in organizational culture and HR practices like performance reviews, incentives etc. Software-as-a-Service (SaaS) model is developing very fast, where companies instead of selling customized software, are hosting the applications themselves and licensing based on usage to clients. Surveys indicate [2] SaaS companies are increasingly adopting agile methodologies. In this chapter, we will also look at agile adoption factors for companies relying on SaaS based software delivery. Open source development model is one emerging model used by companies like GE or IBM where certain middleware or frameworks are developed on open source principles, which are sponsored by these firms. It is interesting to note how such teams are following principles like extreme programming.
Distributed Teams
Distributed team means when members working on same project while they are not located under one roof. This involves various team configurations as explained below.
Terminologies
Some terminologies in distributed teams for software development are [1]: Offshoring: Offshoring means when company opens facilities outside home country, typically in developing countries like India or China and hire local talent as employees of its subsidiary in order to carry out software development. Outsourcing: Outsourcing means when company (client) hires services of third party organization (vendor) to completely or partially develop software for its own consumption. The client firm and not the vendor retains complete ownership over the developed product. There exists a short term or long term contract specifying resources and price. These can be summarized by the table:
Table 1 Distributed Team delivery models
We will now see various success factors for these delivery models from agile development perspective.
Offshore Teams
Ramasubbu [8] identifies that dispersion has negative impact on productivity of software projects but can be mitigated by structured engineering practices. Mindtree Ltd. has identified some critical success factors for distributed teams in order to work on agile [7]. Based on that study, we have derived some factors as below. Base Camp Selected individuals from distributed teams should spend some time together at central lo cation. Activities included in base camp are drafting initial high level requirements, initial user stories, plan on coding standards and communication methods. This is also recommended by Banerjee et al of NIIT [9] from their experience of executing distributed agile project from India. Flat Structure It is important that teams located globally are equal and not reporting into particular location. The flat hierarchy is important characteristic of agile teams. This should be facilitated by having leads or representatives at each level which enjoy equal decision making power.
Page 46 Agile Adoption Readiness Framework
Crisp Handovers Daily standups require time flexibility and should be restricted to each location. The handovers and coordination should be done by daily meetings between leads or repre sentatives at time zone overlap. Query Tracking Any queries or clarifications should not be tracked over emails or chat as it is difficult to track them. The best way is to track them using query tracking tool like Visual Studio which can help with work items which can be assigned to concerned people and easily tracked for completion. Plan Test Drives Test drives should be planned at sufficient frequency at each location. The representatives from other locations should participate in this activity. Internal Quality Since development team does not sit together while working on same project, it is important that internal quality is provided sufficient attention. This includes coding standards, naming conventions, test procedures etc. It also should focus on proactive assessment of progress, quality and performance [8]. Effort variance Redistribution of work overseas may be problematic. Hence, effort variance should be computed first at local level, make required adjustments and then it should be adjusted globally. Since, handovers across locations are not very easy, it should be kept at local level.
Outsourced Teams
When the teams are composed of members from different organization, i.e. outsourced work, location difference specific problems may still apply if these are different. But, even at same location, due to organizational differences, following additional success factors are important. Fixed Price Contracts Most outsourcing vendors work on fixed price contracts. Under such contracts, vendor may not accept frequent changes as expected from agile teams [10]. It is also biggest point of contention. Client can derive the benefit of changing requirements only if client is ready to absorb the additional costs of change without burdening vendor or else ready to exchange requirements as mutually agreed by vendor. This must be captured in the agreements signed for outsourcing. Equal Training Levels Generally vendor organizations are responsible for training of their employees and not client. This can result in inadequate training for vendors compared to client employees. Client organizations should therefore provide required training themselves or make it contractual obligation. Equal Skill/competency level
Page 47 Agile Adoption Readiness Framework
Heterogeneous teams of client and vendor employee should be at par with competency and skill levels. If there are drastic differences, then those members dominate decision processes creating sort of hierarchy. Incentive systems We have seen importance of performance measurement and HR policies on agile projects. Vendor employees working on the project should have same level of motivation. It can be ensured only with similar performance based incentive system. The client should bind vendors with contractual obligation on same. It is critical for success of agile process. Vendor Leads Vendors working with client in a mixed team should have lead of their own (ambassador as recommended by Batra [10]) to represent them. The vendor lead also should enjoy decision making at par with the client lead. This creates feeling of ownership and trust among vendor teams.
SaaS Model
Software-as-a-Service or popularly called as SaaS, is a software delivery model in which applications and/or data is stored centrally on internet or cloud, which is consumed by users which are thin clie nts. Gartner [5] predicts strong growth of this business model as companies worldwide look upon bringing their IT infrastructure costs down. The SaaS solution itself represents lean approach of just in time consumption of required resources. This allows companies to focus on where they excel i.e. doing their business and not in maintaining huge IT infrastructure. The main SaaS vendors include IBM, Microsoft, Amazon, Google, Oracle, SAP. With SaaS model, the vendors have found that the frequency of releasing major version updates is much higher than it was in earlier desktop based applications.
Agile Methodology Short period cycles, continuous delivery Customers and Developers work together
Open Source Methodology Release Early, release often motto Participating users/moderators serve the role
Motivated team members, trusted with their Motivated team members, trusted with their expertise expertise Working software as measurement of progress Continuous improvement, technical excellence refactoring Well documented code is the only artifact and
Open source teams manage themselves as community (democratic approach) Continuous reviews and alterations/suggestions
Success Factors
Tsirakidis [4] has identified following factors for successful implementation of agile techniques in an open source model: Constant, synchronous and transparent communication: Through use of advanced ICTs, the team members are constantly informed about any changes in the project specifications. It is also important that such members can communicate to each other though blogs, notifications and personal messages. It is also critical that customers trust these development members and provide all of them with required information. Consistency in methodological development: A standardization of development methods is needed in order to bring consistency. This may include coding standards, testing standards, check-in and review procedures. Geographical dispersion management: Dispersion management techniques like right selection of volunteers, peer reviews, result orientation, feedback mechanism are needed for effective agile implementation in such teams. Understanding and Accepting environmental limitations: Customers should not expect similar maturity in development environment. E.g. perform more unit tests than end -to-end testing. Customers should understand that the benefits of this model are outweighing the drawbacks.
References
1. Jalali Samireh, Wohlin Claes, Agile Practices in Global Software Engineering A Systematic Map, published in proceedings of 2010 International Global Software Engineering Conference, retrieved from IEEE Explore. 2. Rajesh Ranjan, SaaS and Agile Match made in heaven, Mindtree Programming Blogs, retrieved from www.mindtree.com on Feb 1, 2012. 3. Ron Goldman & Richard P. Gabriel, Innovation Happens Elsewhere - Open Source and Agile Methodologies, retrieved from http://dreamsongs.com/IHE/IHE-28.html on Feb. 1, 2012. 4. Tsirakidis, P., Kobler, F., Krcmar, H., Identification of Success and Failure Factors of Two Agi le Software Development Teams in an Open Source Organization, proceedings of ICGSE 2009, retrieved from IEEE.
5. Gartner Says Worldwide Software as a Service Revenue Is Forecast to Grow 21 Percent in 2011 retrieved from Gartner.com on Feb 2, 2012. 6. Ricks blog on SaaS, http://softletter.com retrieved on Feb 2, 2012. 7. Bavani Raja, Critical Success Factors in Distributed Agile for Outsourced Product Development, Mindtree Ltd. 8. Narayan Ramasubbu, Rajesh Krishna Balan, Globally Distributed Software Development Project Performance: An Empirical Analysis, Proceedings of ESEC-FSE07. Retrieved from ACM. 9. Udayan Banerjee, Eswaran Narasimhan, Kanakalata N, Experience of Executing Fixed Price Offshored Agile Project, NIIT Technologies Ltd, proceedings of ISEC11. Retrieved from ACM. 10. Dinesh Batra, Modified Agile Practices for Outsourced Software Projects, Communications of the ACM September 2009. Retrieved from ACM.
Chapter 9: IT Management
Chapter 9: IT Management
In this chapter
Introduction
Agile teams are self-organizing. So a managers role is no more traditional. Practices like Lean require holistic transformations in organizations as evident from examples of Toyota. The Agile is no different. If organization expects to derive larger benef its from such engagements then it needs to adapt its IT project management practices too. The ScrumAlliance defines role of Agile management as following diagram [1]. We have already covered some functions. In this chapter, we will look at how IT governance, funding, support teams, organizational structure and management policies like conflict management, change management impact success of agile methods.
[1]
Chapter 9: IT Management
Project Governance
Roadmaps
When there are backlogs in agile processes, why do we need roadmaps? VeriSign [2] credits success of its agile programs to PMO roadmaps which helped it 1. 2. 3. 4. Help in prioritizing backlog items Ensure IT is delivering in-line with organizational strategy Facilitate architectural evolution due to visualization of future probable requirements Provide customers near term commitments and long term point of view
Requirement Control
In line with agile lean principles, all possible waste should be reduced. This includes avoidance of documents, meetings and discussions unless absolutely necessary. The PMO of VeriSign [1] also facilitated a process to manage changes requested in requirements in order to ensure they are accommodated and teams are not impacted. This is as described below. Business Case Track For complex requirements a detailed case/stories/BRD is needed. It follows standard track of stories->Backlog->planning. Fast Track If newly requested functionality is aligned to previously defined roadmap then, it moves to user stories and into agile process. Inquiry Track If newly requested functionality does not have enough clarity, it needs to be investigated further in order to define the scope.
Project Funding
The key principle of agile is to welcome change. Accommodating change results in changing budgets or requirements. So, the way in which projects are funded is important to determine success of agile projects. This is especially true when there are tight cost controls or you are dealing with vend ors on fixed price contracts. But, even for internal relaxed funded IT teams, any variance in budgets is always important issue.
Chapter 9: IT Management
Budget Process
The budgeting process begins very early in most of organizations which define high level requirements for various projects and allocate funds for them based on priority order. These methods are generally not suitable to agile way. The organizations must implement quick IT investment change management processes for effective agile implementation [3]. This can include formation of funding bandwidths for each project and delegating change control to PMO or General Managers.
Measure of delivery
For effective agile deliveries, the measure of delivery should not be set of requirements but amount of functionality. This means, business and development teams should define way of quantifying functionality and decide upon them for given budget. If any particular requirements change, the development team can trade for something of equal functionality measure from next sprint without altering budget.
Management Policies
Chapter 9: IT Management
Support Organizations
The Support groups in IT organizations primarily consists of (1) Infrastructure Support (2) Data Support and (3) Application Support. These groups own applications in their run time unlike development teams who own them during design time. While applications are under usage to run business operations, users or customer require a variety of assistance. This is typically covered under Application and Data support. Also, the applications and data are monitored in order to ensure they are up and running and consistent. The corporate data is not static and stored at one location. The huge data flows exist due to various sources and consumers of the data. Also the organization needs to look after its servers and data centers, which comes under infrastructure support. Any development team needs to work closely with support teams in order to deliver their products. In many companies, sign offs from support teams are included as part of process before a newly developed software is released to production. Following are success factors from support organizations point of view for effective agile implementation. Regression Testing Frequent agile releases require frequent regression testing which is generally done by support teams. It is not practical to execute entire regression suite every time a release goes in. In order to optimize the work, it should either be automated or support teams should identify imp acted areas for each release and run a portion of regression suite. SLAs There are service level agreements in place while handling production issues. This puts expectation on development teams to fix any code issues within stipulated time. Support teams should provide separate test environments for such quick fixes as development environments cant be disturbed. Test Data
Chapter 9: IT Management
Support teams also maintain recent test data for pre-production environments. These should be refreshed frequently considering corporate data flows and agile release frequencies to ensure test environments are as close to production. This simplifies business testing process greatly. Involvement Ideally the support team should maintain a point of contact with agile development team. He should at least attend product planning, sprint planning meetings. This will give idea to support organizations what they can expect and what they should provide for each sprint release.
References
1. ScrumAlliance, The Managers role in Agile, retrieved from http://scrumalliance.org on Feb. 3, 2012. 2. Peter Hodgkins, Luke Hohmann, Agile Program Management: Lessons Learned from the VeriSign Managed Security Services Team, Agile 2007 Conference, IEEE Computer Society. 3. Thomas Joseph, Baker Steven, Establishing an Agile Portfolio to Align IT Investments with Business Needs, Agile 2008 Conference, IEEE Computer Society. 4. Bhaven Sheth, Scrum 911! Using Scrum to Overhaul a Support Organization, Agile 2009 conference, IEEE Computer Society 5. Agile Manifesto Principles, Retrieved from http://agilemanifesto.org/principles.html on Feb 4, 2012. 6. Steven Sinofsky, Microsoft Corp., PM at Microsoft, retrieved from http://blogs.msdn.com/b/techtalk on Feb 4, 2012. 7. Domino M, Collins R, Hevner A, Cohen C, Conflict in Collaborative Software Development, SIGMIS Conference 2003, retrieved from ACM.
Looking Back
This research report was structured to serve as complete guide to organization looking for agile software development methodology adoption. In this study, we looked at three methods Scrum, Extreme Programming and Kanban. Then we looked at various factors under 5 areas Software Design, Business Processes, Human Resource Practices, Delivery Model and IT Management. A massive literature survey was carried out to list down the factors. A total of 12 books, 20 online sources and 38 published papers from sources like ACM, IEEE, Business Source Complete and Emerald were reviewed in order to extract initial list of factors. The papers were selected based on relatively higher citation count. Paper containing surveys or case studies describing experiences of users were preferred. Any paper discussing same topic i.e. factors affecting adoption were ignored to avoid any bias from different experiments conducted by those authors. In previous 9 chapters we have seen in detail various factors that affect the agile software development methodologys successful adoption in organization. As discussed in below section we have identified 51 such factors from various literature papers surveyed. In this chapter we explain how the exploratory study was conducted. First, the research method will be explained and then results will be analyzed in detail. We will finally reduce these 51 factors by grouping correlated factors together.
Chapter 10: The Framework Section Variable ID VAR00001 VAR00002 VAR00003 VAR00004 VAR00005 VAR00006 VAR00007 VAR00008 VAR00009 VAR00010 VAR00011 VAR00012 VAR00013 VAR00014 VAR00015 VAR00016 VAR00017 VAR00018 VAR00019 VAR00020 VAR00021 VAR00022 VAR00023 VAR00024 VAR00025 VAR00026 VAR00027 VAR00028 VAR00029 VAR00030 VAR00031 VAR00032 VAR00033 VAR00034 VAR00035 VAR00036 VAR00037 VAR00038 VAR00039 VAR00040 VAR00041 VAR00042 VAR00043 VAR00044 VAR00045 VAR00046 VAR00047 VAR00048 VAR00049 VAR00050 VAR00051 Variable Name Maintainability Measurement of Output Reusability Object Oriented Design principles Knowledge of Design patterns Automated Documentation Unit Test suite as documentation Automated Unit Testing Refactoring Refactoring Commitment Architectural Strategy Evolutionary Design Customer Availability Customer Knowledge on Agile Customer Communication Customer Transparency Self Sufficient Team Knowledge about client usage Business Alignment Process Reengineering Wider competencies Diverse Teams Mobile Workforce Peer Reviews Team Performance over Individual Encourage Innovation Mentorship Soft skills training Best practice sharing Employee Perks Flexible timing Base camp meeting Parallel hierarchy across location Simplified Coordination Formal communication tools Minimum Internal Quality Criteria Minimize global task transfers Vendor Contract structuring for change Vendor skill assessment Vendor training requirement Vendor Performance expectation alignment Vendor Leadership PMO roadmap alignment Requirement classification and roadmap check Resource Limit IT Investment change management Contractual measurements Parallel Dev, Test, PM hierarchy Automated Regression Recent data in test environment Support team participation
Software Design
Business Process
Delivery Models
IT Management
Research Methodology
In order to reduce these factors by Exploratory Factor Analysis (EFA) method, a primary research survey was conducted.
Questionnaire Questions
A survey questionnaire was designed with one question corresponding to each of the 51 variables. Audience was asked to rate importance of the factor as output. In addition, basic information on user profile was collected including their agile exposure and role in organization. Also, the users were asked optional subjective questions in the end to narrate particular experience. Some of the inputs have been listed anonymously in later section of this chapter. All questions were positive in nature i.e. importance of presence of factor will always be indicated by 7 for successful agile adoption.
Scale
All responses were gathered on Likerts 7 point scale from Not Important to Very Important. All questions had same response scale, so no standardization of responses was required.
Sampling Method
It was decided to conduct the survey as Expert survey. The method used was Snowball sampling which is non-probability sampling method. Invitations were sent out to known practitioners of agile methodologies. Individuals were also asked to forward invitations to people they know who have experience in agile methods. We have received considerable number of responses from such secondary level of contacts. Based on responses received, individuals were found to be of different profiles like developers, test engineers, business analysts, program managers, architects, resource managers and consultants. These individuals have varying backgrounds from fields like product development, supply chain, cloud computing, financial services and telecommunication services. These individuals belong to different organizations like Microsoft, Accenture, Amazon, MindTree, Barclays, IBM, Netflix etc. A total of 26 valid survey inputs were considered after eliminating incomplete responses.
Analysis Tool
Software used for analysis was IBM SPSS version 16.0 available with IIM Lucknow. The tool supports out-of-box functionality for statistical analysis using Factor reduction method. This helps summarizing large factors into more compact components. The tool also supports Varimax rotation.
Factor Analysis
Following are various details regards to Exploratory Factor Analysis method conducted.
Descriptives
We will use following descriptives to check validity of factor reduction analysis. (1) Kaiser-Meyer-Olkin Measure (KMO) of sampling adequacy: This measures partial correlations between variables. If > 0.5, it indicates that the given sample is sufficient for factor reduction. Otherwise, it may indicate that the factor analysis is satisfactory. Due to limitation of time, we were able to gather just sufficient responses. Hence, we will perform the factor analysis even if this number is less than 0.5. (2) Bartletts Test of Sphericity: The null hypothesis that factors are uncorrelated must be rejected in order to proceed with the factor analysis. If significant is less than 0.05, it indicates there is sufficient evidence to reject null hypothesis and the factors have strong correlation among themselves, hence factor analysis can be conducted.
Extraction Method
The motive is to extract minimum number of factors that explain variation. Hence, we will use Principle Component Method for extraction.
Rotation Method
Since we want to reduce number of variables with high loading on a factor, we use orthogonal rotation. The particular method used here is Varimax rotation with Kaiser Normalization.
Interpretation Method
We will interpret loading of variables on factor using rotated component matrix. We will follow general thumb rule of identifying loadings which are >=0.5. In some cases, where variable did not load on any factor, we have taken factor loadings which are close to 0.5, due to inadequacy of sample size.
Rotated Component Matrix a Component Variables Maintainability Measurement of Output Reusability Object Oriented Design principles Knowledge of Design patterns Automated Documentation Unit Test suite as documentation Automated Unit Testing Refactoring Refactoring Commitment Architectural Strategy 1 -.140 -.063 .608 .727 .840 .039 .350 .093 .235 .000 .722 2 .086 .003 .010 .301 -.070 -.104 .121 -.035 .868 .925 .262 3 .040 .907 -.063 .061 -.093 -.002 -.318 .076 -.030 .053 .173 .797 4 .119 .180 -.092 -.409 .151 .927 .485 -.072 -.053 -.032 .323 -.273 5 .951 -.034 .719 .019 -.049 .094 -.078 .076 .081 .014 .044 .041 6 .124 .095 -.116 .095 .286 -.094 .370 .959 .102 -.116 -.144 -.040
Evolutionary Design .115 .038 Extraction Method: Principal Component Analysis. Rotation Method: Varimax with Kaiser Normalization. Rotation converged in 7 iterations.
Interpretation
The factors are interpreted as follows.
Factor F1 Factor Interpretation Object Orientation Mastery Variance Explained 19.57% Loading 0.608 0.727 0.840 0.722 0.868 0.925 0.907 0.797 0.927 0.485 0.951 0.719 0.959 Variables in Factor Reusability Object Oriented Design principles Knowledge of Design patterns Architectural Strategy Refactoring Refactoring Commitment Measurement of Output Evolutionary Design Automated Documentation Unit Test suite as documentation Maintainability Reusability Automated Unit Testing
F2 F3 F4 F5 F6
Refactoring Non-conventional design Alternate documentation Modular Code Unit Test Automation
Rotated Component Matrix a Component Variables Customer Availability Customer Knowledge on Agile Customer Communication Customer Transparency Self Sufficient Team Knowledge about client usage Business Alignment 1 .815 .378 .121 .696 .128 .735 .083 2 .115 .298 -.291 -.060 .795 .396 .859 3 .003 .724 .689 .261 -.171 -.096 .123 -.648
Process Reengineering .466 -.028 Extraction Method: Principal Component Analysis. Rotation Method: Varimax with Kaiser Normalization. Rotation converged in 5 iterations.
Interpretation
The factors are interpreted as follows.
Factor F7 Factor Interpretation Customer Involvement Variance Explained 31.51% Loading 0.815 0.696 0.735 0.795 0.859 0.724 0.689 -0.648 Variables in Factor Customer Availability Customer Transparency Knowledge about client usage Self Sufficient Team Business Alignment Customer Knowledge on Agile Customer Communication Process Reengineering
F8 F9
19.87% 15.42%
Extraction Method: Principal Component Analysis. Rotation Method: Varimax with Kaiser Normalization. Rotation converged in 7 iterations.
Interpretation
The factors are interpreted as follows.
Factor F10
Loading 0.767 0.732 0.894 0.549 0.843 0.821 0.881 0.715 0.925 -0.464 0.875
Variables in Factor Encourage Innovation Mentorship Soft skills training Diverse Teams Employee Perks Flexible timing Mobile Workforce Peer Reviews Wider competencies Best practice sharing Team Performance over Individual
F11
Employee Morale
17.42%
Vendor Leadership .803 Extraction Method: Principal Component Analysis. Rotation Method: Varimax with Kaiser Normalization Rotation converged in 7 iterations.
Interpretation
The factors are interpreted as follows.
Factor F15
Loading 0.580 0.849 0.828 0.803 0.837 -0.615 0.776 0.855 0.591 0.844 0.551
Variables in Factor Minimize global task transfers Vendor Contract structuring for change Vendor Performance expectation alignment Vendor Leadership Parallel hierarchy across location Formal communication tools Vendor training requirement Minimum Internal Quality Criteria Vendor skill assessment Base camp meeting Simplified Coordination
F16
Equivalency of teams
15.68%
F17 F18
13.51% 12.12%
Interpretation
The factors are interpreted as follows.
Loading 0.904 0.883 0.796 0.842 0.664 0.508 0.818 -0.593 0.521 0.843
Variables in Factor Recent data in test environment Support team participation Requirement classification and roadmap check Contractual measurements PMO roadmap alignment Resource Limit IT Investment change management Automated Regression Resource Limit Parallel Dev, Test, PM hierarchy
F22
Resource Management
11.61%
Conclusion
Based on the literarature survey and primary research conducted, we can conclude that we were able to arrive at model for important factors that determine software agile adoption. The summerized factors can be broken into original variables using interpretation section of this document. The model framework can be summarized as follows. The factors are in decreasing order of importance in each category. The categories are independent of each other.
Object Oriented Mastery Refactoring Non-conventional design Alternate Documentation Modular Code Unit Test Automation
Employee Development Employee Morale Workforce Dynamics Skill Diversity Team Performance
Software Design
Business Process
Delivery Models
IT Management