Transitioning to Agile Guidelines

CONFIDENTIAL Copyright 2008 Tech Mahindra Limited*Table of Contents Why Agile? Traditional vs. Agile Criteria of selection of projects When not to use Agile Transitioning Steps Agile Enablement Structure Transitioning to Agile Practices Transformation and Baby Steps Agile Delivery Model Case Study for actual transition - Oneview

CONFIDENTIAL Copyright 2008 Tech Mahindra Limited

Why Agile?Why Customers/Product Owners Adopt AgileEarly measurable return on investment

High visibility and control over the project progress

Early and continuous customer feedback

Empowered Product Owner

Incremental delivery

Adaptive to changing business needs

Alignment of IT with the business

Reduces product and process wasteCONFIDENTIAL Copyright 2008 Tech Mahindra Limited*


Why Agile?.contd..Why the Team and Management Adopt AgileBuilds empowered, motivated and self organizing teams

Clear expectations are set and communicated

Success is clearly defined

Teams can focus on delivering measurable results

Customers communicate directly with the team and provide timely feedback

Teams feel a sense of accomplishment and recognition

Management realizes cost/time savings due to waste elimination and efficiency

Better resource management for shared team members

CONFIDENTIAL Copyright 2008 Tech Mahindra Limited*


Traditional vs. AgileCONFIDENTIAL Copyright 2008 Tech Mahindra Limited*

WaterfallAgileWaterfall is release driven, with a defined critical path and sequence for deliveryAgile is based on short iterative delivery cycles

Estimates are based on the work required to meet the requirementsEstimates are done based on the amount of work the team can accomplish in a set period of timeRequires clearly defined requirements upfrontRequirements are expected to evolve and change is embracedSuccess is measured by the IT organizationSuccess is measured by business value delivered


Criteria for selection of ProjectsAgile approach is recommended when:Domain & Technology are evolvingRequirements changeShort timelines for deliveryProject Type Full Life Cycle, EnhancementRelease Planning Joint Development of User stories/ Release Plan in Hothouses Human Factor - Experienced Skill set, Willing and Empowered team / team size of 7 to 9 people; collocationInfrastructure CASE tools for Upper Phases, Testing Tools, Configuration Management ToolsDevelopment Methodology Iterative, Incremental, Exploratory Customer - who wants to work in a collaborative wayProject Criticality - A project that's a little bit more critical than you are comfortable with. But to start first time a simple, low risk project is recommended Organization Is the leadership team ready to support a shift in thinking from the big bang approach to smaller iterative delivery cycles? Can the organization accommodate the frequent delivery of increments? Has the business bought in to Agile? They will be required members of the project team and must actively participate to make Agile work. In many cases they are not willing to give up their day job to support the project team.

CONFIDENTIAL Copyright 2008 Tech Mahindra Limited*BACK


Customer/User/Stakeholder Collaboration- Not to use Agile When Customer not available to answer questions as they arise. When Application users are NOT always accessible to youIf your stakeholders work better as individuals, producing individual results, than working with a group If stakeholders prefer to know what you are going to create before you start the design phase then Agile may not be the best methodology to useManagement Commitment- Not to use AgileWhen Management fail to understand agile practice and failure of management commitment to implement ScrumRequirements/Scope Management- Not to use AgileWhen the requirements aren't managed well When there is well-defined Scope, well-defined acceptanceWhen the applications support an entire business unit over a long ROI period, with repeated updates and enhancements expected. These applications are likely to be managed by successive generations of application owners, who will need to inherit documentation from their predecessors, maintain it, and pass it on their successors.If you know all the project requirements are (plan driven) before development begins then you may not need to use Agile (change driven) methods for requirements elicitation

CONFIDENTIAL Copyright 2008 Tech Mahindra Limited*When NOT to use Agile WHEN and Ifs of Agile


The team and interactions Not to use Agile When the project team cannot adapt to changes in working durations, overlaps & shifts When there simply aren't enough people-For very small tasks or very small teams that can be easily coordinated through other more ad-hoc means, AGILE/SCRUM is over engineering If the development team and test team do not interact on a daily basis or work closely together If you or your team doesnt fully understand how Agile works then do not use itWorking SoftwareNot to use AgileIf it takes you longer than two to four weeks to produce a working productIf you are not working on a compressed or overlapping schedule and you have time allotted to each phase of the SDLC CONFIDENTIAL Copyright 2008 Tech Mahindra Limited*When NOT to use Agile WHEN and Ifs of Agile


CONFIDENTIAL Copyright 2008 Tech Mahindra Limited*Transitioning StepsStep-2First and foremost thing is to identify a good Agile Enablement structure or set up the governance (Refer Agile Enablement Structure)Step-1Don't wait for the right day to start Agile. Start today. Get some good books for startersStep-5Take a simple and low risk project to try Agile Also, with the help of Agile coach ensure that this project succeeds (Refer Criteria of Selection of Projects)Step-4Get all the team members to undergo training on Agile (XP, Scrum, etc)Step-3Ensure that management provides complete support to the Agile Enablement Structure.


