Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Product Development (from the perspective of a software engineer)

Product Development (from the perspective of a software engineer)

Presented at Founder Institute

Michael Cheng

October 09, 2014
Tweet

More Decks by Michael Cheng

Other Decks in Technology

Transcript

  1. From the perspective of a software engineer
    Product Development
    1

    View Slide

  2. Michael Cheng
    Software Engineer, Neo Innovation Inc.
    http://twitter.com/coderkungfu
    http://github.com/miccheng
    http://CoderKungfu.com
    2

    View Slide

  3. 6 Tips for Managing
    Development Teams
    Cos they make your startup tick.
    3

    View Slide

  4. Managing a development
    team
    1. Clear directions (you point, we fire).
    2. Validation events (communicate what
    metric do you want to move).
    3. No kitchen sink wish list please.
    Prioritize. 

    (eg. 70 half-baked/broken features vs 17 fully usable
    features.)
    4

    View Slide

  5. Managing a development
    team
    4. Use project management tools to
    optimise visibility on progress for the
    whole team. (eg. Pivotal Tracker)
    5. Continuous delivery lets you move and
    test your features faster.
    6. Test Driven Development gives you
    stable software (most of the time).
    5

    View Slide

  6. “Good” Team Management
    • Build a self-organising team - processes
    for continuous, rapid innovation
    • Visibility of progress of everyone
    • Automate as much as possible
    • Sustainable product development as
    renewing cycles
    6

    View Slide

  7. Managing a Team
    • Processes for rapid innovations
    • Get your strong & opinionated engineers to
    agree on a process for working together.
    • Trust in a process, not just people.
    • Model for sustainable/continuous growth
    • Industry best practices for *NOT* burning out.
    7

    View Slide

  8. Agile Development
    Methodologies
    • Small batch approach to development.
    • Feature requirements structured as a story of
    how user will use the app.
    • Building features in small rapid iterations.
    • Cycle to Test > Build > Feedback. Repeat.
    • Working app every step of the way.
    8
    Processes for rapid innovation

    View Slide

  9. Test Driven Development
    9
    Processes for rapid innovation

    View Slide

  10. Pair Programming
    • 2 programmers, 2 sets of keyboard & mouse, 1 computer
    (preferably with 1 massive monitor).
    • Counter-intuitive way of improving productivity.
    • Sharing the mental load in writing code.
    • 2 pair of eyes focused on a small batch of code changes.
    • Immediate code-review at time of writing. Improves
    code quality.
    • Tag-team approach to writing unit tests and codes to
    pass the test.
    10
    Processes for rapid innovation

    View Slide

  11. Pair Programming
    11
    Processes for rapid innovation

    View Slide

  12. Kanban-Style Project
    Management
    • During the sprint, your team should establish the
    different "stages" that your code changes goes
    through.
    • Eg. Test is written, code is written, code passes
    tests, deliver to the server for acceptance by
    product owner, accepted by product owner, await
    deployment to production. Deploy to production.
    • Just-In-Time development.
    12
    Processes for rapid innovation

    View Slide

  13. Kanban-Style Project
    Management
    13
    Processes for rapid innovation

    View Slide

  14. Continuous Integration
    • Teams working on code together have a tendency of
    stepping on each other's "toes".
    • The sooner you discover the code conflicts and clashes,
    the better is is for your team.
    • An automated script that pulls together code from
    everyone in your dev team, runs automated tests on
    the code, and return the result. Merge conflicts,
    breaking tests, etc. can be discovered quickly and fixed
    (instead of at day of launch).
    14
    Processes for rapid innovation

    View Slide

  15. 15
    Processes for rapid innovation

    View Slide

  16. Continuous Deployment
    • Once code is ready, app can be deployed
    automatically without human intervention.
    • Minimizes bad deployment due to human errors.
    16
    Processes for rapid innovation

    View Slide

  17. Metric Driven Features
    • Features and changes based on measuring and
    discovering how users are interacting with your
    app.
    • Validated learning that leads to feature changes
    and/or pivots.
    17
    Model for sustainable growth

    View Slide

  18. Agile development as
    renewing cycles
    • Agile dev life cycles can be characterized as
    "low-high-low intensity".
    • The low intensity periods are meant for planning
    and reflection.
    18
    Model for sustainable growth

    View Slide

  19. Agile development as renewing cycles
    Iteration Planning Meeting
    • Structure your feature changes in phases. We
    sometimes call this an "Iteration". This can last
    between 2-4 weeks.
    • As product owner, you decide on the features u wish
    to see.
    • The whole team comes together for an iteration
    planning meeting (IPM) where we discuss the features
    in more details and discover the complexities involved.
    19
    Model for sustainable growth

    View Slide

  20. Planning Poker
    • A good way to determine complexity is via Planning
    Poker.
    • Each team member is given a deck of cards (usually with
    numbers in Fibonacci progression).
    20
    Agile development as renewing cycles
    Model for sustainable growth

    View Slide

  21. Planning Poker
    • After discussing a feature in detail, the Product Manager ask
    for their assessment - the team members will put up a card
    from their deck with a number, signifying what they perceive
    to be the complexity of the feature.
    • The median number shall be the assigned complexity point.
    • More discussion can be had if there is a high difference
    between the perceived complexity points given by team
    members.
    • This could be a sign that they do not completely understand
    the requirements.
    21
    Agile development as renewing cycles
    Model for sustainable growth

    View Slide

  22. Retrospective
    • After each sprint, you wind down the
    intense period with a "Retrospective"
    - a kind of post-mortem/evaluation
    on the sprint.
    • This is a good time for you to
    discover weaknesses in your process.
    • It also allows your team to
    understand each other's working
    style better.
    22
    Agile development as renewing cycles
    Model for sustainable growth

    View Slide

  23. Questions?
    23

    View Slide