1 / 19

Agile – The Movement

Agile – The Movement. Chapter 1 “Agile”, the Movement from SDLC 3.0 Beyond a Tacit Understanding of Agile. Introduction. There seems to be some confusion as to exactly what Agile really means. Some know. Some don’t know..

shafira-ramos
Download Presentation

Agile – The Movement

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Agile – The Movement Chapter 1 “Agile”, the Movement from SDLC 3.0 Beyond a Tacit Understanding of Agile

  2. Introduction • There seems to be some confusion as to exactly what Agile really means. • Some know. Some don’t know.. • We know the background and the thinking and motivation of the key agilists. • The Manifesto was developed to codify this basic thinking behind Agile.

  3. The Agile Manifesto (2001) • These key people felt that they were uncovering better ways of developing software by doing it and helping others do it. They cite their values: • 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 leftmore.”

  4. Introductory Thoughts on Agile • If an approach is to be considered ‘agile’ it must conform to the Agile Manifesto. • Oftentimes, however, many have difficulty in totally subscribing to these values • Some executives have problems, as they are stewards of shareholder funds. • They are concerned with scaling with Agile. • They want to be sure all this works! • They want evidence over and above anecdotal and emotional testimonies.

  5. Two Problems in the Agile Manifesto • Remember: Point 1 from the manifesto: • “That is, while there is value in the items on the right, we value the items on the left more.” • The 17 Agilists realized this is not all white and black. • These individuals did not advocate purist interpretation. • While agile is about change, adherence to this principle can result in outlying groups to advance unique agenda. • Point 2: While the values are clear, they shout for further granularity, and these are the Principles of Agile

  6. The Twelve Principles of Agile Development • Our highest priority is to satisfy the Customer through early and Continuous Delivery of Valuable Software • Welcome changing Requirements, even late in Development. Agile Processes harness change for the Customer’s Competitive Advantage • Deliver working software frequently, from a couple of weeks to a couple of months with preference to shorter periods. • Business People and Developers Must Work Together Daily throughout the Project • Build Projects around Motivated Individuals; Give them the environment and support they need, and thrust them to get the job done. • The most efficient and effective method of conveying information to and within a Development Team is face-to-face Communications.

  7. The Twelve Principles of Agile Development • Working Software is the Primary Measure of Progress • Agile Processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. • Continuous attention to technical excellence and good design enhances agility. • Simplicity – the art of maximizing the amount of work not done – is essential. • The best architectures, requirements, and designs emerge from self-organizing teams. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

  8. Tacit Knowledge and its Effects • Knowledge may be ‘explicit’ – the knowledge we are aware we have / possess • Or ‘tacit’ – knowledge we possess but are not aware we possess it – most of the time. • There is never a substitute for experience in developing software. • No book learning or knowledge of a process or workflow can substitute for the highs and lows of developing software.

  9. Tacit Knowledge • To this end, the author asserts that the majority of software engineering knowledge is tacit – we are not aware we have it until we are in an environment where we can piggy back and share and trust that (oftentimes) accumulated knowledge. • I could not agree more…

  10. Tacit Knowledge and its Emergence • Remember the thirdvaluestatement of the Manifesto: : Customer collaboration over Contract Negotiations. • For tacit knowledge to emerge, we need to be in an environment where this abundant knowledge (MUCH more than explicit knowledge) can be surfaced and used. • Plan-driven (heavy-weight) methodologies are NOT such environments! • These plan-driven processes use documentation as an attempt to have knowledge persist. • Documentation is essential in some activities. But overall, this does not lead to the dissemination of tacit knowledge. • Need to be in an environment where business knowledge and development knowledge can be divulged.

  11. Tacit Knowledge and its Emergence • WE need an open environment for agile methodologies to work • Need an environment of trust and openness for Agile to work. • Truth be told, we have numerous bodies of knowledge and ‘methodology soup,’ as your author cites. • Funny that certain words are ‘owned’ by some of these bodies of knowledge.

  12. Tacit Knowledge and its Emergence • The values in the Manifesto do not include key business concepts such as ROI, NPV, etc. • No hard management science in the Manifesto. • Agile is much more just a statement of values. • This is why some term Agile as a ‘movement.’ • We try to pass on what are thought to be ‘universal truths.’ • The methodologists and adherents assert that this is the way software ought to be developed. • These values seem to be guides as to what / how to proceed.

  13. Tacit Knowledge and its Emergence • Some interesting points: • Some oppose adoption of these values due to personal / profit issues. • Some of the values run very contrary to ‘traditional’ approaches and methodologies in place such as documentation, testing, etc. • Some purists are interested in only the pure interpretations and the sacredness of the values and principles for their own sake. • Some advocates of Agile feel the need to recognizerisks in Agile and move it beyond a tacit level of understanding’ and make it a reality.

  14. Research and Reports • Many research and reports: Gartner; Standish Group • Standish categorizes projects as • Successful – projects completed on time, within budget, and meeting all features and functions as originally specified. • Challenged – projects completed and operational but over budget, over time estimated and frequently offering fewer features / functions than originally specified. • Failed – project cancelled somewhere along the line. • The Standish Chaos Report indicates more projects were successful than failed, but many more were ‘challenged.’ • Let’s look at some of the results.

  15. Standish Chaos Report – Successful Projects • Smaller project milestones were key to successful project outcomes. • This is consistent with the Manifesto values • The two top reasons for Successful Projects: • 1. User involvement and engagement, and • 2. Executive Management Support. • 3&4. Clear Statement of Requirements followed by Proper Planning

  16. Standish Chaos Report –Challenged Projects • Top Factors for Challenged Projects • 1. Lack of User Input! (This was FIRST!!) • 2. Incomplete Requirements (no great surprise!) • 3. Changing Requirements • 4. Lack of Executive Support • Note that the values of the Manifesto directly address all of these.

  17. Standish Chaos Reports- Failed Projects • Top Factors for Failed Projects • 1. Incomplete Requirements • 2. Lack of User Involvement • 3. Lack of Resources • 4. Unrealistic Expectations The Agile values, with emphases on working software, customer collaboration, and responding to change also appear to directly address these factors. Certainly delivering working software frequently and working with the customer to embrace change address these failure issues!

  18. In Closing • Please be aware that there are many flavors of Agile. • Many methodologies claim they embrace some or many of the agile values (and principles) • Unified Process has several agile features that can be used; • Scrum is probably the most popular Agile approach. • XP is also very popular for smaller projects, although there are many who say it does scale to larger projects. • And there are others…..

  19. Closing Remark • Agile is a philosophy – statements of value and suggested practices that claim to address many of the root problems in software engineering

More Related