Transitioning Steps contd..CONFIDENTIAL Copyright 2008 Tech Mahindra Limited*Step-6Don't force all the Agile practices at once. Take Baby Steps one or two practices at a time and give sufficient time for the team to learn and practice. E.g. One can start with shorter iterations and scrum/daily stand up meetings. (Refer to Agile Transformation and approach steps)

Step-7Start with 4-6 weeks iteration rather than 1-2 week iteration.; moving gradually to 2 or 1 week(Refer Agile Delivery Model)

Step-8Don't bother if you would like to start with Scrum or XP. Instead, put all the Scrum and XP practices in a big basket, take the simplest one at a time and start practicing it. Over a period of time you would understand what is best for your team. Step-9Even though having in-depth understanding of Agile values and principles are key to succeed in an Agile environment, the team may not be able to grasp all of them at once. As and when each practice is introduced to the team, show them the relationship to the values and principles.Step-10Depending on the life cycle followed; the SDLC phases viz. Design, Development and Component Integration Testing can be transformed into agile SCRUM teams


Transitioning Steps contd..CONFIDENTIAL Copyright 2008 Tech Mahindra Limited*Step-11SDLC oriented teams need to transformed to functional domain aligned teams e.g. A large team needs to broken into smaller scrum of scrum teams based on functional domainsStep-12Physical co-location as far as possible for each SCRUM teamStep-13Try to make use of visible tools like Flip Charts, Burn Down charts, Post-It notes spreadsheet and encourage more interactions among developers. Make the developers to come out of their cubicles and start designing things on boards. Step-14Scrum and XP advocates specific team structure like Having Product Owner, Team, cross functional teams, no hierarchy, a team coach, scrum master, etc. This is a very sensitive issue. Let the team learn slowly the importance of the values and decide what is best for them. Let the project managers slowly transition from their current responsibilities to become scrum masters.Step-15Use the Agile Assessment Checklist as a readiness tool for any project trying to migrate to Agile AND once the project has adopted Agile and wishes to assess the level of implementation against each of the core Agile practice.


Agile Enablement Structure (Refer Step2)Refer the Model for Agile Enablement Structure for a large Platform or Program made of multiple components / projects

For new start with no prior experience then a consultant external to TechM is recommended else one can seek help of internal SMEs who can act as a mentor at the Program level

External consultant can in turn mentor / groom TechM internal consultant along with representatives from Quality Management Group(QMG) and Education Services Group (ESG)

The internal consultant would then train the coaches identified at a platform level who would work with the teams on a day to day basis and in turn have agile champions in each project to take it forward on an ongoing basis

For a small or medium size project only a Agile coach who can develop internal champions within the project would suffice

Note: This model can be tailored for smaller engagements with only a coach at a project level with internal champions



Agile Enablement Structure - Model CONFIDENTIAL Copyright 2008 Tech Mahindra Limited*


External AgileConsultant

Tech MQuality ManagementGroup

Tech MPlatform AgileConsultant

Tech MEducation Group

Coach 1

Coach 2

Coach 3

Platform Coaches

Component 1Agile Champion



Platform Components

Agile transformation & approach steps(Refer Step6)Baby steps - 1Identify persons for roles (Users, Product Backlog owner)Identify suitable time for Scrum meetingConduct Scrum/Standup MeetingConvert requirements to a User Story formatConsolidate User stories in Product Backlog along with prioritizationEstimate User stories

Baby steps 2Complete Sprint planningUse Burndown/Burnup charts to refine estimates & trackConduct Show & Tell or Sprint Review meetingObtain User SignoffsConduct Retrospective at end of sprint & Show and tell

Baby steps 3Evaluate and finalize Tool for Continuous IntegrationTest automation

Baby steps 4Evaluate and finalize tools & process for Test Driven Development



Agile Delivery Model (Refer Step7)The Release needs to be broken into iterations starting with 3- 4 week duration coming down to 2 -1 week duration. 1 week being ideal.

Assumed that initial planning and E2E architecture is complete prior to start of the development iteration. Component design can also follow an iterative pattern though not depicted here

Figure 1 depicts a 90 day or 3 month release broken down into -A 2 week development iteration consisting of Build +Unit testing combinedData Migration iteration (in case project involves any transformation from old system to new)E2E Testing or System integration testing iterationUser Acceptance Testing (UAT)

The development iteration encompasses sprint or iteration planning in the beginning and show or tell / demo to customer at the end of the iteration followed by Retrospective or post implementation review

Figure2 depicts the sequence how the iterations are sequenced

Support or Fault fixing of First dev iteration starts at the end of development along with SIT1 in parallel with development of the second iteration

Please refer the Agile Kit on BMS for details on the standard agile lifecycle to be followed in TechM



