1

What are the key parts of agile, if any, that would help me as a SWE? What's your working strategy?

Profile picture
Engineering Manager at Mistplay5 months ago

Does anyone like agile or what do you keep in mind when trying to ship something big? Or what about when you're kicking off a new project?

22
3

Discussion

(3 comments)
  • 1
    Profile picture
    Staff Eng @ Google, Ex-Meta SWE, Ex-Amazon SDM/SDE
    5 months ago

    When trying to ship something big, I am most concerned with knowing what the first step is we can take, how many independent/parallel work streams there are, and what decisions can be made early to keep those streams running as independently as possible.

    Certainly knowing what you’re supposed to build is critical, but something like exact UI design shouldn’t block you building the data aggregator. The exact format of a service reply from a dependency shouldn’t stop you from creating your business logic or persistence layer. What the expiration policy is for retention of your data shouldn’t block design approval.

    If you really need a single design to rule them all for the whole system, you should still devolve most of the details to design docs scoped at a module or service at largest. The big picture can compose these, and show overall data flow, have blocks for caches and storage, etc, but semantics of calls or locking or something should be in a lower level design. Having sub-owners for each of these designs, and giving those individuals ownership of implementation (with you possibly owning one, but contributing where need is most) helps further make things run in parallel.

    For me this isn’t like… what methodology or what rituals you perform, it is about having the fewest number of blocking dependencies as possible. If a decision can be made later, make it later. If a decision isn’t terminal/one-way, make it with less data and do so early, knowing you can change course later when the new information arrives.

    Last thing I can think of is to start any review you need (design, privacy, security, data, whatever) at the start of the project, and provide the assets as needed. Get these done as soon as you can. Waiting until code complete makes this a huge serial effort when you have the least wiggle room. If any of these trigger required changes, the sooner you know the cheaper it is to fix. Again, if you can decompose these to module or service level, instead of needing a single reviewer that groks a giant system, that’s great.

    So really, what I think the “good parts” of Agile or Scrum or whatever are isn’t like… having a standup or whatever, it is not trying to write requirements in stone with every possible contingency covered, then starting coding, then doing iterative testing, then doing documentation, then doing internal reviews. Doing least-informed decision making, working on all stages in parallel, and changing course as soon as something is known, tends to go way better.

    • 0
      Profile picture
      Engineering Manager [OP]
      Mistplay
      5 months ago

      Amazingly helpful to get your perspective here. Thanks!

  • 0
    Profile picture
    Engineering Manager [OP]
    Mistplay
    5 months ago

    My take: it is helpful to try to ask questions immediately when something is unclear, ship a piece of it asap, retrospect, and keep the cycle going.

    Also generally I feel waiting for engineers to first look at a problem after non-engineers have planned it out completely from their side is not going to go well.

Mistplay is a loyalty app for mobile gamers. Our highly engaged community is made up of millions of users looking to discover new games and earn as they play. We reward users for the time and money they spend within the games they download from our platform, and they can redeem those rewards for gift cards.
Mistplay9 questions