• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Introducing Agile to the Enterprise
 

Introducing Agile to the Enterprise

on

  • 589 views

 

Statistics

Views

Total Views
589
Views on SlideShare
562
Embed Views
27

Actions

Likes
0
Downloads
7
Comments
0

1 Embed 27

http://www.scoop.it 27

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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
  • We often think about why the development team wants Agile and what it does for the organizationFrom OUR perspective
  • But what really matters is how it looks from the company’s perspective
  • As a development team we like agile because it:Creates a process built around uncertaintyEnsure what gets built matters
  • 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
  • When you survey businesses about what they want from projects (software or otherwise), here’s what they respond.
  • They think they get all of this from Waterfall.
  • 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
  • Any part of the organization that is not incentivized to ship will have no reason to take on the risk of change
  • Any part of the organization that is not incentivized to ship will have no reason to take on the risk of change
  • They still are the benchmark for tracking external dependencies and interacting with parties that are not operating in an Agile mode.
  • “Sure, we can accommodate that feedback and not change the schedule”Treating sprints as fixed scope & scheduleLeaving UAT to the End
  • False Progress“Revision Sprints” or other BSEach Story should be D5 to move on.

Introducing Agile to the Enterprise Introducing Agile to the Enterprise Presentation Transcript

  • Introducing Agile to the Enterprise Getting your company to give up the Ganttchart and learn to love software development
  • 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
  • What Do We Do?The easy-to-deploy, SQL Server-compatible, pure .NET embedded database.Advanced logging and analysis oferrors, performance, and usage patterns for.NET web apps, desktop apps and services
  • Fair Warning
  • Development Team
  • Development Team
  • Why Agile?
  • Why Agile?• No idea or control over cost or schedule• Constant rework and re-testing• Ongoing distractions• Contention between business units
  • Agile ManifestoIndividuals and Interactions Processes and Tools
  • Agile ManifestoWorking Software Comprehensive Documentation
  • Agile ManifestoCustomer Collaboration Contract Negotiation
  • Agile ManifestoResponding to Change Following a Plan
  • Hard StopAgile Isn’t Coding Without a Plan or Requirements
  • “I love that you were able to demofunctionality 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
  • “You built exactly what we asked for, but now that we see it, it’s allwrong. 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
  • Business Goals• Create and Follow a Plan• Predictable Cost and Schedule• Clear agreements between parties• Clear accountability• Easy status reporting and monitoring
  • How’d We Get Here?
  • How’d we get here? Control Cost through Eliminating Waste• Code once• Test once• Don’t code unnecessary stuff
  • How’d we get here? Processes Embody aMethod to Achieve A GoalFollow the process and you can’t help but achieve the goal
  • How’d we get here? 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
  • How’d we get here?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
  • Hard StopPolitical Problems Can’t beSolved with your Software Development Process
  • Organization FitProcess Risk
  • Process Organization Fit Risk NASA
  • Process Organization Fit Risk Typical Enterprise
  • Hard Stop The higher the P/R ratio, the moremanagement Buy-in you must have
  • Is Agile a Fit for my Shop?
  • Organization Fit Values Results over Compliance• Can you read the Agile Manifesto without laughing?• Organization needs to Want to Ship
  • Organization Fit Can see unfinished work• Without punishment for it being unfinished
  • Organization Fit Can Collaborate across Teams• Everyone it takes to build the solution• Everyone it takes to publish the solution
  • 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)
  • Hard StopIf you can’t find the Team and the Project, it’s the wrong Time.
  • Selling Agile to the Business
  • Agile Selling PointsYou Will get Everything you Need• We’re working on your most important items (says you) each sprint
  • 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
  • Agile Selling Points We can change on a dime• How often does your business climate change?• How transformative is the project?
  • Agile Selling Points No surprises on what it does• No disappointment it isn’t all you hoped for
  • Agile Selling Points Build confidence in theSolution instead of the Process• No disappointment it isn’t all you hoped for• Nothing beats real users with real data on real servers
  • Things that Don’t Sell
  • Agile Selling Points that Fail Lower Cost• Visible rework and chaos
  • Agile Selling Points that Fail Done Sooner• You can’t give them date certainty• Iterations instead of measure twice cut once
  • Agile Selling Points that Fail Higher Quality Solution• Quality is subjective• Businesses rarely prioritize User Experience over Cost & Schedule
  • Ways Teams Sabotage Agile
  • Agile Anti-Patterns for DevsNot providing a Project Plan• Track interactions between development and external dependencies• Team, not individual assignments• Externally observable results
  • Agile Anti-Patterns for Devs Making Waterfall Promises• Work out rolling UAT options• Buffer external dependencies• Evangelize advantages of rapid iterations
  • Agile Anti-Patterns for Devs Ignoring Project Documentation• Document expectations and outcomes• Project History (for larger projects)• What would you want to inherit?
  • Agile Anti-Patterns for DevsNot Accommodating Product Feedback Immediately• Changes/Defects/New Features are equally valid for work• Get to Done-Diddly-Done-Done-Done
  • Critical Lessons Learned• Political problems can’t be solved by process• High Process requires Enthusiastic Management• Pick the right Team and Project
  • Additional Information: Websites – www.GibraltarSoftware.com – www.eSymmetrix.com Follow Up – Kendall.Miller@eSymmetrix.com – Twitter: kendallmiller