Agile methodologies..

1. Agile methodologies.. OSQA

2. Contents • The Essence of Agile • Common Agile methodologies • A comparison between various methodologies • Conclusion

3. History • Evolved in mid 90s • Reaction against “Heavy Weight" methods • Heavy weight models like “waterfall “ were seen as bureaucratic, slow, demeaning, and inconsistent with the ways that software developers actually perform effective work • Software developers adopted “lighter” approach for building the software • 17 Practitioners met at Snowbird, Utah to discuss about “Light Weight” methods • Decided the word “Agile “ for the methods as the word means adaptiveness and response to change • Released the Manifesto for Agile software development • Describes what agile stands for and also what agile is opposed to. • Formed Agile Alliance as a non-profit organization to act as a center for furthering agile methods

4. Heavy Weight/Predictive software Methods • Predictive methods • Focus on planning the future in detail • A lot of emphasis on planning before building • Construction be done in a more predictable as per the plan • Very clear about features and tasks planned for the entire length of the development process • Difficulty changing direction. • Typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently

5. Predictive methods Issues - Software Industry • In building business software requirements, changes are the norm.. • Estimation is tough • Software development is more a design activity, and thus hard to plan and cost. • Requirements keep changing rapidly. • So much dependent on which individual people are involved, and individuals are hard to predict and quantify • Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan.

6. What software needs ? A process that can give you control over an unpredictability A method adaptive to changing requirements – Agile Methodologies!!!!

7. Agile – What it means ? Readiness for Motion Nimbleness (Quickness) Dexterity in Motion

8. Software Agility ? • Ability to adapt • to Changing circumstances • to Changing requirements • Impact • Improves business climate • Provides competitive edge • Quick gratification for Customers & Developers • Faster Return on Investment

9. Agile Methods Agile methods produce completely developed and tested features every few weeks or months. Emphasis is on obtaining the smallest workable piece of functionality to deliver business value early, and continually improving it/adding further functionality throughout the life of the project.

10. Adaptive/Agile methods • Focus planning of tasks being done immediately • Very much adaptive to changes • Work done in a highly collaborative manner • People-oriented rather than process-oriented • Are less document-oriented, usually emphasizing a smaller amount of documentation for a given task. • It is more code-oriented • Key part of documentation is source code

11. Agile Programming – Key features • Agile methods emphasize face-to-face communication over written documents • Agile teams are located in a single open office called bullpen • Agile methods emphasize working software as the primary measure of progress • Agile methods are more adaptive in nature • adapting quickly to changing realities

12. Evolution of Agile methods • “We embrace modeling, but not merely to file some diagram in a dusty corporate repository” • “We embrace documentation, but not to waste reams of paper in never-maintained and rarely-used tomes” • “We plan, but recognize the limits of planning in a turbulent environment” • - Martin Fowler & Jim Highsmith Code & Fix Plan driven methodologies Agile Methodologies A compromise between no process and too much process, providing just enough process to gain a reasonable payoff

13. Choosing between adaptive (“Agile") and predictive (“Plan-driven") • Agile • Low criticality • Senior developers • Requirements change very often • Small number of developers • Culture that thrives on chaos • Plan-driven • High criticality • Junior developers • Requirements don't change too often • Large number of developers • Culture that demands order

14. Agile methods – Organization Characteristics • The culture of the organization must be supportive of negotiation • People must be trusted • Fewer staff, with higher levels of competency • Preferred team size is 20 to 40 people • Organizations must live with the decisions developers make • Organizations need to have an environment that facilitates rapid communication between team members

15. Manifesto for Agile Software Development “We are uncovering better ways of developing software by doing it and helping others do it. Through this 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 plan That is, while there is value in the items on the right, we value the items on the left more. http://www.agilealliance.org

16. General Agile Principles • Deliver something useful to customer • Nothing counts until you deliver software • Deliver frequently • Four to eight weeks • Encourage collaboration • “Active customer involvement is imperative!” – find a champion • Daily meetings – very short • Provide technical excellence • Rely on the skills of your people • Do the simplest thing possible • Balance flexibility and structure • Self-correcting teams • Don’t let people suffer • Install when business needs it & technically feasible

17. Agile Manifesto • Satisfy customers with valuable software • The highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome change requests at any time • Making changes quickly can be a competitive advantage • Welcome changing requirements, even late in development. • Agile processes harness change for the customer's competitive advantage.

18. Agile Manifesto Cont… • Deliver working software frequently • Don’t let people suffer • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. • Daily Contact • Customers & developers • Avoid intermediaries • Business people and developers must work together daily throughout the project.

