Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The promise and peril of Agile and Lean practices

385 views

Published on

Why you may to consider adopting Agile or Lean practices, how they differ from each other, what benefits you can expect, and what obstacles you may face.

Published in: Software
  • Be the first to comment

  • Be the first to like this

The promise and peril of Agile and Lean practices

  1. 1. 8/8/2017 Wordpress Ri Meetup The promise and peril of Agile and Lean practices @mtoppa Michael Toppa www.toppa.com
  2. 2. PDF of these slides: http://bit.ly/wpri-agile-lean
  3. 3. actblue.com @mtoppa 20 years of experience in web development, project management, and functional management. I work for ActBlue Technical Services. ActBlue is nonprofit tech organization, and we build fundraising software for Democratic campaigns, and also nonprofits. * Previously: * Freelance * Director of Development, WebDevStudios * Director of Web Applications, U Penn School of Medicine * Web developer at: Georgetown University, Stanford University, E*Trade, Ask Jeeves, and the 7 person start-up, ElectNext
  4. 4. My challenge in this talk… Teach you about Agile & Lean… Without actually teaching you Agile & Lean I want to teach you about why you may want to consider them, how they differ from each other, what benefits you can expect, and what obstacles you may face
  5. 5. Tell me your problems… Agile and Lean are solutions, so first we need to talk about the problems they’re meant to solve. So we’re going to talk about a bunch of bad stuff for a while, but then we’ll get to the good stuff.
  6. 6. Features Cost Schedule 1.The iron triangle Client can pick two Quality I’ve explained the triangle to dozens of clients over the years. Programming is not magic. If the client tries to squeeze all 3 sides of the triangle, quality suffers.
  7. 7. “If you go to the store with a huge shopping list and twenty dollars, you need the authority to go to the money machine for more cash, or the authority to make changes to the list.” Ron Jeffries, Making the Date What’s happening is that the client is trying to retain authority on the project while giving you the responsibility. But ultimately, for the project to be successful and for both you and the client to be happy, responsibility and authority need to be brought into alignment.
  8. 8. Misalignment of authority and responsibility Cartoon by Mike Lynch Used with permission - Following this advise lets you cover yourself politically, and is a great way to make everyone who works for you miserable - I've found that misalignment of authority and responsibility can explain a lot of dysfunction that happens in organizations - When you have responsibility for your work but not enough authority over it, you will feel like a cog in machine To have any chance of success in the long run, you have to claim authority you may not have had previously. You may have to fight for it…
  9. 9. Source …but you have to always be professional. Think of how doctors behave in an ER. When the pressure is on is when you want them to be at their most professional.
  10. 10. 2. Multiple projects and multitasking Source Context switching between two projects eats about 20% of a full-time worker’s schedule. The sense of progress with multitasking is an illusion, compared to not multitasking
  11. 11. Source In addition to too much work, another common aspect of the Death March is not having good visibility into your workload
  12. 12. My U Penn team - too much work SWAG chart 9 developers, 2 product owners, and me supporting - 22 clients with 124 applications 3 designers and 1 product owner supporting - about 200 static content web sites Taking inventory itself was a huge undertaking
  13. 13. 3.The cone of uncertainty Source One of the greatest contributions of Agile has been getting people to more fully understand that software development by its very nature is an exploratory process.
  14. 14. “Most of the time [on a project] is spent thinking and communicating about a seemingly endless number of micro-problems that seemingly emerge out of nowhere… The only way to discover them is to encounter them one at a time, like boulders in the path of a road-laying crew. You must face each obstacle.. [and] then soldier on—only to find another boulder around the very next bend.” Jesse Watson The Hard Thing About Software Development This happens because every project you do is, in a way, a unique invention - you are building something that didn’t exist before. No matter how much time you spend gathering requirements, you will always encounter unexpected obstacles and unknowns. NBC Latino slideshow example
  15. 15. Tell me what you want… For yourself, and for your customers
  16. 16. What makes a job enjoyable? ✤ Autonomy ✤ Reward for effort ✤ Challenging/complex work “Work that fulfills these three criteria is meaningful.” – Malcolm Gladwell, “Outliers: The Story of Success”
  17. 17. “Novices believe that quality and velocity are inverse. They think that hacking is fast. They haven’t yet recognized what professional developers know all to well: …the higher the quality, the faster you go” Bob Martin, Vehement Mediocrity
  18. 18. How do we get there?
  19. 19. Add more people? Brooks’ law: ”Adding manpower to a late software project makes it later” - Fred Brooks, The Mythical Man-Month
  20. 20. Add more pressure? Source Hold the developers’ feet to the fire. This is the death march. Analogy that software development is like a washing machine.
  21. 21. “The main thing that pushed Agile and Scrum was that the success rate on traditional projects was terrible; it was 45%. If that was a car- manufacturing place, that would mean you’d throw out every other car you built.” Ken Schwaber, co-creator of Scrum, 6/21/2011 Source
  22. 22. What’s the alternative?
  23. 23. Agile solution: flip the triangle Source The traditional approach also does not take into account the “cone of uncertainty” - things will change
  24. 24. Agile: frequent feedback is key Source Rather than fight the “cone of uncertainty” we embrace it. We are always checking in to make sure what we’re delivering is what the client wants, and we’re ready to adjust priorities based on feedback. At some point we will run out of time or money, and when that time comes, we want to make sure we have delivered the most important features.
  25. 25. Lean solution: maximize “flow”
  26. 26. Agile, Lean: what’s the difference? inspect & adapt incremental & iterative; roles & rituals limit WIP; eliminate waste Agile Lean Both originate from management ideas in Japan, but Agile was created in the US software industry in the late 1990s, and Lean comes specifically from Toyota in Japan
  27. 27. Agile and Lean are Principles
  28. 28. Scrum is the most popular Agile methodology
  29. 29. Scrum is the most popular Agile methodology
  30. 30. Kanban is the most popular Lean methodology
  31. 31. Scrum is a holistic project management system Source
  32. 32. Scrum has clearly defined roles and responsibilities Source If you adopt Scrum, people’s jobs will change, at least to some extent
  33. 33. Kanban can be applied to any project management system It’s about achieving the right amount of “work in progress.”
  34. 34. Kanban takes you from this… Too much WIP can feel like a traffic jam. Covering every inch of a highway with cars is not how we achieve the capacity of the highway
  35. 35. …to this We achieve capacity when the cars flow smoothly on the road. They get to go reasonably fast, operating their engines at a good fuel efficiency. They don’t need to slam on their brakes. They don’t need to change lanes often, and there’s a safe distance between them. This is what we want our work to feel like.
  36. 36. Adopting Scrum means going all-in: big change, all at once
  37. 37. The Scrum Promise “In my Scrum classes I warn attendees of what I call the Scrum Promise: If you adopt Scrum, there will be a day you come into the office nearly in tears over how hard the change can be. This is because Scrum doesn’t solve problems, it uncovers them and puts them in our face. Then, through hard work we address them.” – Mike Cohn, Agile Trainer I didn’t know this when I led the scrum adoption at Penn, but it’s definitely true
  38. 38. Adopting Kanban leads to evolutionary change
  39. 39. Kanban foundational principles ✤ Start with what you do now ✤ Agree to pursue incremental, evolutionary change ✤ Respect the current process, roles, responsibilities & titles
  40. 40. All-in vs. evolutionary change ✤ All-in pros: ✤ Gets everyone working in the same system quickly ✤ Get good at a complete system with clear rules first, then learn where to make changes ✤ All-in cons: ✤ Near term productivity loss, confusion, resistance ✤ Can surface too many pre-existing problems at once ✤ Evolutionary pros: ✤ Minimal disruption ✤ Make changes only as needed ✤ Evolutionary cons: ✤ Easy for change process to stall and not address deeper underlying issues
  41. 41. Common ways Agile and Lean adoptions go wrong
  42. 42. 1. The top-down, lip-service approach Scrum master hiring story
  43. 43. 2. Misunderstood and/or misapplied
  44. 44. 3. Consulting environment challenges ✤ Traditional contracts require detailed plans ✤ See my Agile Contracting Philly ETE talk from last year! ✤ Who is the product owner? ✤ Clients aren’t good at it (but think they are) and probably don’t want to pay you to do it ✤ Hard to work in teams when you typically have projects that are small and simultaneous
  45. 45. Key to success: inspect and adapt Source Single loop learning is “how can we do better”? Double loop learning is “Why do we believe that?” Double loop learning means challenging fundamental assumptions
  46. 46. Afterword… You can do an evolutionary Agile adoption… But you need to know what you’re doing
  47. 47. ElectNext - I brought Agile practices to ElectNext, which was a 7 person start-up… - But only applied them selectively, as needed. - The trick to doing this is having the experience to know what practices are needed and which aren’t. - We did one week sprints, we had a prioritized backlog, daily stand-ups, and retrospectives, but we didn’t have the standard Scrum roles - What was really awesome is the whole company was Agile, not just the engineering team (sales, marketing, even the CEO).
  48. 48. Additional references ✤ “Succeeding with Agile: Software Development Using Scrum” and “Agile Estimating and Planning” by Mike Cohn ✤ “Kanban: Successful Evolutionary Change for Your Technology Business” by David J. Anderson ✤ Angry Dinosaurs: Accelerating Change and Institutional Incompetence presentation by Cory Ondrejka, Wharton Web Conference, 2010 ✤ “The Lean Startup” by Eric Ries ✤ “The Nature of Software Development” by Ron Jeffries ✤ “Specification by Example” and “Impact Mapping” by Gojko Adzic
  49. 49. Any questions? @mtoppa Michael Toppa www.toppa.com 8/8/2017 Wordress Ri Meetup

×