Larry’s Top 10 Agile and Scrum Myths

1. Larry’s Top 10Agile and Scrum Myths Larry Apke Agile Expert www.agile-doctor.com larry@agile-doctor.com

2. Biographical Information Larry Apke is a Managing Consultant, a Certified Scrum Master (CSM) and a Certified Scrum Professional (CSP). For the last six years he has been a hands on Scrum Master for multiple companies and dozens of teams. He has give dozens of talks every year to many different groups. His two life’s passions are Agile and his family. His new gig is working as an Agile coach with USAA in San Antonio.

3. Myth #1 - Agile is a Framework/Methodology A framework is a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure into something useful. A methodology is a system of practices, techniques, procedures, and rules used by those who work in a discipline Agile is the Agile Manifesto (4 values) and the 12 agile principles - http://agilemanifesto.org/ Agile is a philosophy or a series of concepts`

4. Myth#2 - Agile Means No Documentation Agile Manifesto values states, “Working software over comprehensive documentation“ First Qualifier – Comprehensive Second Qualifier – “That is, while there is value in the items on the right, we value the items on the left more. “ What Agile is really looking for is the appropriate amount of documentation necessary for end user value – “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. “

5. Myth#3 - Agile is Less Disciplined / Easy “…early and continuous delivery of valuable software. “ “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. “ “Business people and developers must work together daily throughout the project. “ “…maintain a constant pace indefinitely. “ “At regular intervals, the team reflects on how to become more effective, then tunes and djusts its behavior accordingly.”

6. Myth#4 - You Can Achieve Agility Without Organizational Change You cannot just “do” agile, you must “be” Agile Version One Survey 2011 – Reasons for failed agile projects - 44% Due to Broader Organization Not Adopting Successfully “Lack of Understanding of Broader Organizational Change Required” – 11%, “Company Philosophy or Culture at Odds with Agile Values” – 9%, “External Pressure for Waterfall” – 8%, “Lack of Cultural Transition” – 6%, “Insufficient Training” – 5% “Lack of Management Support” – 5%

7. Myth#5 - Agile is Scrum Agile is a philosophy or set of concepts Scrum is a framework who purpose is to allow for achievement of Agile philosophy Scrum’s success is a blessing and a curse – so much so that when people even mention Agile most people automatically think of Scrum Version One Survey – 52% use Scrum only, with 68% using Scrum mixed with something else Scrum may not be the best way for a team to achieve agility

8. Myth#6 - Scrum Will Lead to “Hyperperforming” Teams As a framework simply “doing” the ceremonies around scrum will allow the team to understand the impediments in the way of the team increasing performance. Without the ability or will to change, to remove the impediments, you will merely have a greater visibility into problems. A greater visibility of problems with no solutions will only increase frustration from the team which often results in negative behaviors (and less productivity). Transparency and predictability are the immediate benefits

9. Myth #7 - You Must Get 100% of all Stories Complete or You’ve Failed Patrick Lencioni – Five Dysfunctions of a Team – First Obstacle – Absence of Trust – 100% can lead to misrepresentation So instead of trying for 10 stories and getting 9, I may try for only 7 or 8. Yes I get 100% done, but I do not get as much done. Teams will be reluctant to take stories where all is not known. Getting stories started takes longer so value is not delivered to customer. Team morale will suffer even though a viable product is being built.

10. Myth #8 - Scrum Master = Project Manager A project manager is someone who manages the project and the team and is the person accountable to the business for accomplishing the project objectives. A product owner is closest to project manager. A scrum master is a coach, a facilitator, someone who helps remove the impediments. A scrum master ensures that the scrum framework is followed. Over time a good scrum master empowers the team to a point where he or she is no longer needed.

11. Myth #9 - We Can Do Scrum Without a Product Owner or Many P.O.s A team without a P.O. has no vision, focus, etc. A P.O. owns the backlog. It is very difficult and inefficient to have multiple owners. There are numerous parties interested in what the team does – stakeholders – with competing interests. They need to speak to development with one voice. P.O. is sometimes referred to as the “single wringable neck.” While I disagree, the P.O., because they are responsible for backlog content and order, has the accountability for the direction of the team.

12. Myth #10 - With Scrum We Can Make Changes Whenever We Feel Like It Scrum is not chaos. It is a highly disciplined approach to software development. A highly functioning Scrum team will spend some time each sprint “grooming” the stories likely for the next sprint. Changes to the work planned for sprint after team has committed result in too much work, too little understanding or both. At the very least additional “emergency” work must be balanced by a corresponding reduction of planned work, ie one point in one point out. The team is responsible, the team must choose.

13. Questions