1. Misconceptions about Agile Development ALSO KNOWN AS «STEP AWAY FROM THAT JOB ADVERT!»

2. How I’m going to bore you tonight: A quick overview of the Agile Manifesto The main course: myths and misconceptions Who, what and why do these misconceptions hurt The 12 principles of Agile Development Tell me your stories! Myths and misconceptions that you have met …and you can argue with me in front of a pint at the pub

3. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: 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 left more. Published in February 2001

4. Mandatory Dilbert Tax:

5. Myth 1 Agile is “new” (alias, “not mature”) Facts: In 1970, Tom Gilb publishes the concept of EVO (evolutionary project management) Lightweight software development methods date back to 1990 In 1995 SCRUM is born in 1996, Crystal Clear and eXtreme Programming In 1997, feature-driven development The Agile Manifesto was published in 2001

6. Myth 2 Agile means not having to write documentation Facts: Releasing a Working Software is more important than writing extensive documentation, but not a replacement “Documentation” is not just a page on a Wiki: Unit Tests, when written properly, can be an effective way to document the code Some day, someone will pick up your work to maintain it. Document its features, FFS!

7. Myth 3 We’re doing SCRUM (or Kanban), that means we’re agile Facts: Scrum was designed to be used by Agile teams, but by itself it’s not sufficient to make your process agile It’s actually very easy to use SCRUM within a Waterfall process (Kanban less so, but still possible). Search your feelings: you know it to be true. Agile focuses on reducing process; SCRUM and Kanban are still processes: abusing them goes against the principles of Agile development

8. Bonus Dilbert Tax!

9. Myth 4 Agile is not suited for large projects Facts: Agile development typically follows the Iterative Approach rather than the Incremental Approach At every cycle, the product or the prototype must be “working” before adding a new feature (= new cycle) There are more “abandoned” large waterfall projects than large agile projects Even with waterfall, the end result usually differs quite a lot from the original plan

10. Bonus Dilbert Tax!

11. Myth 5 Agile doesn’t work in fixed budget projects Facts: Larger projects tend to blow up the budget – the larger the scope, the more the budget will be blown up It’s a common occurrence in waterfall projects as well The problem is not Agile: the problem is mixing fixed budget to oversized scope

12. Myth 6 There’s only one way to “be Agile” Facts: Agile is a set of principles, not a set of rules Going “by the book” is a good way to get introduced to Agile by using proven and tested processes and tools Each team is different! Do you feel like SCRUM is not for you? Do you think that Kanban doesn’t help you? Invent your own process!

13. Myth 7 Agile means “no design” Facts: Design in Agile evolves with the product There is no big, upfront design phase Instead, it’s spread across the entire development cycle, tackling design issues only when they show up Technical Excellence and Good Design enhance agility

14. Myth 8 Agile is just for developers Facts: Agile principles revolve around software development, not developers Creating and delivering a software involves different kinds of expertise, including management, testing, customer relations… If only the developers follow agile principles, the whole process is NOT agile (imagine having an elastic jumping mat inside a box made of concrete)

15. Bonus Dilbert Tax!

16. Myth 9 Agile teams don’t need to be managed Facts: Agile processes promote the use of self-organising teams Self-organising != Self-managing Management is still beneficial if not necessary, but must shift focus: defining the goals, prioritising features, act as “domain safeguard”

17. Myth 10 Agile processes are all about change Facts: The Agile principles encourage change where there is a need to adapt or there is a chance to improve At the same time, change for the sake of changing is not beneficial to any team The real focus is constant improvement, not constant change

18. Who (or what) is damaged by these misconceptions? Let’s look back at our Dilbert tax

20. The victims THE DEVELOPERS Missing specifications Lack of coordination with other teams and management Lack of product ownership Lack of engagement with the business values High turnover Lost knowledge

21. The victims THE MANAGEMENT Missed deadlines Budgets get blown up Projects get abandoned because too slow/too expensive Architectures, specifications and assumptions eventually MUST be re-written from scratch Developers leave

22. The victims THE PRODUCT Bad practices, hacks and “temporary fixes” No documentation, aka “How the f#çK does this work?” Bugs Never completed or canceled

23. The victims THE CUSTOMER Poor user experience Missing features Features not needed Late delivery of the product …or not delivered at all

24. The 12 Agile Principles BECAUSE THE AGILE MANIFESTO IS MORE THAN JUST A SLOGAN

25. Customer satisfaction by early and continuous delivery of valuable software Welcome changing requirements, even in late development Working software is delivered frequently (weeks rather than months) Close, daily cooperation between business people and developers Projects are built around motivated individuals, who should be trusted Face-to-face conversation is the best form of communication (co-location) Working software is the principal measure of progress Sustainable development, able to maintain a constant pace Continuous attention to technical excellence and good design Simplicity—the art of maximizing the amount of work not done—is essential Best architectures, requirements, and designs emerge from self-organizing teams Regularly, the team reflects on how to become more effective, and adjusts accordingly

26. What is “Agile” then? Agile is a mindset defined by values, guided by principles, and manifested through many different practices. Ahmed Sidky, Executive VP, Santeon