19. Agile Manifesto Cont… • Use Champions • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done • Managers must thrust their staff to take decisions • Team Communication • Avoid long or large meetings • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Distinction between agile and document-centric methodologies is not one of extensive documentation versus no documentation; rather a differing concept of the blend of documentation and conversation required to elicit understanding.

20. Agile Manifesto Cont… • Working software is primary measure • Models, documentation, use cases do not count • Working software is the primary measure of progress • Maintain a constant pace indefinitely • No Death Marches • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

21. Agile Manifesto Cont… • Design Quality enhances agility • Late and post-implementation changes easier • Continuous attention to technical excellence and good design enhances agility • Design is continuously enhanced throughout the project • Self-organizing teams increase quality • Volunteers produce better results • Members look out for and help each other • The best architectures, requirements, and designs emerge from self-organizing teams.

22. Agile Manifesto Cont… • Simplicity -- the art of maximizing the amount of work not done -- is essential • Do less – get more • Include only what everybody needs rather than what anybody needs "Everything should be made as simple as possible, but not one bit simpler” - Albert Einstein • Teams self-correct • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

23. Adaptability Scale

24. Project Management Styles • Predictive : Command & Control • Defined process • Plan what you expect – make predictions • Enforce the predictions • “Change Control” to manage change • Agile : Collaborative leadership • Empirical process • Start with a plan • Change plan frequently • Inspection & Adaptation

25. Agile Methods - Business Benefits Promotes rapid delivery of value to customers Provides timely and regular visibility of the solution to customers, product owners and stakeholders Delivers increases in productivity, quality & ROI for software development organizations Agile more effectively addresses change Minimum Process, Maximum Value

26. Software Economics Net Profit = Throughput – Operating Expense ROI = Net Profit / Investment

27. How Do Agile Methods Improve ROI? Solutions are better fit to customers real needs Easier mid-course correction - reduced costs of unforeseen changes Lower investment in inventory and unnecessary features Lower project expense due to less rework after the first release Increased productivity of the development staff Greater executive visibility

28. Agile methods - Issues Initial assumptions may result in a large drift from an optimal solution especially if the client has poorly formed ideas It is easy for a single "dominant" developer to pull the design of the target in a direction not necessarily appropriate for the project

29. Agile Development criticisms • Lack of structure and necessary documentation • Incorporates insufficient software design • Requires too much cultural change to adopt • Can lead to more difficult contractual negotiations • Can be very inefficient -- if the requirements for one area of code change through various iterations, the same programming may need to be done several times over. Whereas if a plan was there to be followed, a single area of code is expected to be written once. • Impossible to develop realistic estimates of work effort needed to provide a quote, because at the beginning of the project no one knows the entire scope/requirements • Drastically increases the chances of scope creepdue to the lack of detailed requirements documentation

30. A Generalized Agile Process Release Backlog Iteration 1 Iteration 2 Iteration … Backlog • Feature 1 • Feature 2 • Feature 3 • …. • Feature 9 • Feature 1 • Feature 2 • Feature 3a • Feature 3b • Feature 4a • Feature 4c • Feature 6 • Feature 7 • Feature 8 • Feature 9 • Feature 10 • ….

31. Waterfall Iterative Iterative and Incremental Parallel AcceptanceTest Driven Big Design Up Front Continuous Highly specific Big Test on Backend Fully Integrated Continuous What’s Different? Agile Development Process Measure of Success Conformance to Plan Response to Change Culture Command-and-Control Leadership /Collaborative Design QA Tool Support

32. New Measures of Success • Critical bottlenecks • Feature Breakdown Structure • # of features accepted • Parallel functions • Empirical time boxes • Fixed time and resources • Real time objective evidence Agile Development WaterfallDevelopment Iterative Development Iterative and Incremental Development Parallel Development AcceptanceTest Driven Development Process Measure of Success Conformance to Plan Response to Change • Critical Path • Work Breakdown Structure • % complete of tasks • Serial functions, R,D,T • Procedural process • Fixed scope • Plans, estimates, earned value

33. Culture of Discipline and Collaboration Agile Development WaterfallDevelopment Iterative Development Iterative and Incremental Development Parallel Development AcceptanceTest Driven Development Process Culture Command-and-Control Leadership /Collaborative • Culture of learning • Gross estimates create the high-level plans • Detailed Planning JIT • Protect the date and iteration scope • Demonstrate every iteration • Culture of sign-offs • High-level plans = Roll-up of detailed plans • Detailed planning early • Protect the project scope • Demonstrate at end

