Downloaded 10 times
More Related Content
Similar to Introducing Agile to the Enterprise
Introducing Agile to the Enterprise
- 1. Introducing Agile tothe Enterprise Getting your company to give up the Gantt chart and learn to love software development
- 2. Who Am I? •Kendall Miller • One of the Founders of Gibraltar Software – Small Independent Software Vendor Founded in 2008 – Developers of VistaDB and Gibraltar – Engineers, not Sales People • Enterprise Systems Architect & Developer since 1995 • BSE in Computer Engineering, University of Illinois Urbana-Champaign (UIUC) • Twitter: @KendallMiller
- 3. What Do WeDo? The easy-to-deploy, SQL Server- compatible, pure .NET embedded database. Advanced logging and analysis of errors, performance, and usage patterns for .NET web apps, desktop apps and services
- 4.
- 5. Development Team
- 6. Development Team
- 7.
- 8. Why Agile? • No idea or control over cost or schedule • Constant rework and re-testing • Ongoing distractions • Contention between business units
- 9. Agile Manifesto Individuals andInteractions Processes and Tools
- 10. Agile Manifesto Working Software Comprehensive Documentation
- 11. Agile Manifesto Customer Collaboration Contract Negotiation
- 12. Agile Manifesto Responding toChange Following a Plan
- 13. Hard Stop Agile Isn’tCoding Without a Plan or Requirements
- 14. “I love thatyou were able to demo functionality so early on and make the changes we wanted. Now you just need to tell us exactly when the remaining functionality will be completed” - A Senior Program Manager
- 15. “You built exactlywhat we asked for, but now that we see it, it’s all wrong. Can you do redo it in the next two weeks?.. .. Why can’t you say when everything else will get done?” - A Senior Customer Stakeholder
- 16. Business Goals • Create and Follow a Plan • Predictable Cost and Schedule • Clear agreements between parties • Clear accountability • Easy status reporting and monitoring
- 17. How’d We GetHere?
- 18. How’d we gethere? Control Cost through Eliminating Waste • Code once • Test once • Don’t code unnecessary stuff
- 19. How’d we gethere? Processes Embody a Method to Achieve A Goal Follow the process and you can’t help but achieve the goal
- 20. How’d we gethere? Processes are a Surrogate for the Goal • Hard to argue against doing things • No one is really sure what would happen if they were changed or removed
- 21. How’d we gethere? Processes Stand In for Trust • I can trust the Process not the People • We can Blame the Process • Easier than doing the hard work of Managing your People
- 22. Hard Stop Political ProblemsCan’t be Solved with your Software Development Process
- 23.
- 24. Process Organization Fit Risk NASA
- 25. Process Organization Fit Risk Typical Enterprise
- 26. Hard Stop The higher the P/R ratio, the more management Buy-in you must have
- 27. Is Agile aFit for my Shop?
- 28. Organization Fit Values Results over Compliance • Can you read the Agile Manifesto without laughing? • Organization needs to Want to Ship
- 29. Organization Fit Can see unfinished work • Without punishment for it being unfinished
- 30. Organization Fit Can Collaborate across Teams • Everyone it takes to build the solution • Everyone it takes to publish the solution
- 31. Organization Fit How Much Trust? • Find a project team that has the trust of the business and go with them first. • Less trust requires more formal agreements (until Agile is impossible)
- 32. Hard Stop If youcan’t find the Team and the Project, it’s the wrong Time.
- 33. Selling Agile tothe Business
- 34. Agile Selling Points YouWill get Everything you Need • We’re working on your most important items (says you) each sprint
- 35. Agile Selling Points You have a Buying Choice every Sprint • If it’s good enough, we can stop • If it’s no longer a good investment, we can stop
- 36. Agile Selling Points We can change on a dime • How often does your business climate change? • How transformative is the project?
- 37. Agile Selling Points No surprises on what it does • No disappointment it isn’t all you hoped for
- 38. Agile Selling Points Build confidence in the Solution instead of the Process • No disappointment it isn’t all you hoped for • Nothing beats real users with real data on real servers
- 39.
- 40. Agile Selling Pointsthat Fail Lower Cost • Visible rework and chaos
- 41. Agile Selling Pointsthat Fail Done Sooner • You can’t give them date certainty • Iterations instead of measure twice cut once
- 42. Agile Selling Pointsthat Fail Higher Quality Solution • Quality is subjective • Businesses rarely prioritize User Experience over Cost & Schedule
- 43. Ways Teams SabotageAgile
- 44. Agile Anti-Patterns forDevs Not providing a Project Plan • Track interactions between development and external dependencies • Team, not individual assignments • Externally observable results
- 45. Agile Anti-Patterns forDevs Making Waterfall Promises • Work out rolling UAT options • Buffer external dependencies • Evangelize advantages of rapid iterations
- 46. Agile Anti-Patterns forDevs Ignoring Project Documentation • Document expectations and outcomes • Project History (for larger projects) • What would you want to inherit?
- 47. Agile Anti-Patterns forDevs Not Accommodating Product Feedback Immediately • Changes/Defects/New Features are equally valid for work • Get to Done-Diddly-Done-Done-Done
- 48. Critical Lessons Learned •Political problems can’t be solved by process • High Process requires Enthusiastic Management • Pick the right Team and Project
- 49. Additional Information: Websites – www.GibraltarSoftware.com – www.eSymmetrix.com Follow Up – Kendall.Miller@eSymmetrix.com – Twitter: kendallmiller
Editor's Notes
- #5 We are not going to talk about various Agile processes or their detailed implementationThe focus is on what it takes to get your organization to give you the right shot to put Agile into practice
- #6 We often think about why the development team wants Agile and what it does for the organizationFrom OUR perspective
- #7 But what really matters is how it looks from the company’s perspective
- #8 As a development team we like agile because it:Creates a process built around uncertaintyEnsure what gets built matters
- #13 Don’t Forget: it’s not that we don’t value the things on the bottom, it’s that we value the things on the top MORE
- #17 When you survey businesses about what they want from projects (software or otherwise), here’s what they respond.
- #19 They think they get all of this from Waterfall.
- #21 It was all reasonable as it wentWhy can’t you know how long to do x? Everyone else can say..In the inches it’s hard to argue against each item, have you ever answered “What are we going to do to make sure this never happens again?”No one is sure what happens if processes are changed:The implications are lost as the process is codifiedProcesses have side effects these become an “unknown unknown” risk
- #29 Any part of the organization that is not incentivized to ship will have no reason to take on the risk of change
- #30 Any part of the organization that is not incentivized to ship will have no reason to take on the risk of change
- #45 They still are the benchmark for tracking external dependencies and interacting with parties that are not operating in an Agile mode.
- #46 “Sure, we can accommodate that feedback and not change the schedule”Treating sprints as fixed scope & scheduleLeaving UAT to the End
- #48 False Progress“Revision Sprints” or other BSEach Story should be D5 to move on.