CONFIDENTIAL Copyright 2008 Tech Mahindra Limited*Agile delivery model Figure 1 Elapsed DaysRetro-spectivePre-ReleaseT0306090180-15Phase 1Phase 2Working Days015Sprint orIterationPlanningRelease 2PlanningShow &TellRelease 1PlanningPrioritised Business Scenarios/User StoriesBusiness Delivery Plan

IterationNote:Timelines are for illustration purposes only

BMS References

ProceduresAgile Kit for PM (ITS-E-G006A) contains references to all other linked procedures, templates and checklists pertaining to the Agile life cycle

Guidelines & ChecklistsAgile Assessment Checklist (WIP)Recommended TrainingsAgile Level1 Training


Document HistoryCONFIDENTIAL Copyright 2009 Tech Mahindra Limited*

Version NoDateAuthorReviewed ByApproved ByReason and Nature of Change0.117-Jul-12Ashwini ChaudhariShalini, Puja and Ashish G First Issue Internal Review done by Agile task force0.208-Aug-2012Ashish GuptaAshwini and PujaIncorporating internal review comments and formatting changes0.39-Aug-2012Ashwini ChaudhariChanged name of the document and content in Enablement slide


Agile enablement structure

CONFIDENTIAL Copyright 2008 Tech Mahindra Limited*Benefits of AgileBetter collaboration with the users/SPOCImproved user acceptance by continuous collaboration with the userCapturing defects early in delivery cycleAbility to deliver units fasterDaily tracking through burndowns Opportunity to refine estimate every dayLearn/fine-tune as you go approach through retrospectivesQuicker delivery cyclesHappier teams and customers


CONFIDENTIAL Copyright 2008 Tech Mahindra Limited*Agile manifestoThat is while there is value in the items on the right we value the items on the left moreWe are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value

http://www.agilemanifesto.org


**Early measurable return on investment. They want to see working software at the end of each iteration and early in the process. High visibility and control over the project progress. High visibility into project progress can also yield early indications of problems. Early and continuous customer feedback. Because the customer is involved throughout development they end up with software they want and will use. Empowered Product Owner.The PO is given the information necessary to make decisions to steer the project toward the goal. Incremental delivery. Delivery of software on the scheduled release date is not an all or nothing deal. Agile change management is adaptive to changing business needs.Agile and Scrum give the product owner more control over adding, changing, or removing requirements (except for the current iteration stories) than traditional methodologies. Agile helps align IT with the business. Teams work only on the top business priorities. Agile reduces product and process waste. Nothing is developed that isnt specifically needed. Agile processes are lightweight and value driven.

*Agile builds empowered, motivated and self organizing teams. Agile produces an increased level of team satisfaction because individuals are empowered to provide input, set the iteration goal, self-organize, and help improve the process. This unleashes the creativity and innovation of the team members. Clear expectations are set and communicated. Both the team and product owners have a clear understanding of the release and iteration goals and what is expected of them to reach these goals. Success is clearly defined. The agile definition of "Done" is accepted by the product owner as completed and ready to ship. The only measurement for success is stories that are "Done" at the iteration and release level. Teams can focus on delivering measurable results. Agile teams focus on getting working software delivered instead of clearing impediments, prioritizing, or being pulled in other directions. Customers communicate directly with the team and provide timely feedback. Early and direct feedback is the only way to deliver what the customers really need. Teams feel a sense of accomplishment and recognition. The team feels a sense of accomplishment at each demo when they deliver stories that are "Done" and hear the customer and stakeholder feedback first hand. Management realizes cost/time savings due to waste elimination and efficiency. Many organizations that adopt agile seek to become "Lean" and eliminated processes that add no value. Better resource management for shared team members. The good thing about time-boxed iterations is that they are time-boxed! This means that shared members from other teams (DBAs, Technical SMEs, Report Writers, etc.) will know in advance when the next planning meeting, demo, and retrospective are scheduled.

*Which methodology to use depends upon depth of the challenge, in this instance how deep is your knowledge of business requirements and the technology solution you are planning to deploy.Waterfall is best suited to scenarios where the business requirements and technology solution is well known and understood. For example, with the popularity and increasing use of mobile and hand-held devices there is a tremendous need to re-factor or re-develop existing applications and make them compatible with these new platforms. In these scenarios, where the business requirements are clearly known and the technology is clearly established a waterfall methodology will be the best to be used. Waterfall is a robust methodology and in my experience it starts to fail when you are dealing with relatively unknown set of business requirements.Agile: Use of Agile for software development is gaining popularity rapidly. Agile is very useful and highly recommended when business is implementing a new operational strategy. In other words, when the business requirements, the end solution are reasonably known and you have a business owner who can take an instant call what is needed and what not, the Agile methodology works the best.A digression, Agile is a very used and abused term these days and people tend to focus on methods such as Scrum, Extreme Programming (XP) or Test Driven Development (TDD) a lot and miss the whole point of Agile.******

Transitioning to Agile Guidelines

Documents

Transcript of Transitioning to Agile Guidelines