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.
5.
6.
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.
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.
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!
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
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
