Agile Adoption Framework

3,127 views

Published on

IIM Lucknow CIS Report. Visit website - http://agile.vaibhavsathe.com for more details and SPSS outputs on the project.

Published in: Technology, Business

Agile Adoption Framework

  1. 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 agilemethodologies 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. 2. APPROVED FOR SUBMISSION TO PGP OFFICE TOWARDS TERM VI REQUIREMENTSOF PGP COURSESignature:Dr. Bharat BhaskerProfessor,Information Technology & Systems Area,IIM LucknowDate: 22.02.2012 Page 2 Agile Adoption Readiness Framework
  3. 3. AcknowledgementsThe author would like to thank Prof. Bharat Bhasker for the most valuable help and guidance heprovided throughout the course of this project, without which it was impossible to achieve thecompletion.The author acknowledges Mr. M. U. Raja and the staff of IIM Lucknow Library, who promptlyprocured all the books required in this massive literature survey. Author also thanks library andadministration of IIM Lucknow and ESCP Europe, Paris campus for the rich collection of journalsand digital database subscriptions without which the project could not have been completed.Author thanks numerous authors of books, articles, papers, blogs and other publications whosereferences 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 CorporationBhavik Vora, Sr. Software Engineer, Microsoft India R&D Pvt. Ltd.G. Nagraj, Director, TeamDecode Software Pvt. Ltd.Krunal Dedhia, Sr. Software Engineer, AccentureNaveen 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 IndiaRohit Ratnakar Mallya, Global System Engineering Lead, Microsoft CorporationSandhya Rithe, Program Office Manager, BarclaysSanjay BK, PGDM Student, Indian Institute of Management LucknowSudheesh S, Associate Consultant, MindTree Ltd.Swati Patil, PGDM Student, Indian Institute of Management LucknowVikas Gupta, General Manager and Global Practice Head (Cloud Computing), MindTree Ltd.Vinayak Rakkasagi, PGDM Student, Indian Institute of Management LucknowVivekananda Parepalli, PGDM Student, S.P. Jain Institute of Management & ResearchAuthor also acknowledges the contribution of all survey participants including those who chose toremain anonymous, while helping this project. Page 3 Agile Adoption Readiness Framework
  4. 4. Executive SummaryThe objective of this study was to identify factors that affect adoption of agile methodologies insoftware 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 onchapters dedicated to each topic as below.Chapter 1This study included a detailed literature survey in which we have taken overview of evolution ofvarious software engineering methods. Later on we have discussed how the principles of agilemanifesto formed foundation to various agile methods like Scrum, Kanban and ExtremeProgramming.Chapter 2, 3 and 4Then we have discussed in brief the three agile methods mentioned above with detailed explanationof terminologies, meetings, tracking methods, delivery cycles and various tools that are used. Wehave analyzed these methods from perspectives of customer and developers.Chapter 5 - 9In later section, literature survey was carried out to identify list of possible variables that impactadoption of agile methods. Various case studies, published papers, interviews and websites ofconsultants were reviewed. A list of 51 such variables was finalized organized in 5 sections which aredifferent organizational aspects of software development – Software Design, Business Process, HRPractices, Delivery Model and IT Management.Chapter 10Primary survey was conducted to gather expert opinion on criticality of these factors. StatisticalExploratory Factor Analysis was performed to identify correlated factors together. A summarizationexercised 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 inadoption process. Page 4 Agile Adoption Readiness Framework
  5. 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 57Web CompanionFor additional updates, references, SPSS outputs and appendices, refer to project homepage:http://agile.vaibhavsathe.com Page 5 Agile Adoption Readiness Framework
  6. 6. Chapter 1: History of Agile Development Chapter 1: Agile EvolutionIn this chapter… Waterfall model and its shortfalls Techniques from manufacturing Toyota Production Systems (TPS) Agile Manifesto, 2001Waterfall software development modelSince pre-historic times, most projects were executed sequentially. For example, in thatera construction projects were most prominent. Hypotheses on construction ofEgyptian Pyramids suggest that the approach followed was – Specification ofrequirements, designs and models, creation of building blocks, assembly, variousverifications and necessary modifications. The similar approach was followed inmanufacturing industry later on and then when software industry was born, naturallythis 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 problemFigure 1 Pressman (1994) Waterfall Software Model again and again, thereby gaining Page 6 Agile Adoption Readiness Framework
  7. 7. Chapter 1: History of Agile Developmentexpertise and improving efficiency through learning. Maurer and Melnik also state that key reasonwhy such methods are inapplicable to software development is because fundamentally it is non-repeatable process.Steps in Waterfall ModelPressman[2] defines waterfall model for software engineering as follows. It consists of steps likeRequirements 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 ofactual against expected specifications and finally acceptance or actual deployment of system into thebusiness. Important thing to note here is most of these activities happen in a strict sequence with verylittle or no scope for backtracking more than two steps without restarting the whole process.Problems with waterfallThe biggest issue is that the waterfall expects requirements to be frozen in order to begin analysisand design phases. Project managers working on waterfall models expect requirement signoffs inorder to begin their effort on estimates and functional specifications. And once they freeze theirspecifications, downstream developers begin coding work. All hell breaks when certain requirement isinvalidated, added or even modified. Reality is that it is impossible for business to freeze requirementsseveral months in advance (before they get delivery of entire project through above steps). AlanShalloway[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 inadvance. Software design and processes therefore, should mature in order to handle changingrequirements.Other problem includes that working version of the project is available only in the end. It creates twoproblems, one in terms of justifying investments without seeing returns and other is risk of increasinggap from stakeholders’ expectations.The waterfall processes do not encourage larger stakeholder participation in multiple stages. It ratherfocusses 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 qualityof output as processes, people and design is not ready to handle such deviations. Softwaredevelopment fundamentally differs from manufacturing activities in terms of huge time take n fordevelopment and availability of option of reversal. These two differences result in dynamicrequirements and hence the thought process began on adopting processes to this phenomenon.Techniques from ManufacturingManufacturing firms realized that the key competitive advantage lies in their efficiency which willenable them to retain profit margins while becoming cost competitive in the market. Various newtechniques evolved to increase efficiency, throughput, quality and productivity of manufacturing andsupply chains. Software industry borrowed many of the ideas, concepts or methods and developedseveral new methods to address problems of similar nature. We will look into some keymethodologies. Page 7 Agile Adoption Readiness Framework
  8. 8. Chapter 1: History of Agile DevelopmentSix SigmaDeveloped 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 SixSigma in Software are that since software development is non-repetitive, statistical methods areineffective and inability to link software metrics to direct economic or customer centric metrics formost companies. As per Dr. Fehlmann[8], The software implementation of Six Sigma is based on threeprinciples. (1) Use customer centric metrics only. (2) Adjust to moving targets (3) Enforcemeasurement.The key similarity between Six Sigma and Agile Techniques is in its principle to recognize that changeis imminent and processes need to adapt. Also, both methods make project more transparent to themanagement and the customer.CMMICapability Maturity Model Integration in Software Engineering is process developed by SoftwareEngineering Institute (SEI) at Carnegie Melon University. It focusses on integrating separateorganizational functions, defines objectives for process improvements, defines organizationalpriorities, provide guidance for quality processes and provide point of reference for improvements incurrent processes. The CMMI defines various stages of maturity as Maturity Level 2-5 in SoftwareDevelopment, Services and Acquisitions areas. This indicates systematic synergistic approach ofprocess evolution.Broad opinion considers CMMI as complete opposite ideology of Agile methods. However, manyresearchers differ. They find increasing commonalities and cross-influences of one another as bothprocesses have evolved. Some of notable work includes, presentation by Dr. Russwurm [7] fromSiemens 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/PSPTSP stands for Team Software Process and PSP stands for Personal Software Process. Both weredeveloped by Software Engineering Institute of Carnegie Melon University. These processes guideengineering teams in developing software intensive products and claim to produce secure andreliable software in less time and lower cost.Personal Software ProcessPSP focusses on individual learning in steps – (1) Process Discipline and Measurements (2) Estimationand Planning and (3) Quality Management and Design. Again, PSP is considered Predictive while Agileis considered in contrast, Adaptive methodology. But, PSP focusses on individual developers andhence can be adapted to suit needs of Agile development. Commonalities include focus on realisticschedules, estimations and continuous modifications in schedules. Page 8 Agile Adoption Readiness Framework
  9. 9. Chapter 1: History of Agile DevelopmentTeam 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 teamand the TSP team are that both believe in team members taking complete responsibility for theirwork. They work on creating environment of trust and accountability and they work together onrealistic plans.Toyota Production SystemsToyota Motor Corporation consolidated its managerial philosophy in “The Toyota Way” [6] written byJeffrey Liker, which is based on two primary principles “Continuous Improvement” and “Respect forpeople”. Dr. Liker explains the system in following 14 principles.Section I: Long-term philosophy1. 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 results2. 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 partners9. Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others.10. Develop exceptional people and teams who follow your companys 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 learning12. 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 isbringing Kanban or Lean techniques which are largely influenced by TPS. Key ideologicalcommonalities between TPS and Agile methods are building continuous process, focus on visualrepresentations, increased coordination between all stakeholders, higher visibility to management at Page 9 Agile Adoption Readiness Framework
  10. 10. Chapter 1: History of Agile Developmentall stages and decentralization of decision making. We will see Kanban implementation for software ingreater details in Chapter 4.Agile Manifesto, 2001The alternatives to waterfall model started surfacing in mid-1990s targeting different problems. Thisincludes Extreme Programming (1996), Scrum (1995), Feature Driven Development or Test DrivenDevelopment. These methods were later rebranded under the agile umbrella after declaration of AgileManifesto in 2001.In February 2001, 17 software developers met at Snowbird resort and published Manifesto for AgileSoftware Development[4]. This was beginning of agile revolution in software world. These authors laterformed the Agile Alliance, a non-profit organization for promotion of development based onprinciples 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. Throughthis 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 planThat 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 encouragingdynamic 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 ManifestoIn February 2011, on the day of 10 th anniversary of manifesto, many senior agile developmentprofessionals 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 SystemsInnovation” is worth mentioning here. It mentions how the Agile IT practices are going to drive agilityin the business thereby creating larger value in the future. Page 10 Agile Adoption Readiness Framework
  11. 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 todiscuss how Agile can expand into wider business world with cloud, social media and consumer IT.References1. 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. 12. Chapter 2: The Scrum Chapter 2: The ScrumIn this chapter… Scrum framework Scrum Team Scrum Process Scrum tools and documentationIntroductionScrum is an iterative, incremental framework for project management classified underthe Agile techniques umbrella. Scrum principles are based on Agile Manifesto.Although scrum was defined originally from product development point of view, itsmost common usage is for managing software development and/or maintenanceprojects. The scrum process was developed by Jeff Sutherland in 1993. The methodevolved over a decade by work of many and was formalized through release ofSchwaber’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-softwaredevelopment but complex and innovative project. In this chapter, the technicalities ofmethodology are explained in brief. Figure 2 ScrumAlliance® The Scrum Framework [1] Page 12 Agile Adoption Readiness Framework
  13. 13. Chapter 2: The ScrumProduct 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 toIncrement customer, put on store or show to stakeholder. Sprint ends with review and retrospective.The Scrum TeamRoles in scrum are defined as Pigs and Chickens. Pigs are working or core members. Chickens areancillary or non-working members. Scrum requires regular coordination among these members.PigsScrumMaster: The team’s process leader is called as Scrum Master, usually ScrumAlliance® CertifiedScrumMaster. He ensures that scrum process is followed as intended. He may also be member ofworking team. Schwaber says that the authority of ScrumMaster is indirect and comes from hisknowledge of the process. He increases success probability by helping Product Owner select mostvaluable backlog and helping team to turn that into functionality. [2]Product Owner: Representative of customer is called product owner. He/she provides and prioritizesrequirements and has authority to alter/control changes. Generally, product owners are not teammembers 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.ChickensManagers: Managers are people or project managers who control the work environment andpossibly budget for the teams. They are also responsible for performance reviews of the teammembers.Stakeholders: Stakeholders include customers and vendors other than Product Owner who is activemember of scrum team. These are potential suppliers or benefactors of the project work and aregenerally involved only during sprint reviews.The Scrum ProcessThe scrum process includes following key activities. [6] Page 13 Agile Adoption Readiness Framework
  14. 14. Chapter 2: The ScrumPlan the ProjectPlanning process sets expectations of stakeholders, who are beneficiaries, sponsors or someone whois affected by delivery or non-delivery of the project. Amount of budget, time duration, expecteddeliverables and identified risks are included in the plan. The minimum plan consists of a vision and aproduct backlog. Vision is the motive, desired end state and impact of project on variousstakeholders.User StoriesUser stories highlight scrum’s customer centric focus. It is functionality explained from point of viewof 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 achievinghigher accuracy in estimations and work division.Team VelocityTeam velocity is number of story point it can complete it given duration of sprint. This is obtainedbased on historical data or rough estimations in absence of history. This is more generalized estimatewhich helps in planning how many stories to include in given sprint or decide team size. Accurateestimations of tasks are only considered in individual sprint planning.Release PlanIterative release plan is made based on which user stories are dependent on each other, and howmuch value they add to end user. Also, for each sprint, new stories can be added or removed. Groupsof user stories are made, which represent releasable feature, something that can provide s ufficientbusiness value to customer.SprintTeam starts work in sprints of fixed duration.Sprint Planning MeetingDuring Sprint Planning meeting which runs for a day, team breaks down stories to identify exact tasksand develops estimates. Commonly used estimation methodology is Planning Poker which is basedon consensus between team members on sizes of each work item. Team then commits to this agreedupon 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. 15. Chapter 2: The ScrumDaily Stand-up meetingsTeam members meet daily for short time (hence stand up) and share their accomplishments of lastday, plan for today, and any possible issues they foresee.Finishing the SprintSprint Review MeetingIn the end, Sprint Review is conducted where team presents deliverables. Customers accept thestories if expectations are met. Incomplete and new stories are added back to product backlog.RetrospectiveIn 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 generaleffectiveness, productivity and quality of the teamwork. Solutions identified are incorporated inplanning meeting of next sprint. They are also recorded in organizational KM systems for feedback toother teams.Scrum tools and documentationScrum does not focus on creation of excessive documentation. There are various tools available fortracking scrum projects like Microsoft Project, Microsoft Visual Studio, IBM rational have add -ins. Let’sreview one of the simplest among them, an Excel based worksheet which is part of Mi crosoft ScrumKit.Microsoft Scrum KitMicrosoft Scrum Kit[5] includes Excel templates for product backlog, sprint backlog, burndowntracking and various charts, which give visual representation of project status for consumption ofmanagement. 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 columnscorresponding to each day in sprint. Team member has to record time spent and time left on eachwork item every day. This data is used to compute all required graphs and charts to report projectstatus.Analysis: Analysis tab provides view what is to be discussed in Daily Stand up meetings. It gives viewof Not Started, In Progress and Completed work items. It gives idea to team if they are laggingbehind. It also shows burn down chart. Burn down Chart[4] Page 15 Agile Adoption Readiness Framework
  16. 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 andhelp plan better to achieve higher predictability in future. It also records member comments on WhatWent Well and Areas of Improvement.References1. 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.com6. 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. 17. Chapter 3: eXtreme Programming Chapter 3: eXtreme ProgrammingIn this chapter… XP framework XP practices XP team XP artifactsIntroductionExtreme Programming (hereafter referred as XP) is a type of agile softwaredevelopment technique focused on improving software quality while increasingresponsiveness to changing customer requirements. Contrary to popular claim insoftware industry, XP claims “It’s possible to keep the cost of changing software fromrising dramatically with time.” [1] It is one of the methods that focus on customerdelivering what and when customer wants.The methodology takes agile programming one step nearer to lean techniques byemphasizing on Just In Time (JIT), i.e. build software features only when they arerequired and not in advance, to reduce uncertainty of changing requirements. This ofcourse, 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. 18. Chapter 3: eXtreme ProgrammingBasic VariablesXP 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 despitechange in other, remaining two variables will need to make sacrifice. E.g. If scope increases anddelivery date i.e. time needs to be kept constant, then naturally either resources or quality or bothneed to take the heat.XP suggests that agree on acceptable level of quality with customer and management. During theduration keep time unit and resources fixed. Hence, only variable tha t remains is the scope. What andwhen will be decided by customer. Team will deliver on that.Extreme Programming ValuesThe 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 TeamFollowing are core and supplementary roles in Extreme Programming methodology. [1]Core RolesThe CustomerThe XP recognizes rights of customer to (1) Ensure ROI maximization (2) Change the project scope todeal with schedule change (3) To determine and alter feature prioritization (4) Measure progress ofproject 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 clearstories and (5) Work in team providing guidelines and receive feedback.The DeveloperThe 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 isnecessary and (3) Communicate constantly with customer. Page 18 Agile Adoption Readiness Framework
  19. 19. Chapter 3: eXtreme ProgrammingSupplementary RolesThe CoachThe coach is an expert from whose example team learns. By virtue of experience, he provides hiswisdom to guide team through occasional obstacles and subtleties.The TrackerThe 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 ProcessRules of Extreme ProgrammingExtreme Programming methodology defines basic rules for 5 stages of development. They are asfollows: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.htmlProject Life CycleBelow self-explanatory diagram shows end-to-end release cycle of an XP project. [2]Figure 4 Extreme Programming Project; Source: extremeprogramming.orgSpike solution is implemented when a tough technical problem is encountered and solved by puttingpair of developers who are dedicated to solve that problem ignoring all other concerns. Page 19 Agile Adoption Readiness Framework
  20. 20. Chapter 3: eXtreme ProgrammingIterative DevelopmentFollowing 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 inthis iteration. [2]Figure 5 An Iteration; Source: extremeprogramming.orgPair ProgrammingIn Pair programming technique, two programmers work together on single piece of code or moduleon 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_programmingLogically, this method doubles the cost of development and various experiments have yieldedcontradictory results. However, Microsoft Research’s Andrew Begel and Nachiappan Nagappan [4]conclude based on survey conducted among Microsoft developers that benefits of pair programmingoutweigh the cost and other disadvantages. Key benefits are listed as bug reduction, shorter qualitycode which is more maintainable.Test Driven DevelopmentXP 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 akthe 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. 21. Chapter 3: eXtreme ProgrammingXP artifactsCore XP does not prescribe any documentation but the code itself. It asks code to be self-explanatoryand 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 ofthem.User Story CardsThese are tools of customer to specify what, how and when he wants the deliverable. Advantage ofcards is that they help developers visualize and organize each story easily. They can be put up on wall.Task BoardDuring planning of iteration, user stories are translated to task cards, which are given to programmerto whom the task is assigned. These task cards are put up on task board in different phases. Anyonelooking 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 SoftwareReferences1. 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. 22. Chapter 4: Lean Agile Chapter 4: Lean AgileIn this chapter… Lean Principles Kanban in Software Kanban Practices Milestones and MeetingsIntroductionAdapted from Toyota Production Systems, Lean Agile is the translation of Leanmanufacturing principles into field of software development. The term originated inbook Lean Software development written by Poppendieck Mary & Tom.Enterprise AgilityAgile process applied in Scrum or XP focusses largely on software developmentproject. But latest trend in agility is to look at entire value stream, stream of deliveredsoftware flowing from delivering organization to customer or consumers of solutions,driven by business need.[1] Enterprise Agility focusses on applying lean principles ofminimizing cycle time, eliminating waste in this end-to-end delivery flow.Below diagram depicts scope of Scrum/Agile vs. Lean/Agile on organization’s valuechain. [1]Figure 8 Application of Agile methods on value chain, Source: Alan Shalloway - Lean/Agile Page 22 Agile Adoption Readiness Framework
  23. 23. Chapter 4: Lean AgileNecessity of adopting Lean principlesVarious implementations of Scrum and/or XP across organizations resulted in some commonproblems over period of time. As Frank Vega [3] shares his experience, these are – (1) Business need tointegrate and collaborate in various applications, however various team operate in silos, (2) Overperiod of time long backlog gets generated due to starvation of secondary items and (3) Velocity ofteam fluctuates based on technical complexity, hence predictability becomes an issue.Principles of Lean DevelopmentThe borrowing of Lean principles from TPS tries to address these problems. As described byPoppendiecks, 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 KanbanWhat is Kanban?TPS [5] defines Kanban as signal of some kind e.g. sign, card, billboard, poster etc. Toyota’s Kanbansystem means managing and ensuring flow and production of materials in just-in-time productionsystem. What this means is process flows are controlled through completion signal by preceding andsuccessive stages based on their availabilities statuses. This means overheads like complexcomputerized 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/KanbanPull Replenishment SystemDo you fill gas in your car prescribing to some schedule decided in advance? No. You f ill it once theindicator on your car’s dashboard approaches empty. In simple words, this is Kanban or simple pullreplenishment system.In Toyota plant, which manufactures automobiles, which is essentially a very large scale assemblyproject of thousands of part. Typical stakeholders include suppliers, workers and dealers. Dealersbased on demand in market place orders to plant by placing kanban order cards. While such cardsexist in order boards, Toyota workers continue to build cars of those types. For particular car, theystart using spare parts to be assembled from stores. As they use parts, they place kanban ordersupplies card in mailbox to supplier. As supplier receives such kanban card, he refills those stores with Page 23 Agile Adoption Readiness Framework
  24. 24. Chapter 4: Lean Agilespare parts. As explained, whole system works end-to-end on trigger points and not on pre-decidedschedule.Kanban in SoftwareDavid Anderson [2] defines Kanban in software as “virtual” system. The signal cards are replaced bywork items. There are no physical signal cards to function as signal to pull more work. Signal to pullmore work is inferred from visual quantity of work-in-progress subtracted from capacity (limit) at eachstage in development.Kanban ProcessThere are many flavors of kanban process. But following objectives exist a t core.Visualize the workflowThe card wall is the most popular form of coordination. Each stage is marked as column with limitwritten on top. Work items are marked as “Ongoing” or “Done” in that particular stage. If there is anycapacity available (capacity – Ongoing is positive), card (work item) from previous stage’s “Done” willmove into next stage. There are no other long queues waiting due to starvation. Priority will beapplied while moving card to next level. [6] Figure 9 Kanban card wall. Source: crisp.Limit Work In ProgressWorking simultaneously on multiple work items especially in software development, reducesefficiency and is error prone, due to context switches. Kanban believes in reducing this by puttingstrict limits as indicated in above figure. Anderson [2] insists on limiting one request per developer atany given time as a policy. Kanban, however, allows flexibility to alter this if team agrees.Cycle Time measurementCycle time or lead time measures how quickly item moved from order to production. This is criticalmetric from predictability point of view. Graphs are plotted for lead time against Service LevelAgreements (SLA). Average Lead time is not very useful as it neither indicates predictability norimprovement opportunity. Spectral analysis is done to identify outliers and items that just failed to Page 24 Agile Adoption Readiness Framework
  25. 25. Chapter 4: Lean Agilemeet the target. Root cause analysis of cluster of such “just failed” category provides improvementopportunity.Kaizen – Continuous ImprovementKaizen demands workforce to be empowered and motivated to dig deep into problems, discussoptions 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 arerequired. 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 tofoster culture of ownership.Key Milestones and MeetingsReplenishment During this meeting, kanban system’s empty queues are replenished atMeeting 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 atMeetings 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 - KanbanReferences1. 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. 26. Chapter 4: Lean Agile3. 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. 27. Chapter 5: Software Design Chapter 5: Software DesignIn this chapter… OO Design and Design Patterns Unit testing Refactoring Old Code Architectural StrategyIntroductionIn 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 ofpriorities of developers, technical soundness and organizational trainings on softwaredesign process. We will look at how the Object Orientated Languages proved to beboon for agile development and how design patterns helped achieve objectives ofmanaging change. We will also look at how code should be maintained throughrefactoring in order to be more agile.Priorities while CodingWhat is important? Is it the number of lines of code or is it the performance or thecosmetics like comments and naming conventions? The organizations all over theworld 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 acceptchange.Maintainability vs. PerformanceIt is widely considered that a design is a tradeoff of Performance vs. Maintainability. Ahigh performing code is perceived to be difficult to understand, hence hard tomaintain. This is true to certain extent. With advent of high computing and memoryhardware, in typical IT setup, the performance need not be achieved at cost ofmaintainability. A well written, self-explanatory and modular code is basic necessity foragile adoption. Maintainable code is the one which is easy to understand, analyze andmodify by person other than author. Page 27 Agile Adoption Readiness Framework
  28. 28. Chapter 5: Software DesignNew Lines of Code vs. ReusabilityMethodologies 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. Asdevelopers try to maximize lines of code in order to inflate their estimates, they also get license formore defects. These both are in contrast with the Agile principles. Organizations should not mandatetheir LOC based measures for agile teams.Reusability is likelihood that already written, time-tested piece of code can be reused in the newsoftware. This requires code organization in modules or classes. These are unit tested and preservedin repository. Developers requiring similar functionality can reuse or extend these. This saves time andimproves maintainability and quality of code.Object Oriented DesignObject Oriented DesignObject oriented programming is a programming paradigm using objects which are data structuresconsisting 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+OrientedLet’s look at four major principles of Object Oriented Design and how they ease Agile adoptionprocess.Principle DescriptionEncapsulation 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 rightSimply having knowledge of Object Oriented Programming is not sufficient. The design processshould reflect the object oriented thought process. If designs prepared fail to address changes infuture, developers have tendency to patch the design as workaround. The system with suchpatchworks, very common in IT systems today defeats the Object orientation purpose and becomes Page 28 Agile Adoption Readiness Framework
  29. 29. Chapter 5: Software Design [8]critical issue in agile adoptions. Stoecklin et al defines strict criteria for writing well formed OOmethod 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 PatternsDesign patterns are reusable designs based mainly on Object Oriented concepts which are genericsolutions to many common problems. Modern patterns were introduced by “Gang of Four” throughtheir legendary book [2], which is authority on this topic today. Some of popular patterns includesingleton, 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=5127Alan Shalloway [3] strongly argues that Design Patterns form foundation for Agile Development if usedproperly. As Mikio Aoyama [4] also agrees, we can identify key benefits of Design patterns as – (1) Itmakes software design “Change Resistant”. What it means is that as requirements change, the designis impacted minimally as there are no ripple effects of change in design through strict adherence toObject oriented features described in above section. (2) Designs are developed faster. Several designpatterns are generic solutions to common problems. These are time tested. Use of patterns save timeto find logical solutions and improve quality. (3) It also increases maintainability of the program aspatterns are standard. (4) Learning design patterns help shape developers design skills and thinkingpositively for agile adoption. They do not hate changes as most can be accommodated with minimaldesign impact.Unified Modeling LanguageUnified Modeling Language, popularly called UML, is standardized general purpose language whic hrepresents 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 maintainingup-to-date knowledge base of designs is UML diagrams. Some key advantages are: (1) Developers aretrained to read these standard diagrams. So, no additional explanations are needed. (2) They are mostconcise way of representing almost all issues regarding design. (3) Most of these diagrams can beauto-generated from code. Hence, developers need not actually create them. That also ensuresdiagrams are always up-to-date. (4) Sometimes code also can be generated directly from thesediagrams. E.g. Class definitions and function signatures are directly generated by most IDEs from UMLclass diagram. Page 29 Agile Adoption Readiness Framework
  30. 30. Chapter 5: Software DesignUnit TestingIEEE [6] defines Unit Testing as testing of individual hardware or software units or groups of relatedunits. This is a type of White Box testing, i.e. the tester is aware of intricacies of the unit and is testingusing interfaces to validate them.Test Driven DevelopmentThe Extreme Programming requires developers to write their automated unit tests first and then writecode modules that satisfy those cases. Developers refactor the code later to prescribed standardswhile ensuring that unit tests continue to pass. Since, this requires repeated running of same unittests, the automation is recommended.Technical SpecificationsAlthough not widely accepted, Agile methodology can consider well developed unit test suite asalternative to technical documentation. This requires structuring of unit tests based on broken downevents from user stories. And then unit test suite in combination with UML diagrams can substitutetedious task of developing technical documentation sand maintaining these current during iterativedevelopment cycle. Extreme Programming with Test Driven Development approach favors this.Refactoring Old CodeThe developers don’t always work on new code. A major part of their work is modification orextension. The structure of old code has large impact on the performance of agile teams. Acrossorganizations, 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 defectsand delays.Refactoring is the activity of restructuring old code to follow Object oriented or design patternguidelines, without altering its external functionality. Modular structures and automated unit tests aredeveloped. As refactoring course tutor, Yoder [7] says, refactoring is the disciplined approach and addsimportance of regression testing. Refactoring can be considered as software equivalent of leanprinciple “kaizen”.Resistance from BusinessBusiness owners and sponsors often see code refactoring initiatives as waste of resources. Refactoringdoes not alter any business functionality. Hence, it does not yield any tangible benefit for them. Manyeven see this activity as developer’s obsession for cleaner code [9]. This is where the role of productowners who represent business sponsors of project is important. Being part of team they have highervisibility into success factors of agile processes. And from sustainability point of view, the refactoringactivities must be viewed as investments rather than expenses. Also, business may fear that newdefects may be introduced as a result of refactoring activity. Hence, a comprehensive regression andunit testing suite must be ready before venturing into refactoring space. Page 30 Agile Adoption Readiness Framework
  31. 31. Chapter 5: Software DesignRefactoring TypesClassic Fowlerian ApproachAs described by Stoecklin [8], in this approach a working code is improved for clarity and designquality.Open Close PrincipleMeyer [11] defines Open Close Principle as “software entities (classes, modules, functions, etc.) shouldbe open for extension, but closed for modification”. Bain [9] applies it to code as the code which ismore 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 itundergoes imminent change. In this way, business value can be derived from the refactoring.Emergent DesignEmergent or continuous or evolutionary design is a process of continuous refactoring resulting inimprovement 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) ContinuousImprovement commitment in face of schedule pressure. He cautions however not to mix it withdesign 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, theyscrapped pre-designed database and instead worked on incremental design. This allowed them touse their evolving domain skills to come up with more efficient design than they would have atbeginning with limited skills and domain knowledge.Architectural StrategyThere is ongoing debate on role of architects in agile development setting. This is due to highlyrequirement oriented nature of agile processes. XP and Kanban methods even perform the changeonly when it is necessary. On other hand, enterprise architecture focusses on large picture and takeslong term view through roadmaps. While it is perceived that Agile methods take more short termview to avoid impact of changes.Cisco’s Steve Fraser [10] says in order to capture benefits of economics of scale and scope, architectureis necessary. The feedback loop of Agile development can be integrated with Architectural learningand both processes can work hand-in-hand. Microsoft’s Randy Miller [10] argues that Architecture isnot “Big Design Up Front” as many developers confuse the two. Hence, it is not necessary forarchitecture to complete before development starts. Architecture is slow evolving process like agiledevelopment is. However, it takes view of larger picture and is beneficial to both small as well as largescale projects.From organization setting, Agile demands Architecture to work closely with Agile teams and ensureteams are developing aligned to enterprise architecture roadmap. But such architecture must not beat micro-level. Clear demarcation between architecture and design needs to be highlighted. Page 31 Agile Adoption Readiness Framework
  32. 32. Chapter 5: Software DesignReferences1. 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. 33. Chapter 6: Business Processes Chapter 6: Business ProcessesIn this chapter… Customer Function vs. Process orientation Business IT alignment Service Oriented ArchitectureIntroductionAgile process adoption requires a mindset than just skills. In business context, agilitymeans capability of organization to readily adapt to changes in market andenvironmental changes in productive and cost-effective ways. But in practical there arevery few examples of truly agile organizations. Most organizations, in which agiledevelopment projects will be undertaken, are themselves highly bureaucratic andhierarchical. They will be resistant to change. This situation actually becomes hinderingfactor for truly agile process on IT side as agile processes demand IT to have closeinteraction with business throughout lifecycle of project.Today, a lot of businesses worldwide are undergoing transformations. This is due tolarger adoption of IT, Management Information Systems, Analytics, Enterprise ResourcePlanning (ERP) and Customer Relationship Management (CRM) like initiatives, whichgive them competitive advantage over their rivals. Businesses have also realized thatunless they are dynamic, they will perish. However, they are at different stages oftransformation. It also should be noted that IT teams (organization of CIO) have limitedcontrol on modifications in business processes to make them suitable for IT adoption.It is therefore imperative for IT managers to take pragmatic approach when situationresults in business processes limiting agile adoption.In this chapter, we will look at various drivers of agility in business environment andhow 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. 34. Chapter 6: Business ProcessesCustomerLet’s first define who is customer for IT. ITIL [3] defines customer as someone who buys goods orServices. The Customer of an IT Service Provider is the person or group who defines and agrees to theService Level Targets. The term Customers is also sometimes informally used to mean Users.Customer InvolvementAgile 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 facecommunication with developers. In XP, customer activities include (1) Creating customer team torepresent requirements (2) Provide development environment (3) Review project plan (4) Feedback (5)Requirement management (6) Consult throughout (7) Testing and demonstrations (8) Acceptingworking 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 closecollaboration beyond standard definition of roles of customers and developers is needed in order topromote 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 unproductiveactivity. This comes due to traditional mindset on IT (waterfall model). Though IT teams are goingagile, most business processes still follow sequential waterfall model. Participation in agile processesis additional burden for customers. Especially during peak business cycles like quarter close, they willnot prioritize time for developers. This impacts agile process.Requirements Gaps: It’s difficult for customers to think of all scenarios in requirement phase. Theycan’t visualize IT outputs. Only during testing or demonstrations, they realize certain pitfalls and wantto amend their user stories. This requires recoding those modules ultimately impacting Developerteams.Training: Sometimes customers are enthusiastic about interacting with developers but then theyshould 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 dataand data flows. In test environment, end-to-end data generation is not mostly possible. Also, for agileiterative releases, the focus is more on testing individual modules. Since, business customers are notacquainted to such unit testing; they can’t perform exhaustive scenarios during test phase. All suchissues get leaked to the production.Communication: Customers and development teams sometimes do not communicate each othertransparently or on time. This is especially true for bad news or delays. Page 34 Agile Adoption Readiness Framework
  35. 35. Chapter 6: Business ProcessesFunction vs. Process OrientationAs Majchrzak defines [4], functional units are those which have limited responsibility specific to theirfunction. These units are largely dependent on one or more units for performing upstream anddownstream tasks. While process complete units are defined as those units which control larger valuechain 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 dueto reduction in effort of aggregating efforts of autonomous units. When agile processes likeLean/Kanban are to be implemented, the transformation can’t be li mited to IT organization. Asalready explained in chapter on kanban, the business processes must be reengineered for suchtransformation. Otherwise, agile adoption of kanban will not be able to produce desired results.Functional MindsetMajchrzak [4] also argues that just implementing process completeness through integrations inresponsibilities is not sufficient. The employees and managers need to develop mindset that isprocess complete and not functional i.e. think about larger picture and beyond the team. It increasesorganizational focus on collaboration, helps reduce bureaucratic approach. It also helps developcommon goals for front-end and back-end employees which are more closely aligned to businessgoals.In terms of Agile software development, this approach helps as agile demands customer focus andlarger 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 andmiscellaneous organizations like schools, NGOs and hospitals. Most of these o rganizations havededicated IT teams of varying size. Information refers to the business data that is generated, sharedand churned by IT systems as part of various business processes. Applications refer to variousplatforms, UIs and tools that help business users and customers to carry out their operations. Manyapplications may act at different stage in data pipeline.For faster agile development cycles, the alignment of various teams in IT organization must be withcorresponding business units from operations. However, IT needs to account for shared dependenciesin terms of application platforms and data. For e. g. a customer may be enrolled for two different Page 35 Agile Adoption Readiness Framework
  36. 36. Chapter 6: Business Processesbusinesses with same firm. However, if corresponding IT units operate in silos, customer will nee d tomanage two separate accounts with the firm, which increases redundancy in data and costs for thecompany.ERP integration – a driver for changeMost organizational structures underwent changes once they embraced ERP. ERP aggregatesinformation spread across organizations. This highlights redundancies and inefficiencies in theorganization structures. For obtaining true ROI out of ERP integration and gain competitiveadvantage, the businesses have to realign themselves. ERP integration creates efficient Business-ITorganization structure. Such structure favors adoption of agile development processes by ITorganizations.Types of AlignmentChen defines Business-IT alignment is of following types –Alignment by ArchitectureThis alignment is mostly driven by Enterprise Architecture team which provides cross-functional andcross-discipline collaboration to deliver complex business processes. This ensures application andinformation systems are designed along with data flows in order to eliminate redundancy costs.Alignment by GovernanceIT Service management works on value propositions and aligning business-IT operations. Delivery,performance, risks and resource management is aligned across Business and IT. Regulatorycompliances are ensured and IT audit handles managerial control.Alignment by CommunicationThe communication gap between customer and developers exists due to cultural gaps. In thismethod, 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 agiledevelopment process point of view, for techniques like scrum and XP, a communication alignment issufficient as minimum condition. But, if organization is aiming for Lean/Kanban implementation, thenit needs to achieve governance alignment as basic minimum. In the long run, architectural roadmapshould 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 toexpose to its customers or partners or other portions of organization. The SOA appro ach fororganizational functioning gives interoperability, flexibility, transparency, cost-effectiveness andinnovation. Following diagram depicts the architecture proposed by Chen [8]. For detailed informationon various features of schematic, refer to the paper. Page 36 Agile Adoption Readiness Framework
  37. 37. Chapter 6: Business Processes [8]Figure 11 Chens IT Alignment with SOA schematicImplications for Agile DevelopmentThe 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.References1. 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. 38. Chapter 6: Business Processes4. 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, 20087. 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. 39. Chapter 7: HR Practices Chapter 7: HR PracticesIn this chapter… Recruitment Performance Management Trainings HR policiesIntroductionSoftware organizations aiming adoption of agile methods for large projects needholistic transformation. Vital change is required in firm’s Human Resource practices. AsDavid 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 managersof knowledge workers in order to create motivated, productive and innovative workenvironment.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 themToyota grows leaders internally as they live in firm for longer time and understands itsday to day culture thoroughly i.e. genchi genbutsu, means deeply observing actualsituation.Develop excellence in individual work while promoting effective team workToyota puts tremendous time in hiring right candidates as it focusses on effective teamwork 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, performancemanagement, trainings and other HR policies impact on adoption of agile processes. Page 39 Agile Adoption Readiness Framework
  40. 40. Chapter 7: HR Practices [2] Figure 12 Crocitto, Youssef Model of organizational agilityRecruitmentThe recruitment policies of the firm are responsible for bringing right talent required for agileadoptions.Workplace DiversityAs Andrea Tapia [4] mentions, IT industry faced a sudden explosive growth during .com bubble. Thegold rush of hiring talent resulted in homogeneous employee population with followingcharacteristics.(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 behemothshave agreed in recent past to transform their processes to correct this situation, most initiativeshave 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 culturepredominant in Software organizations. Any work organization must be representative of thepopulation from which it is derived. No company survives on “template” employees. Especially agileadoption requires multitalented and dynamic employees at workplace. The diversity of hiring in termsof gender, race, religion, age, culture, color, physical abilities and sexual orientation is imminent for ITorganizations. Page 40 Agile Adoption Readiness Framework
  41. 41. Chapter 7: HR PracticesDesired CompetenciesAs explained with Toyota’s principles, individual excellence and effective team work are of utmostimportance while hiring employees for agile development teams. Below table highlights whatcompetencies are needed from collective agile team. Every member need not or can’t have all ofthem and hence diversity at workplace is needed. It also highlights competencies of manager andminimum competencies of individual members required for effective agile adoption.Agile Team’s Collective Competencies Agile Team Managers’ Competencies1. Required Technical Skills 12. Innovation Management2. Required Business Knowledge 13. Fostering Diversity*3. Customer Focus* 14. Understanding Company Culture*4. Dealing with Ambiguity 15. Develop and Grow People5. Problem Solving6. Creativity Agile Team Members’ Individual7. Respecting Differences Competencies8. Positive Conflict9. Change Management 16. Communication Skills10. Decision Making 17. Interpersonal Skills/Team Skills11. Collective Ownership 18. Integrity and Trustworthiness 19. Accomplishment Orientation or passion* also, Agile Leadership Qualities 20. One or more of the collective competenciesIn one way, software teams differ from lean manufacturing is, lean manufacturing relies onstandardization of tasks for improving productivity of employees. This is not true for software as thereare no standardized tasks that a developer does over period of time. Developers improve productivitythrough varying experiences, developing strong problem solving skills.Staffing levelsAs explained in lean principles and extreme programming principles, agile teams adjust change in onevariable by making change in other variables from time, scope, resource, quality [5]. As described incase study on Menlo [6], overtime is strict NO for agile teams. This means, agile teams need to increaseresources 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 serviceorganizations? No, that is inefficiency. As evident from the case of Menlo [6], it means building a highlymobile workforce. This means based on requirement resources should be both increased ordecreased from given agile team on weekly basis. This requires separation of functional and technicalskills. Assign workforce on skill basis to various projects. The members switch between projects basedon 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. 42. Chapter 7: HR PracticesPerformance ManagementReview ProcessPeer ReviewAgile emphasizes on team performance. Hence, individual’s performance review should comprise offeedback from team members. Some companies follow anonymous feedback or in some feedbacksare 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 beaware of what each of his peer thinks about him. Google [8] even conducts performance reviewinterviews with peers.Review CyclesThere should be at least two (ideally 3-4) performance review cycles, as this gives ample opportunitiesto employees to correct his shortcomings. Google [8] conducts two such official cycles, but alsoremains open for any feedback/review sessions anytime in the year. As per continuous improvementprinciple of agile, frequent review cycles are desirable.CompensationSalary and Performance BonusA competitive base salary (fixed) which translates into monthly pay, followed by performance linkedcash 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 marketconditions. Some companies provide merit increments based on performance even withoutpromotions. Some companies like Google [8] factor employee performance and company performanceas multiplier in determining increments.For effective agile adoption, team work needs to be rewarded. As evident in Menlo’s example [6], theperformance bonus and increments should factor the team performance as additional component.This creates motivating environment for individual excellence with effective team work.Stock OptionsPublic listed firms reward performance of their employees by awarding stock options. Somecompanies provide Employee Stock Options (ESOPs) or some provide Stock Awards. This is paycomponent linked to overall performance of the firm in the market. Though individual’s work hashardly any relation to stock performance, it helps in creating sense of collective ownership in theemployees. Companies like Microsoft [7] award stocks which mature over stipulated period, whichhelps it retain employees for longer period and reduce turnover. Page 42 Agile Adoption Readiness Framework

×