Your SlideShare is downloading. ×

Agile adoption julen c. mohanty

906

Published on

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
906
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Agile Adoption : Success or Failure
  • 2. Agile Adoption : Success or Failure Julen C Mohanty Citicorp Services India Ltd
  • 3. DISCLAIMERS Any views or opinions showcased in this presentation are solely those of the author and may not necessarily represent those of the Citigroup. This document is meant for use of Business Analyst World or it’s members. Has to be used within Business Analyst World or it’s members and not to be forwarded to anyone outside Business Analyst World or it’s members.
  • 4.
      • INDEX
    What is Agile Why to go for agile (problem with water fall model) Difference between Agile & Iterative INVEST model for requirements Why Agile Projects Fail? CASE STUDY - Approach for Agile The agile Business Analyst A day with Agile BA
  • 5. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Source: http://agilemanifesto.org/
      • What is Agile
    That is, while there is value in the items on the right, Agile value the items on the left more.
  • 6.
    • Value to Customer isn’t realized until the end of a project
    • All requirements are delivered at once, instead of phasing by priority
    • Defects and integration issues are found very late in the project
    • Major risks aren’t identified and mitigated early
    • Change isn’t easily accommodated
    • Quality is often compromised to meet deadlines
    Problems with Waterfall Development
  • 7. Effect of Delays Start- up Initi- ation Concept Design Func Design Build / Test Tech Design Deploy Start- up Initiation Concept Design Func Design Build / Test Tech Design Deploy Start- up Initiation Concept Design Func Design Tech Design Build / Test Deploy Typical Project Plan: Option A: Reduce Build / Test / Deploy Time. This will compromise the Quality Option B: Extend Project End Date and Increase Cost OR Typical Project Execution:
  • 8. Client’s Perception Start- up Initiation Concept Design Func Design Tech Design Build / Test Deploy 12 Month Project (originally a 9 month project) Month 10: Value Is Visible (Client begins testing) Month 12: Value Is Achieved Months 1-9: No Visible Value
  • 9. Lack flexibility to change Start- up Initiation Concept Design Functional Design Tech Design Build / Test Deploy 12 Month Project (originally a 9 month project) Theory: All requirements should be defined More requirements discovered. Conceptual Design changes More requirements / problems discovered during build. Functional Design / Technical Design changes More requirements discovered. Functional Design changes
  • 10. Testing at the End (Fail Late) Start- up Initiation Concept Design Functional Design Tech Design Build / Test Deploy 12 Month Project (originally a 9 month project) Bugs and critical Integration issues aren’t driven out until here resulting in delays
  • 11. Agile Development is focused on an iterative (addressing all aspects of the lifecycle in each iteration) and flexible approach to software development Agile : Iterations
  • 12.
    • Agile allows for recurring releases that can be either internal or external
    • Prioritization of requirements means the highest value is delivered first
    • Customer sees growing value at the end of each iteration
    • If at any point project is halted, most critical value has already been delivered
    • Customer may choose to halt project once key requirements delivered, saving money
    Deliver Value to Customer
  • 13. Attack Critical Risks Early Iter 1 9 month project Problem: Assumptions were made in Conceptual that weren’t proven until Functional and Technical Design. These assumptions ended up being incorrect – resulting in serious delays Solution: Identify and attack those risks early on Iter 2 Iter 3 Iter 4 Iter 5…
  • 14.
    • Perform testing with each iteration
    • Most critical bugs are driven out early & resolved
    • Reducing overall cost and time of project
    • Each iteration is well tested, allowing for faster delivery of functionality
    • If at any point a project is halted, functionality to-date can be delivered and has been tested
    • Removes complexity of deferred testing
    Test Early and Test Often
  • 15. Difference between Agile & Iterative PLAN BUILD TEST REVIEW DEPLOY PLAN BUILD TEST REVIEW DEPLOY PLAN BUILD TEST REVIEW DEPLOY Waterfall Iterative
  • 16. Difference between Agile & Iterative PLAN BUILD TEST REVIEW REVIEW DEPLOY PLAN BUILD TEST REVIEW PLAN BUILD TEST REVIEW PLAN BUILD TEST REVIEW PLAN BUILD TEST REVIEW REVIEW DEPLOY PLAN BUILD TEST REVIEW PLAN BUILD TEST REVIEW PLAN BUILD TEST REVIEW Agile = Iterative + Incremental A B A B C A B C D IT1 IT2 IT3 Time Delivery Agile
  • 17. Agile Requirements Characteristics Independent • Avoid dependencies with other stories • Write stories to establish foundation • Combine stories to deliver in a single iteration Negotiable • Stories are not a contract • Not every story must be negotiable, Courtesy : Bill Wake Valuable • Each story should show value to the Users, Customers and Stakeholders Estimable • Enough detail should be listed to allow team to estimate • The team will encounter problems estimating if the story is too big, if insufficient information is provided / if there is a lack of domain knowledge Sized Appropriately • Each story should be small enough to be completed in a single iteration • Stories that may be worked on in the near future should be smaller • Larger stories are acceptable if planned further out Testable • Acceptance criteria should be stated in customer terms • Tests should be automated whenever possible • Team members should demand clear acceptance criteria INVEST
  • 18. WHY AGILE FAILS Not Looking at the bigger Picture Not having proper tools No Collaboration with Customer No Agile Mindset Absence of Team Work OR collaboration among team members No feedback system Not coming out from rigid plans No Response to change Sticking to contract and not the need of the situation Agile is not a silver bullet. Don’t expect Charismatic Results Agile as an excuse for having no discipline Agile without explanation Agile process fixation Time Value of Money Lack of Powerful Communication Not Having Test Driven Development Not Measuring Value delivered People in fear to lose title Team priorities change rapidly leading to productivity undermine Team keeps on missing iteration deliverables Bugs found by QA after the iteration completes The design & architecture is a mess!
  • 19. Technology Organization Structure Leadership People CULTURE Failure Category
  • 20. CASE STUDY 1
    • Global regulatory project to be rolled out to 70 country’s business users.
    • Involves consolidation of 15-20 stock exchanges of the world
    • Involves integration of 45 feeds from different countries
    • Have 15 languages to be incorporated to roll out
    • 95% of the application in No UI but in Mainframe
    • Some of the issues:
    • Interacting with business users with different regions for same parameters of data
    • Non availability of requirements on time from scattered business users
    • Most users weren’t 100% sure about the aggregation logic
    • Regulatory reporting requirement for countries were different
  • 21. group into 4 major regions One large exchange from each region 4 different tracks of development with agile Incrementing to region Integrating to global Taking care of regional specific requirements
    • Global regulatory project to be rolled out to 70 country’s business users.
    • Involves consolidation of 15-20 stock exchanges of the world
    • Involves integration of 45 feeds from different countries
    • Have 15 languages to be incorporated to roll out
    • 95% of the application in No UI but in Mainframe
    CASE STUDY 1
  • 22. Thinking: Are all team members aware of their progress 4 0 toward meeting team goals? Does the team improve their process in some way 5 0 at least once per month? Collaborating: Do team members generally communicate without confusion? 4 0 Do nearly all team members trust each other? 5 0 YES NO Releasing: Can any programmer on the team currently build a tested, 5 0 deployable release with a single command? Do all programmers integrate their work with the main body 4 0 of code at least once per day? How to Measure Agility
  • 23. Planning: Does the team have a plan for achieving success? 4 0 Does the team regularly seek out new information and 2 0 use it to improve their plan for success? YES NO Developing: Are all programmers comfortable making changes to the code? 3 0 Do unexpected design changes require difficult or costly 0 3 changes to existing code? How to Measure Agility
  • 24. Collaborating Developing Thinking Planning Releasing How to Measure Agility
  • 25. 7.5 points or less : immediate improvement required (red) 7.5 – 9.5 Points : improvement necessary (yellow) 9.5 – 10 Points : improvement possible (green) 10 Points : no further improvement needed How to Measure Agility
  • 26. Developer Business Analyst Tester Tester Developer Business Analyst/ SME Team Project Process undertakes shapes & follows the applies Agile is all about people, it’s people who build software not processes Agile Suggested way to approach Agile
  • 27. The Agile Business Analyst In agile the “analysis phase” is not just set of analysis documents and artifacts In Agile the ‘Analysis Document’ is not a deliverable, unlike in Waterfall model. In Waterfall model analysis documents : - do not show what is unknown about the project, - do not show the true risks associated with the project - user shows confidence as so much effort have gone in - becomes the “Bible” for the stakeholders to follow & benchmark business analysts spend a majority of their time on creating documentation rather than performing analysis, that is, learning about the problem
  • 28. The Agile Business Analyst in ‘Analysis learn about the problem Agile analysis is highly iterative and incremental process In Agile Analysts, developers and project stakeholders actively work together - to understand the domain - to identify what needs to be built - to estimate that functionality - to prioritize the functionality - produces artifacts that are just barely good enough. In agile the Analysis Phase isn’t a phase of a project isn’t a task on a project schedule isn’t a means unto itself The Agile Business Analyst
  • 29. Agile analysis should be communication rich Agile analysis is highly iterative Agile analysis is incremental Agile analysis explores and illuminates the problem space Agile analysis includes estimation and prioritization of requirements Agile analysis results in artifacts that are just good enough The Agile Business Analyst Process Parameters:
  • 30. significant amount of business analysis must be performed to understand what the features and tasks must be before they can be estimated design depends upon analysis, Neither can be done without the other It need not identify classes, relationships, and methods, Rather those tasks, and their estimates, describe external behaviors that are visible and demonstrable to the stakeholders the stakeholders could choose a few of the most important features. The team could break them into tasks, estimate them, prioritize them, and choose a month’s worth of the highest priority tasks to implement   In an agile project team repeat this activity The Agile Business Analyst Things to keep in mind
  • 31. A day with Agile BA 1. Identify System Users 2. Define Main Users Goals 3. Define System Usage Patterns 4. Invent Functional Solution to Meet Users Goals and Usage Patterns 5. Define Main Navigation Paths 6. Create UI Mockups 7. Polish UI Elements Can we improve UI to reduce clicks, provide better visibility, etc? Who will use the system? What I (as a user ___) want to achieve with help of the system? What are the typical user behaviors (daily, specific situations, etc.)? What is the best way to satisfy usage pattern? What functional areas/action should user execute to complete usage pattern? Prototype showcase
  • 32. Agile is like a If u use it properly in your work If u use it wrongly, it will put you into trouble
  • 33. Thank You www.twitter.com/julenmohanty www.linkedin.com/julenmohanty julenmohanty [email_address]

×