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
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
How do you know? • User stories • Estimation of complexity • Perceived value to customers • Chores (stories with direct business value to customers) 12 Build
Minimum Viable Product • Establish your product/ market fit. • Interaction model (how users use your app). • Mental model (how users perceive your app). 13 Build
Myth of MVP • Minimum to prove the value proposition. • Usually smaller, less complex than what u think. • Minimize waste, destruction of value. 14 Build
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
4) Validate • Communication plan • Analytics • Success metrics (what does success looks like, indicators) • Working software != deliver customer value 33
… 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
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
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
miccheng
ivargrimstad
yamotuki
stewemetal
taowata
mot_techtalk
amixedcolor
nozaki
twada
yatasunshine
shimabox
hazumirr
peaceiris
kastner
malarkey
yeseniaperezcruz
maltzj
morganepeng
eileencodes
garrettdimon
thekraken
holman
scottboms