Product Development (from the perspective of a software engineer)

Presented at Founder Institute

Transcript

1. From the perspective of a software engineer Product Development 1
2. Michael Cheng
   Software Engineer, Neo Innovation Inc.
   http://twitter.com/coderkungfu
   http://github.com/miccheng http://CoderKungfu.com 2
3. 6 Tips for Managing Development Teams Cos they make your startup tick. 3
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
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
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
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
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
9. Test Driven Development 9 Processes for rapid innovation
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
11. Pair Programming 11 Processes for rapid innovation
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
13. Kanban-Style Project Management 13 Processes for rapid innovation
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
15. 15 Processes for rapid innovation
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
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
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
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
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
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
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
23. Questions? 23