Some lessons for agile software development

Written by NetworkError, on 08-01-2013 17:51
Views 6016

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.

Last update: 11-01-2013 10:04

Published in : Public, Technical Wootness

Users' Comments (1)
Posted by Nonsense, on 08-04-2013 20:48, IP, Registered
1. Scrum bags and managers
I agree with your insight.  
The company I work for is transitioning from waterfall to an agile system using scrum. In general, I think this is a good idea but the success of this system is in everyone understanding their role and resisting the temptation to overstep. Exhibit 'A', a Project Manager who is also Scrum Master. That itself, is not a problem. He constantly gets hung up on following scrum to the most specific techniques, while also getting hung up on implementation details from the developers.  
Product Manager != Project Manager != Scrum Master
» Report this comment to administrator
» Reply to this comment...

Add your comment

mXcomment 1.0.7 © 2007-2018 - visualclinic.fr
License Creative Commons - Some rights reserved