34. Big Design Up Front Continuous Big Test on Backend Continuous Continuous Design & Test Contract with Customer Big Design sign off Dreaded integration phase Never miss “dev complete” date Work in big phases Testing squeezed Agile Development WaterfallDevelopment Iterative Development Iterative and Incremental Development Parallel Development AcceptanceTest Driven Development Process Design QA • Partner with Customer • LRM Design Decisions • Continuous integration • Never break the build • Work in small chunks • Low features squeezed

35. Highly specific Fully Integrated Agile Project Tooling • Focus on the team • Optimize the whole • Tight integration • Manage rapid throughput-Manage the FBS • Real-time visibility up, down and across the team Agile Development WaterfallDevelopment Iterative Development Iterative and Incremental Development Parallel Development AcceptanceTest Driven Development Process Tool Support • Focus on individual • Optimize the parts • Integrate with batch update • Manage large inventories Un-integrated with the WBS • Visibility through manual PM report

36. Myths and Realities of Agility Myths and Realities of Agility • Agile is free form and chaotic • An iteration is a release • Agile doesn’t require documentation • Agile is Extreme Programming • Agile doesn’t need requirements • Agile methods is against "plan-driven" or "disciplined" methodologies Myth Reality • Agile is an extremely disciplined software process • A Release is a Release • Agile recommends documentation that is appropriate to the project context • XP is one form of agility, an extreme form at that • Agile excellence is dependant on effective requirements process. • If none exists, agile IS a requirements discovery process.

37. Extreme Programming • SCRUM • Crystal Methodology • Feature Driven Development ( FDD) • Rational Unified Process( RUP) • Dynamic System Development Method (DSDM) • Adaptive Software Development (ASD) • Agile Modeling

38. eXtreme Programming A system of practices that a community of software developers is evolving to address the problems of quickly delivering quality software, and then evolving it to meet changing business needs.

39. XP One of the fundamental ideas of XP is that there is no process that fits every project as such, but rather practices should be tailored to the needs of individual projects.

40. Extreme Programming • A discipline of software development with values of • Simplicity • Communication, • Feedback • Courage Key roles of XP Customer Programmer Manager

41. Roles in XP • Customer • Define “business value” (User Stories) • Decide “What to do first” • Defines “Acceptance test” • Programmer • Estimate the difficulty of all stories • Deliver the business value - Design, build and Test and bring the entire software to a coherent whole • Track the pace at which the stories can be delivered • Manager • Bring the customer & developer together and helps them meld into a smoothly operating system • Remove everything from the team’s path that doesn’t contribute to the delivery of good software • Conflict resolution

42. Rights & Responsibilities • Manager & customer • Right to an overall plan , to know what can be accomplished, when and at what cost • Right to see the progress in a running system proven to work by passing the test specified • Right to change the requirements & priority • Right to be informed of the schedule changes • Right to cancel at any time and be left with an useful working system

43. Rights & Responsibilities • Programmer rights • Right to know what is needed with clear declaration of priority • Right to ask for and receive help from others • Right to make and update the estimates • Right to accept the programmer responsibilities instead of having it assigned to you

44. XP Practices

45. The circle of life An XP project Succeeds when customer selects business value to be implemented based on team’s measured ability to deliver functionality over time Build Value Define Value Customer Programmer Programmer Customer Choose Value Estimate Cost

46. Learning from CoL • Managing the scope • To get the best possible combination of features with the required quality • For a predictable delivery with the required quality

47. On-site customer • Full time customer to provide guidance • Programmers will program anything – Tell them what’s needed • More the time the customer & programmers spend together , the better things go • Not tying hands of developer , but available to answer the questions • Conversation about what’s needed is more effective than written communication • AT address the risk of loss of information conveyed through conversation • Saves Time and build a rapport between customer & programmer • Avoids Unnecessary guesses & waiting time

48. If customer can’t be there Have a pseudo-customer who is an expert in the area Get the real customer at least for planning meetings where priorities are set Send programmers to customer site Release code frequently – Customer can’t see you , but they can see the system Expect misunderstandings and plan accordingly

49. User Stories Captured as additional documentation • System is specified through stories from the point of view of an user User Stories • Each story card serves as a token for planning and implementation Written cards Conversation series between customer & programmer

50. Stories Stories are Promises for Conversation Prefers informal analysis of the stories – Ask the customer Splitting of story if required Thump rule – At least one story per programmer per month, two is better