Agile vs. Waterfall/Meeting Notes 2019-06-10

From SOBAC Wiki
Jump to navigation Jump to search

Agile vs. Waterfall

Date
Monday, 10 June 2019 from 7:00pm to 9:00pm iCal
Meetup Event
https://www.meetup.com/NetSquared-Kitchener-Waterloo/events/261791510/
Location
Room 1301 -- Conrad Grebel University College, 140 Westmount Rd. N., Waterloo, Ontario Map


Do you manage projects? Software development projects? Are they big projects or small projects? Are there many or few developers? Is it complex software or easy to understand? Are you developing for external customers or your own organization? Are there many opportunities for testing or only a few? Can you develop new code while testing, or is development dependent on test results? Are transient coding errors tolerated or not? Do you need Agile or Waterfall Development?

Let's discuss different coding methodologies with Darcy Casselman and Eric Gerlach, Senior Director at Oracle/Netsuite. We'll have our regular Round Table discussion, where we can all contribute our expertise.


--Marc Paré, Steve Izma & Bob Jonkman




Resources

TechSoup Canada catalogue

Waterfall Vs. Agile: Must Know Differences


Meeting Notes

  • Introductions

Guests:

    • Eric Gerlach is a senior director at Netsuite
    • Darcy Casselman is a senior developer at Netsuite and organizer with MakerExpo
What is TechSoup?
  • Software distribution company, many different vendors
    • Microsoft, Netsuite, Adobe, &c.
    • TechSoup matches NonProfits with vendors, manages licenses, ensures non-profit registgration status
    • Why not free (no cost)? TechSoup still has costs, and license payments ensure less proliferation of unlicensed software
Introduction to Agile Development
  • Book by Gil Broza, a local Canadian "Agile Luminary" -- The Agile Mindset


  • The Agile mindset (not the book) has become less "elite".


  • Traditional development techniques give you what you asked for, not what you wanted
    • Also gives you nothing until the project is entirely complete


  • Donald Rumsfeld's "Unknown Unknowns" -- he was so right when it comes to software development (not so much for political situations)


  • Agile Mindset -- Values:
    • People first, before product and process
    • Adaptation
    • Early and frequent value delivery
    • Customer collaboration


  • Agility is not the perfect solution for every situation, it is a way to achieve a certain goal.


  • Waterfall Mindset -- Values:
    • Make early commitments
    • Get it right the first time
    • Deliver on time and on budget
    • Process comes first, before product and people


  • Government is super waterfall! (experienced voices who have worked in government concur)


  • Is Agile vs. Waterfall dependent on the size of the organization?
    • Maybe true for government, is it true for very large organizations?
    • Agile interaction enhances the skill set of the people
    • Corporate (and Government) management styles have not kept up with management styles in project management
    • But eg. Amazon's software development process, including budgeting, is very agile
    • We don't know what a fully Agile large corporation would look like (yet)
    • Is the budget process responsible for process-bound governments and corporations? eg. yearly budget cycle, or based on 3-4 year election cycle.
    • Failing frequently: Better to fail at ten different $100,000 points in the project, rather than once at $100,000,000 point in the project


  • Graf von Moltke: "No plan extends with any certainty beyond the first contact with hostile forces"
    • So you want to build in a much higher ability to adapt, revise quickly, learn quickly.


  • Classic Waterfall failure: Government of Canada's Phoenix payroll system
    • In spite of rollout problems on the first day, the rollout was continued (no adaptation)
    • The first year (2016) cost of failure was $50,000,000. Still ongoing today.
    • Payroll in insanely complex...
    • Netsuite's HR and payroll software is aimed at smaller businesses, not something the size of Phoenix


  • Risk-based development: Riskstorming (like brainstorming for risks)
    • Risk mitigation strategy: Ask for e-mail address (or money) before a product exists (ensures there is interest in the project, and worthwhile continuing)
    • For non-profit orgs, a small financial outlay may be overwhelming, so do risk mitigation


  • 68% of IT projects fail
    • Traditional response: Plan more! More detail! (costs & time increase)


  • People First: Theory X and Theory Y
    • Motivation (external, internal)
    • Responsibility (none, lots)
    • Money (only important thing, not as important as doing good)
    • Non-profits tend to fall into Theory Y


  • Software development is a people skill
    • Diagnosing personal interactions to build better software
    • Software development is a team sport (esp. in large organization)


  • Early and frequent value delivery -- What is "value"?
    • Early startups doing things that don't scale, eg. AirBNB using paper forms for client matching
    • But they're delivering value, not software
    • Other examples of manual processes that eventually automated, a la Mechanical Turks
  • Agile has frequent points of value delivery, even if the cost of that value is less than the cost of the development to that point
    • Eventually, the value exceeds the cost (at the completion of the project)


  • Does modularity have anything to do with it, rather than monolithic design?
    • Modularity goes to frequent value delivery, and smaller costs of failure
    • Modularity goes towards the people thing, since people can work more autonomously


  • Philosophy of design has been around for a long time, not solved yet.
    • Modular vs. monolithic
    • These days the monolithic design is pushed to the side
    • Sometimes companies discard monolithic design too quickly
    • Advantage of monolithic: There is only one thing to manage!


  • Customer Collaboration
    • Google Wave: A solution to a problem that didn't exist
      • Had they talked to anyone, they might have realized no-one wanted it
    • Color photosharing app
      • No-one understood how it worked
      • Could have been the results of a requirements document: "The program must do this thing" and it does, but...


  • The customer is a member of the development team
    • Traditional picture has the customer sitting beside the developer
    • Constant communication!


  • What's the difference between Agile and a mini-Waterfall approach?
    • As the Waterfalls become smaller and smaller they begin to look more like Agile
    • But Agile still needs customer consultation, iteration, value delivery
    • An overall Waterfall approach could still have Agile at the micro level


  • What do we give up with Agility?
    • Predictability, lower cost, no rework, uniform work processes, comfort, consistency, easy thinking
    • and break-neck speed development


  • Agility requires more creativity, waterfall can rely on rote work


  • Agile is not "better, faster, cheaper", it is only "better"
    • Perhaps in the long run it is faster and cheaper too


  • Agile requires developers' self-examination, looking at yourself as working in a team
    • This is hard, not everyone is successful


  • Project manager: Maybe lose some velocity if you're delivering the right thing.
    • Working faster may deliver something faster, but is that the right thing?


  • Detailed mockups get less demanding feedback from customers
    • Back-of-napkin designs may get criticized for small details, not relevant to the issues you're looking for


  • Project management tools like Timeline and MS-Project tend to encourage Waterfall approaches to projects


  • Tools for Agile Project managers:
    • Trello (small, super simple, basically free)
    • JIRA (pretty heavyweight)
    • Rally (not recommended)
    • Pivotal Tracker
    • TAIGA (Open Source)



Back to: Agile vs. Waterfall

Retrieved from "https://sobac.com/mediawiki/index.php?title=Agile_vs._Waterfall/Meeting_Notes_2019-06-10&oldid=2377"