Introducing Agile


Published on

presented during 2 days seminar on software testing in vellalar college, erode

Published in: Technology, Business
  • 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
  • General notes: The objectives for this presentation are (in order of “most votes at the stake holder meeting” to “least votes”) Should you go for Agile (How to make a decision, and pros and cons) Learning about Agile during ISIS Understand how I can change the way I do my job to be more Agile Better understanding of the benefit of Unity Agile Understand that discipline is required (esp. Project Management even on an Agile project) Understand that documentation is important in an agile project (detail which documents) Agile does not mean “no discipline” Yes, that last point is a repeat :) In the context of this presentation, “Agile” refers to “Unity Agile” (that is, CCA’s brand of agile) This is to reduce the word count and to avoid confusion (“Does this apply to us? Or is it something specific to scrum?”) So, what is the Unity Project? It’s an attempt to specify a subset of methodologies that can be used to deliver projects. There are two main streams: an “agile” stream, presented here, and a “progressive” stream (which is essentially the waterfall model) The aim is to provide greater customer satisfaction by providing successful releases of projects that meet all of a project’s goals. The slogan for Unity is “The Way CCA Does IT”, hence the subtitle of this presentation. The diagrams in this presentation have largely been drawn from the Unity website, though some of them should feed back the other way too. For groups larger than about 5 people (that is, for all the presentations where ThoughtWorks will be presenting content) there should be a co-facilitator. Their role is two-fold: 1) to learn the content and to be prepared to act as the lead presenter at some point (not today!) and 2) provide back-up to the presenter (eg: a TWer might appreciate having an experienced CCA person along to help answer some Coke specific questions, and an extra pair of hands for the Agile Game is useful) I’d love for some of the slides to be less wordy. The ideal is the “beyond bullets” approach, where almost all the content is visual and there are no bullet points at all. I’ll settle for someone being able to read the titles of the slides and getting a good feel for what this presentation is about. Final notes, use “we” when speaking as much as possible. You’d like people to feel included and that you’re not an outsider pushing new ideas and concepts down their throats. This is particularly important because a sizable minority of the audience might not see much point in their being there; they need support and to feel involved. Enthusiasm also counts for a lot: this is fairly dry content, so a little humour and an enthusiastic presenting style is what’s going to make sure that people walk away feeling “warm and fuzzy” about what they’ve just heard.
  • Introducing Agile

    1. 1. Introducing Agile
    2. 2. Realities of software development <ul><li>Requirements will change </li></ul><ul><li>Cost of change is high </li></ul><ul><li>Plans don’t effectively accommodate change </li></ul>
    3. 3. Traditional Process 50 % done?
    4. 4. Better way of doing the same End-to-End small slices of work 20 % done = 100 % usable
    5. 5. Agile Manifesto <ul><li>“ We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: </li></ul><ul><ul><li>Individuals and interactions over processes and tools. </li></ul></ul><ul><ul><li>Working software over comprehensive documentation. </li></ul></ul><ul><ul><li>Customer collaboration over contract negotiation. </li></ul></ul><ul><ul><li>Responding to change over following a plan. </li></ul></ul><ul><li>That is, while there is value in the items on the right, we value the items on the left more.” </li></ul>
    6. 6. Just the right amount of documentation
    7. 7. Collective Ownership No bottlenecks Team responsibility Improves code and process Reduced risk of staff absence
    8. 8. Collaboration IT and Business working together
    9. 9. Pairing Developer (Driver) Developer (Co-Driver) Business Analyst
    10. 10. Continuous Integration Integrate early, integrate often Automated builds Culture of accountability
    11. 11. Frequent Short Releases Prioritized features Adds business value early Showcases for feedback
    12. 12. Collocation Everyone in the same area to Improve communication
    13. 13. “ Yesterday, I …” “ Problems …” “ Today, I ...” Daily Stand-Ups
    14. 14. Story Wall shows the project health
    15. 15. Project objective
    16. 16. Simplest thing that adds business value
    17. 17. Incrementally adding business value
    18. 18. Successfully accommodating changed requirements
    19. 19. Result of iterative and incremental development Original objective
    20. 20. Questions?
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.