Agile Product Development

Presented at Ideas Inc. startup training at *scape.

Transcript

1. Cos its cool to be lean, green and mean! Agile Product Development 1
2. Michael Cheng
   Software Engineer, Neo Innovation Inc.
   ! http://twitter.com/coderkungfu
   http://github.com/miccheng http://CoderKungfu.com 2
3. Speaker Deck 3 http://j.mp/agilepd2014 ! http://j.mp/agilepd2014-doc
4. 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
5. 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
6. Roles • Product Owner • Delivery Team • Validation (market & customers) 6
7. Lean Approach • Limited resources (time, money, people) • Value creation vs Value destruction • Find out what’s not working 7
8. Lean Approach • Small iterations of: 1. Value hypothesis, 2. Test/Metrics, 3. Build, 4. Validate 5. Repeat 8
9. 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
10. 2) Test / Metrics Test: Product does what it's supposed to do. ! ! ! Metrics: Product has the desired effects on the target audience. 10
11. 3) Build • Just do it, maybe? • What to build? • Is it the right thing to build now? 11 Build
12. How do you know? • User stories • Estimation of complexity • Perceived value to customers • Chores (stories with direct business value to customers) 12 Build
13. Minimum Viable Product • Establish your product/ market fit. • Interaction model (how users use your app). • Mental model (how users perceive your app). 13 Build
14. Myth of MVP • Minimum to prove the value proposition. • Usually smaller, less complex than what u think. • Minimize waste, destruction of value. 14 Build
15. 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
16. 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
17. 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
18. Delivery Team • Outsourcing overseas is not easy • Timezone differences • Communication • Language barrier • Cultural differences 18
19. Team Management • Self-organising team • TDD/BDD • Kanban • Tests as documentation • Retrospective (release steam) 19
20. 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
21. 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
22. Test Driven Development 22 Processes for rapid innovation
23. 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
24. 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
25. 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
26. 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
27. 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
28. 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
29. 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
30. 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
31. 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
32. 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
33. 4) Validate • Communication plan • Analytics • Success metrics (what does success looks like, indicators) • Working software != deliver customer value 33
34. 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
35. Questions? 35
36. Practice Agile Product Development Let’s Build a… 36
37. … 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
38. 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
39. 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
40. Ta da! Demo Time 40
41. Retrospective • What made you happy? • What made you sad? • What were you not sure about? 41
42. Michael Cheng
    Software Engineer, Neo Innovation Inc.
    ! http://twitter.com/coderkungfu
    http://github.com/miccheng http://CoderKungfu.com 42