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

Agile Product Development

Agile Product Development

Presented at Ideas Inc. startup training at *scape.

Michael Cheng

July 05, 2014

More Decks by Michael Cheng

Other Decks in Programming


  1. About Me • Self-learned front-end / back-end / iOS developer

    • Building web apps since 2001 • Started Singapore PHP User Group in 2006 • Co-founded iOS Dev Scout (2012) • Worked in startups: Foound (2010) and mig33 (2012) • Joined Neo Innovation Inc. in March 2014 4
  2. What is Agile? • A process of product dev that

    is responsive to market changes & changing needs of the business in a timely and iterative fashion. 5
  3. Lean Approach • Limited resources (time, money, people) • Value

    creation vs Value destruction • Find out what’s not working 7
  4. Lean Approach • Small iterations of: 1. Value hypothesis, 2.

    Test/Metrics, 3. Build, 4. Validate 5. Repeat 8
  5. 1) Value Hypothesis • What you think customers want. •

    Customers don't know what they want. • Don't follow what they say, see what they do. • You pretty much have to measure everything. • Do you actually know your customer? • User Personas to guide your discovery process. 9
  6. 2) Test / Metrics Test: Product does what it's supposed

    to do. ! ! ! Metrics: Product has the desired effects on the target audience. 10
  7. 3) Build • Just do it, maybe? • What to

    build? • Is it the right thing to build now? 11 Build
  8. How do you know? • User stories • Estimation of

    complexity • Perceived value to customers • Chores (stories with direct business value to customers) 12 Build
  9. Minimum Viable Product • Establish your product/ market fit. •

    Interaction model (how users use your app). • Mental model (how users perceive your app). 13 Build
  10. Myth of MVP • Minimum to prove the value proposition.

    • Usually smaller, less complex than what u think. • Minimize waste, destruction of value. 14 Build
  11. Mocking Up • Modeling user experience. Flow from 1 screen

    to the next. • Low res mocks: Visualize the user interactions • High resolution mockups: Sense of proportion • Mock-ups: http://balsamiq.com/ 15 Build
  12. Delivery Team • Who’s in your Delivery Team? • Do

    you have the right delivery team in place? • Talent is hard to find. Usually not cheap in SG. Outsource overseas? • More than what you need now? 16
  13. Delivery Team • Who's the technically strongest person in your

    team? His programming language of choice is usually the fastest for your team to ramp up. • Are you willing to learn technical stuff? 17
  14. Delivery Team • Outsourcing overseas is not easy • Timezone

    differences • Communication • Language barrier • Cultural differences 18
  15. Team Management • Self-organising team • TDD/BDD • Kanban •

    Tests as documentation • Retrospective (release steam) 19
  16. 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 growth • Industry best practices for *NOT* burning out. 20
  17. 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. 21 Processes for rapid innovation
  18. 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. 23 Processes for rapid innovation
  19. 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. 24 Processes for rapid innovation
  20. 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). 25 Processes for rapid innovation
  21. Continuous Deployment • Once code is ready, app can be

    deployed automatically without human intervention. • Minimizes bad deployment due to human errors. 26 Processes for rapid innovation
  22. 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. 27 Model for sustainable growth
  23. 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. 28 Model for sustainable growth
  24. 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. 29 Model for sustainable growth
  25. 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). 30 Agile development as renewing cycles Model for sustainable growth
  26. 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. 31 Agile development as renewing cycles Model for sustainable growth
  27. 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. 32 Agile development as renewing cycles Model for sustainable growth
  28. 4) Validate • Communication plan • Analytics • Success metrics

    (what does success looks like, indicators) • Working software != deliver customer value 33
  29. 5) Repeat (or Pivot) • Mid course adjustments • Do

    it till they bite • Do it till you die (run out of cash) • Pivot (it's not working out this way) 34
  30. … Lego Animal • Form 3 teams of bio-engineers. •

    Each team will attempt to genetically create an animal that will thrive in one of the following environment: • Volcanic tropical Island • Desert oasis • Deep sea ocean floor 37
  31. Instructions • Roles: • Choose a Product Owner • The

    rest will be delivery team • Build “user” stories together (15 mins) • Estimate complexity together (5 mins) • Build (10 mins) • Acceptance meeting with product owner 38
  32. Product Owner • Define parameters of the environment • List

    animal characteristics that will thrive in that environment • Define acceptance criteria • Make sure user stories meet survival criteria 39
  33. Retrospective • What made you happy? • What made you

    sad? • What were you not sure about? 41