Common Myths about Agile

Description

This presentation gives an overview of some of the common myths about Agile. I have touchec on what according to me and a brief literature review are some of the common myths. There are many more and we might do a second presentation pretty soon. Although I have tried to make it very simple, it would probably make more sense when I present it online, which I would do soon :-)

Comments
Would you like to comment?

Sign In if already a member, or Join Now for a free account.

Presentation Transcript Presentation Transcript

Common Myths about Agile : Common Myths about Agile Beyond non-agile, 100% agile, practical agile and complex agile …

Myth #1 It's a silver bullet that will solve all your problems : Myth #1 It's a silver bullet that will solve all your problems Straight forward Extreme Effectiveness

Radically different way : Radically different way Make mistakes, but sooner This is not an answer to incompetence or poor organization Producing high-quality, maintainable code is a deliberate process There are no short cuts to excellence You also need a proper structure Product Owner/ Marketing Leadership Process Coach Self Organizing Teams

Myth 2:Using Agile means that you can do what you like. : Myth 2:Using Agile means that you can do what you like.

It is highly disciplined approach : It is highly disciplined approach Discipline is not paper pushing , compliance and bureaucracy. At any point the team is working on the thing that the Product Owner wants most. You can not violate the values in spirit or letter. It requires much greater discipline to stay focused on high-value activities in too dynamic a context. Key Responsibility Areas: Product Owner – success of the product The Team – technical architecture of the product Process Coach/ Manager – the team and value creation

It is highly disciplined approach : It is highly disciplined approach Keeping designs simple and minimally sufficient Demonstrating transparency Refactoring code to avoid redundancy and duplication Writing tests first Continuously integrating Releasing shippable product on a regular cadence Arguing the best idea while letting go of ego

Myth 3: Doing Agile means no Architecture or Planning : Myth 3: Doing Agile means no Architecture or Planning

Just-in-time : Just-in-time All upfront planning comes with a huge risk and tremendous amount of waste Requirements Change because Market Changes 67% or more features originally planned are never used Distributed planning and just in time analysis Postpone decisions to last effective moment – Use Concurrent Engineering/ Set based Concurrent Engineering Approach [Lean] Test the architecture upfront and regularly Continuous Integration Unit Testing Shared Code

Myth 4: Agile does not work with CMMi : Myth 4: Agile does not work with CMMi

What is the value? : What is the value? Focus of CMMi – Repeatability Focus of Agile – Sustainability Validation/ Appraisal for CMMi – Evidence Many requirements can be met in creative ways, such as taking pictures or making videos and filing them with indicative names Ton’s of metrics you can track in Agile projects – one’s which provide direct value Automated collection of data

Myth 5: Agile approaches means avoiding commitments – price and schedule. : Myth 5: Agile approaches means avoiding commitments – price and schedule.

A different take : A different take Agile trades the illusion of control and predictability [and crystal ball gazing] for transparency and quality. Hard dates and price control can not work with one side control. Estimates derived on basis of past projects and complicated formula's are still “estimates”. Use Agile Collaboration Schemas

Myth 6:Using TDD (writing tests first) doubles the amount of work. : Myth 6:Using TDD (writing tests first) doubles the amount of work.

Did you actually try it out? : Did you actually try it out? Test suite serves as an unambiguous external description of system’s intent, design, and usage. Writing tests first fleshes out uncertain designs. It provides a robust regression suite. You can make changes to the code easily. Defects introduced into the code stream are caught quickly, and are isolated immediately, preventing propagation. The resulting designs are generally simpler and easier to implement.

Myth 7:Agile is just an iterative and incremental process. : Myth 7:Agile is just an iterative and incremental process.

You need a reality check : You need a reality check Agile is tough and each role fits in like a Jigsaw Goal of Agile -> Outcomes over features : Product Owner Sustainability : The Team Process Competence: Scrum Master/ Agile Coach

Some Others … : Some Others … Agile means no documentation You need a very experienced team for Agile Anyone can be a Scrum Master or Product Owner Refactoring is cleaning up bad code There is no role for Managers in Agile Outsourcing and Agile are anti-thesis Agile does not support diversity

Agile is not a new fad : Agile is not a new fad It's based in thinking and writing of many renowned people and industry experience. A recent Forrester Research report on agile development discusses that: Agile development processes are already in use in 14 percent of North American and European enterprises, Another 19 percent of enterprises either are interested in adopting agile or already are planning to do so.

Slide 20 : a”gile is the widely accepted umbrella term … agile is the ability to create and respond to change. agile is the ability to balance flexibility and structure. agile is something you strive for, not do.

Slide 21 : Early and continuous delivery of working software Welcome changing requirements Build projects around motivated individuals Give them the environment and support they need Trust them to get the job done Self-organizing teams Team reflects on how to become more effective Face-to-face conversations Continuous attention to technical excellence and good design Working software is the primary measure of progress Sustainable development

61 Members Recommend this Teacher
Copyrights © 2009 authorGEN. All rights reserved.