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.
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>
Better way of doing the same End-to-End small slices of work 20 % done = 100 % usable
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>