Can Agile Work for this Project?


Published on

To be sure you can succesfully use the Agile methodology on your next software development project, simply ask yourself these four important questions.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Can Agile Work for this Project?

  1. 1. • Cognizant 20-20 InsightsCan Agile Work for This Project? Executive Summary given project. If we find that we are struggling with coming up with answers for these questions, One of the four pillars of the “Manifesto for Agile then we probably need to spend a little more time Software Development”1 is that “we have come thinking through how we would apply Agile before to value… working software over comprehensive we move forward with the decision to use it on documentation.” In reality, we are saying that that given project. we value working systems as opposed to merely limiting ourselves to only delivering working What Do Our User Stories Look Like? software. Most of the very large and complex projects we deliver are really as much about The first question we should be asking is: What integrating systems together as they are about is our concept of a user story? Are we describing building new bespoke software applications. But user interactions with a system; are we describing do all of these different flavors of projects lend a feature; or are we describing a component? What themselves towards using Agile? This is a question other types of artifacts will we need to produce that is on the minds of many decision makers in to augment the user story? At the same time, we the field of information technology these days. also need to keep in mind the Agile Manifesto, and remind ourselves that we value working Many organizations have already adopted Agile systems over comprehensive documentation. So as the primary software development methodolo- we don’t want to go overboard, but instead find gy for custom building new applications. However, that balance of how much documentation is the many of the projects that are undertaken by infor- “sweet spot” for building working systems. mation technology organizations don’t fit neatly into the paradigm of a brand-new application. IT How Will We Sequence Our Backlog? projects come in many sizes, shapes and flavors. The second question is: What criteria are we going Based on our experience virtually all of them can to use to determine the order of user stories on be successfully done using Agile, but we need the product backlog? Can we attach some sort to be smart about it and make sure we carefully of monetary value to the user story and thereby think through how we would adopt Agile for these order the more valuable stories to the top and different patterns of project types. the less valuable to the bottom? Should we be prioritizing the stories based on architectural Before we can say definitively that a given uncertainty or complexity, or whether they are project can be done in Agile, we need to look at foundational stories that later stories on the answering four important questions. If we are backlog are inherently dependent upon? Or in the able to answer these four questions with well- example of a project where the solution is more thought-out responses then we would be fairly about standing up a new commercial off-the-shelf assured we could have success with Agile for a cognizant 20-20 insights | december 2011
  2. 2. (COTS) application, perhaps what goes onto the immaterial when we are trying to answer the fourbacklog is a sequenced set of configuration tasks big questions. Moreover, the way in which a giventhat need to be done in a particular order. organization would answer those questions will probably have the least variability from organiza-How Will We Partition Tasks? tion to organization in this example. For the sakeThe third question we should be asking is: Can of this example, let’s assume we are talking aboutwe partition the user stories into sets of tasks a software company that makes online bankingthat the Scrum team can perform within a Sprint software using a fairly traditional implementationto deliver some sort of “potentially shippable” of Scrum.product that can be demonstrated to the productowner? Perhaps these tasks are the typical set User stories will most likely look like the classicof tasks you would expect to see in a traditional 3x5 card that describes who the actor is, whatproject where you are building a new applica- they are trying to accomplish and how we willtion: perform design, coding and unit test, build know if we have successfully accomplished it. Itand integration. Perhaps the tasks are a different would resemble something like, “As a customer, Iset of tasks due to the nature of the project we want to be able to see my last thirty days of trans-are performing, such as configuration tasks, actions on my account so that I can reconcile mydata reengineering activities such as extract, checkbook.”transform and load or perhaps they are tasks that The set of user stories would most likely be orderedwould be performed while using a 3GL or CASE numerically with an absolute ranking on thetool to generate code. product backlog by the product manager. It would then be the product manager’s responsibility toWhat Is Our Definition of Done? come up with the rationale for how the ranking isThe fourth and final question is: How will we know performed. In some organizations, some sort ofwe are done with the user story? That is to say, monetary value would be placed on the user storyhow do we know when we have something that is (for example, some user stories might be related“potentially shippable”? How are we going to test to a new product feature that would allow us towhat we are delivering? Are we going to use test- sell our product to new customers and createdriven development (TDD)? Are we going to have incremental revenue). Another possibility is thata separate bifurcated testing team downstream the product manager might rank stories based onof the Scrum team to certify the product coming how many end customers have requested a givenout of the Sprints before it is actually shipped feature or customers? These are important questions toconsider when deciding how we are going to test Partitioning the story into tasks is also a prettyour stories. straightforward exercise, wherein there might be some tasks oriented around creating technicalFor any given IT project, if we are able to come stories. These would be performed in the earlyup with a well-reasoned set of answers to all part of the iteration/Sprint, then there would befour of these major questions, then we can feel coding and unit testing tasks, and then finallyreasonably assured that choosing Agile for that some acceptance and validation tasks.specific project was a good decision and thatthere is not a particular nuance that prohibits the Lastly, it would most likely be a responsibility ofuse of Agile. Now let’s reinforce this by looking the product manager to answer the question,at some common examples of archetype patterns “are we done?” The user stories would likely haveof information technology projects that probably some acceptance criteria that can be used tolook pretty similar to some projects on your road make that determination, and when the productmap or portfolios. Then we’ll discuss how we manager accepts the story and it is shown in thewould answer these four questions for each of demo then the story would be considered “poten-those patterns. tially shippable.” It would then ship during the next scheduled release.Custom-built/BespokeThe green field project where we are building Package Implementation/ERPa brand new bespoke application from scratch Package implementations and enterprise resourceis the most classic example of a project well planning (ERP) are other common patterns of ITsuited for Agile. Whether the skill set is Java, projects. But how would we go about answering.NET or a legacy mainframe technology is almost the four big questions in this type of example? cognizant 20-20 insights 2
  3. 3. Let’s assume we are talking about an organiza- implementation have been delivered against thetion that is migrating from a set of home-grown acceptance criteria and are now “potentiallyorder management and fulfillment applications shippable.”to a commercial off-the-shelf (COTS) package.It’s likely that most of the user stories would Data Warehouse/Business Intelligenceresemble the types of user stories from the Data Warehousing and BI projects are an interest-first example; they would describe interactions ing example. These projects tend to be complex,between end users and the system, explain what very large and long in duration. They also tend tobusiness function they are trying to perform and be very discovery driven especially as it relatesdescribe some sort of acceptance criteria that to data cleansing and extract, transform andtell us when that functionality or capability has load (ETL). In addition to having a considerablebeen provided. amount of effort relating to ETL, there is usually some sort of analytical tool or reporting packageHowever, the role of the product manager and that is implemented. In general, we could treatthe way in which user stories are sequenced on the standing up and configuring of the reportingthe backlog are both likely to be different in this package as being analogous to the package/example. Instead of some sort of ranking based ERP project pattern which we have alreadyon value or desirability of a feature, it is more discussed. So let’s focus the discussion on how tolikely that there are certain core modules within do data conversion and data migration projectsthe target package that have to be stood up and using Agile.configured first before other parts of the ERPpackage can work. For example, you need to set ETL projects can be done using a variety ofup and load the product module before you can technologies and tools, some involving customstart setting up and configuring the order entry coding, legacy and more modern programmingapplications, so the stories might get ordered languages and ETL tools. What they have inbased on these dependencies and would look common, though, is moving and synchronizingsomething like a critical path schedule. data from a source to a target, and performing transformations on the data. Sometimes we areThe tasks that the delivery team would perform going from source systems to an operational datawould also be different from the traditional store (ODS). Sometimes we are loading large datacustom application development tasks of design, warehouses, and sometimes we are extractingcoding and unit testing. A lot of the technical from data warehouses and loading data performed is more oriented around con-figuration as opposed to software development. User stories in this example would probably lookBut all that means is that we would partition the dramatically different than user stories fromstory into a different set of tasks that are more in a custom application development project. Wetune with the type of technical work that would are less likely to be describing the way an actorbe performed. Perhaps the story would be parti- interacts with a software application. Rather,tioned into a set of tasks such as “configure hier- we are likely describing an extraction routinearchies,” “customize business rules” and “validate that needs to pull data from a source system, orfunctionality in the user interface.” describing business rules that need to be applied to data to transform it into the target schema.It is likely that the acceptance criteria on thestories will be similar to acceptance criteria on We may need to give some careful thought on whouser stories for projects where we are custom is going to play the role of the product managerbuilding. The stories would describe a working and how that person would prioritize the storiesfunctionality where an end user is able to perform on the backlog for the development team. Onesome important business-oriented task such as approach could be that the data architect whoentering an order. The acceptance criteria would designed the target schema could play that role.explain some sort of evaluation criteria that Also, the sequencing of the backlog could be basedwould describe how we would know when we are on the chain of inheritance in the data model. Thatsuccessful. Therefore the product manager could is to say, the early stories on the backlog might beplay a similar role of formally accepting the stories related to extracting and loading the primary keysand then having them demonstrated at the end of and identifying data of base stand-alone entitiesa Sprint. So, much like in the bespoke example, such as customer, location and product. Then thethe product manager would be the gatekeeper middle priority stories might end up being aboutdetermining which parts of the overall package ETL routines dealing with the one-to-many and cognizant 20-20 insights 3
  4. 4. many-to-many relationships like sale and sale Application Value Maintenanceitem. And then the latest stories might be about Application value maintenance (AVM) projectspopulating important but ancillary data elements are usually ongoing and about making minoron the tables in the data warehouse. enhancements and making rapid break-fixes to aAlso, if the project is about both loading a data mature application on the right hand side of thewarehouse and data marts, the early sets of product lifecycle.stories would likely be about going from source The user stories are likely to be very simple,systems to the warehouse and the later stories sometimes being as straightforward as a defectmight be about populating downstream data or customer issue logged in a quality tool.marts used by analytical tools. Some sort of algorithm based on priority andPartitioning user stories into development tasks severity is probably going to be used to determinewill also be a challenge. Many times in these types the sequence of the issues on the defect backlog.of projects the work that is done is very discovery Sometimes when it’s about customer issuesdriven. Frequently, the quality of the data itself is we could use a first in first out (FIFO) approachan unknown. One approach to try would be to have to sequencing. Or perhaps depending on theone story about doing the 80% of the customer particular customer there are different servicerecords and then having developers use ETL tools level agreements (SLA) that dictate the an early Sprint to do the 80% accepting thefact that the first time through the gate we might Because time is usually of the essence, we mayhave a considerable amount of data that is fallout want to have the partitioning of stories be asbecause of unexpected data issues. Then in a simple as possible — basically, just get it done.second trailing Sprint the developers would tackle Whatever developer is now free takes the nextthe 20% that required separate special treatment item off the backlog, works it to completion, marksbecause of more complex business rules that it ready for test and then immediately moves towould need to be identified in other user stories. the next item. No Sprints, no demos. In fact, this sounds a bit like Kanban, as lean as we can be.Answering the questions about when we are doneis also a challenge. One way to look at it would be Then it would usually be up to some quality orga-to have two levels of “doneness.” One early grade nization to make the call on whether the issuewhen the data in the warehouse is now usable and has been resolved and can be moved to a closedcomplete enough that we can make good business status, or whether the issue persists and needs todecisions based on how the data is flowing into go back to the top of the backlog.the data marts. Perhaps after 80% of the salesdata is flowing cleanly we can use that incomplete Deciding on Agileset to still make pretty reliable product marketing Coming up with thoughtful well reasoned answersdecisions. Then when the data quality hits the to these questions is certainly not a guaranteehigher grade later on we can strive closer towards that we will have success with Agile. There are99% to 100% quality. This may be a challenge many other dimensions we need to assess, suchbased on what types of business decisions are as learning and maturity, organizational culturalbeing made with the information coming out of fit, availability of resources, etc.the warehouse and data marts.Footnote1 the AuthorDan Fuller is an Associate Director in Cognizant’s Advanced Solutions Group. He is an experienced Agilepractitioner who has led some of Cognizant’s largest and most complex deliveries for clients using Agile.His background includes 20 years of information technology consulting for some of the largest and mostrespected IT consulting firms. He received a master’s degree in technology in education from HarvardUniversity and a bachelor’s degree in accounting and information technology from the University ofMassachusetts, Amherst. He can be reached at cognizant 20-20 insights 4
  5. 5. About CognizantCognizant (NASDAQ: CTSH) is a leading provider of information technology, consulting, and business process out-sourcing services, dedicated to helping the world’s leading companies build stronger businesses. Headquartered inTeaneck, New Jersey (U.S.), Cognizant combines a passion for client satisfaction, technology innovation, deep industryand business process expertise, and a global, collaborative workforce that embodies the future of work. With over 50delivery centers worldwide and approximately 130,000 employees as of September 30, 2011, Cognizant is a member ofthe NASDAQ-100, the S&P 500, the Forbes Global 2000, and the Fortune 500 and is ranked among the top performingand fastest growing companies in the world. Visit us online at or follow us on Twitter: Cognizant. World Headquarters European Headquarters India Operations Headquarters 500 Frank W. Burr Blvd. 1 Kingdom Street #5/535, Old Mahabalipuram Road Teaneck, NJ 07666 USA Paddington Central Okkiyam Pettai, Thoraipakkam Phone: +1 201 801 0233 London W2 6BD Chennai, 600 096 India Fax: +1 201 801 0243 Phone: +44 (0) 20 7297 7600 Phone: +91 (0) 44 4209 6000 Toll Free: +1 888 937 3277 Fax: +44 (0) 20 7121 0102 Fax: +91 (0) 44 4209 6060 Email: Email: Email:© Copyright 2011, Cognizant. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by anymeans, electronic, mechanical, photocopying, recording, or otherwise, without the express written permission from Cognizant. The information contained herein issubject to change without notice. All other trademarks mentioned herein are the property of their respective owners.