Some lessons for agile software development

Written by: NetworkError, on 08-01-2013 17:51
Last update: 11-01-2013 10:04
Published in: Public, Technical Wootness
Views: 6122

I've been working as a Tech Lead with one foot in the Product Management world for a while now. I've had successes and failures. Here are some lessons I've learned. (I could write a whole essay on this, but I think it would just cause word inflation and dilute the point.) I'm primarily keeping this as a reference for myself and will update it with new lessons learned. Hopefully others will find some useful gems here.

Some principals of good software development:

  • Plan using these tools:
    • A concise list of specific requirements <-- Should focus on what goals you want to accomplish and why.
    • Stories to fulfill each requirement <-- Should focus on how you want to accomplish each goal; talk exclusively about behaviors. (Build a walking skeleton out of real 3x5 cards or stickies - the sense of touch and spacial awareness are powerful memory tools.)
    • Talk about implementation details and get on the same page, but don't get too hung up on it yet
    • A high-level architecture diagram <-- Very helpful any time you need to explain your project to someone else
    • Also: Gut-check your skeleton regularly
  • Don't over-plan or get hung up on details. Instead, iterate and refactor. Once you get started:
    • Assign stories piece-by-piece, sprint by sprint
    • Leave the specific implementation specs up to the developers. Document and stay synced as you go. (Document all public inputs and outputs rigorously.)
  • Stick to the essentials. Leave nice-to-haves completely off the table; they'll only distract you. This should be a litmus test for every feature, story, task, and change request:
    • "It's not the daily increase but daily decrease. Hack away at the unessential." --Bruce Lee
  • No new functionality should be checked in without an accompanying test (unit, module, integration...)
    • Tests should be written first. (Start red.) Code should be written to satisfy them. (Go green.) Iterate and refactor. (Loop: Red -> Green -> Refactor)
  • All modules within a given silo should live behind a service layer. Keep your silos small-ish. No back-doors or direct access to files/dbs. Period. (Case study: Amazon.)
  • QA should be able to construct their tests based off your stories and the docs written by developers as they implement.
    • Development should automated testing for all behaviors and units. QA should primarily focus on exploratory testing, and reviewing the test automation.

Read more... User comments (1)   |   Print   |   Send to friend