Agile software development for startups


Published on

This is a presentation made to Surge Accelerator in Houston in March 2013. This serves as a Guide to Early Stage Technology Companies, building enterprise class software.
This covers the typical lifecycle of a software start-up, fundamentals of Agile software development, and some do's and don't for how to build successful software companies.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile software development for startups

  1. 1. Building Enterprise Class Software A Guide to Early Stage Technology Companies March 2013
  2. 2. Topics for Discussion1. Lifecycle of a software start-up2. Realities of software development3. Key decision points4. SummaryConfidential
  3. 3. Lifecycle of Software StartupCompanyMaturity (HC,Rev, etc.) Idea Incubation Time in Years > 1 yr. Bootstrap, Seed A-Round B-Round Angel Round ~$4M ~$4M ~$200K ~$0.5M Confidential
  4. 4. Topics for Discussion1. Lifecycle of a technology start-up2. Realities of software development3. Key decision points4. SummaryConfidential
  5. 5. Building Software is Complex • Unlike other engineeringEvolving/Changing Inherent R&D Nature of disciplines (e.g. manuf, bldgBusiness Requirements Software Development const), building software is• Multiple, inconsistent inputs • Software performance issues harder and more complex• Change is usually good though • Changing/New technologies • If not managed properly, a lot can go wrong! • Needs to be properly managed – with appropriate level of process discipline • Agile approach works very Technology EnvironmentDistributed Teams well in most cases with Many Moving PartsNeeding to Collaborate • Dependence on external • Team communications technology components –HW/SW • Need for complementary skills • Constantly changing environment Confidential
  6. 6. What is Agile?Agile approach accounts for unique nature of softwaredevelopment. It is a…•software project management approach that encouragesdelivering in short cycles, with frequent inspection, feedback,and adaptation•leadership philosophy that encourages team-work, selforganization, and accountability at team level•disciplined engineering approach to softwaredevelopment that results in rapid delivery of high qualitysoftware•business approach that focuses on delivery real businessvalue (=customer needs) above all.Various flavors are practiced – SCRUM, XP, Kanban etc.Confidential
  7. 7. Agile Manifesto - 2001“We are uncovering better ways of developing software bydoing it and helping others do it. Through this work we havecome to value: – Individuals and interactions over processes and tools – Working software over comprehensive documentation – Customer collaboration over contract negotiation – Responding to change over following a planThat is, while there is value in the items on the right, we valuethe items on the left more.”Kent Beck Mike Beedle Arie van BennekumAlistair Cockburn Ward Cunningham Martin FowlerJames Grenning Jim Highsmith Andrew HuntRon Jeffries Jon Kern Brian MarickRobert C. Martin Steve Mellor Ken SchwaberJeff Sutherland Dave ThomasConfidential
  8. 8. Waterfall Approach • 6+ month • Too linear, with no learning/feedback cycle • Expects all requirements upfront • No value based prioritization of features • Often results in over engineering • Often testing/quality compromisedConfidential
  9. 9. Agile Approach • First working software in 4 weeks or less • Emphasis on learning/feedback • Embraces changing/evolving requirements • Consistent focus on high-value features • “Just-enough” engineering, with emphasis on frequent refactoring • Focus on repeated testing/qualityConfidential
  10. 10. SW Triad – Conventional vs. AgileConventional Iron triad of Scope x Cost x Schedule should be replaced byValue x Quality x Constraints SCOPE VALUE COST SCHEDULE QUALITY CONSTRAINTS • Cost • ScheduleConfidential
  11. 11. Agile Development CyclesConfidential
  12. 12. But, Agile is Not a Panacea• Following Agile approach greatly helps but is not a panacea• “Lip Service Agile” can be worse – more chaos, no net business value!• All involved (business, dev, etc) need to understand the nature of software development and have realistic expectations• Ensure proper team composition – Same person can play multiple roles – But, all roles need to be covered – Be realistic about skill fit of the person playing a roleConfidential
  13. 13. Agile Myths • Agile = No documentation • Agile = No planning • Agile = No commitment on scope of work to be delivered • Agile = No need for upfront requirements gathering • Agile = No software discipline/rigor • Agile = No budget • Agile = A rigorous process defined in a set of 3-ring bindersConfidential
  14. 14. When You Can Do Without Agile• When you know (for sure) all the requirements upfront – and, for some reason (e.g. regulatory constraints), they can’t change/evolve• No technology risk at all• But, still there is benefit of building software in short cyclesConfidential
  15. 15. Team Structure For SuccessNeeds to • Idea owner, drives long-term productbe close to roadmapcustomers VISIONARY • Passionate, evangelizes the idea • But, can’t “write” detailed reqs • May not understand software dev process and get easily frustrated PRODUCT MGR DEV MGR SW ARCHITECT PRODUCT OWNER DEVELOPER ARCHITECT Can be Offshore/ Remote QA DEVELOPER ARCHITECT• Understands the vision, and writes • Seasoned development manager • Seasoned software technologist –requirements – owns delivery plan – resource, makes effective design trade-offs, time, scope, risk lays technical foundation• Understands domain, specificcustomers/users, competitors, etc • Pushes back on Prod Mgr to • Works with dev team on design manage scope• Detail oriented, analytical • Owns short-term and long-term • Great people manager technology roadmap• Defines scope of eachiteration/release, owns QA Confidential
  16. 16. Strive For Stable Teams• As far as possible, keep your software team stable• Don’t stop and start teams – High churn has huge negative impact – It is better to have a smaller team, but stable – Real IP is in the heads of team members, no amount of documentation can replace itConfidential
  17. 17. Bug Free Software?• There is no such thing as “bug free” software?• Plan for proper test/QA process and capacity – In very early stages, market feedback is more important than software quality – In later stages, software quality is far more important than pace of new features• Plan for automated QAConfidential
  18. 18. Software is Never “Done”• If you have users, software will keep evolving• Bugs will keep showing up• Current customers will keep asking for new features• New customers will demand new features• Performance will need to be enhanced• Technology will keep evolving, requiring you to keep up• You should actively refactor code, improve usability on a regular basis• So, plan for an on-going, stable engineering teamConfidential
  19. 19. Topics for Discussion1. Lifecycle of a technology start-up2. Realities of software development3. Key decision points4. SummaryConfidential
  20. 20. Key Decisions Start Start Is software a NO Consider Consider significant outsourcing outsourcing Is software NO value? the core value prop? YES Can find & Build small local NO YES Build small local attract talent team team locally? Have CTO Consider Consider YES YES as co- Build initial Build initial offshore/ offshore/ founder? software version software version outsourcing outsourcing Have NO sufficient Acquire initial Acquire initial NO capital? customers customers Find one Find one YES Need to YES expand Expand locally Expand locally team? NO Continue customer Continue customer acquisition acquisitionConfidential
  21. 21. Why Outsource?1. You need software development and delivery skills (process or specific technologies), that you don’t have in-house2. Required talent difficult to hire (locally)3. Peaks and valleys in your need, e.g. QA/Testing4. Capital constraintsConfidential
  22. 22. When Outsourcing…• Look for a “partner”, rather than a “vendor” – Trust based, collaborative partnership – Specific skills, good software development process – Longer term relationship – Stable teams• Be very careful of paying dev partner with equity – Raise capital from professional investors, e.g. VCs – For software development, engage with a professional software dev company• Maintain ownership of your IPConfidential
  23. 23. Topics for Discussion1. Lifecycle of a technology start-up2. Realities of software development3. Key decision points4. SummaryConfidential
  24. 24. Summary1. Building enterprise software is complex undertaking, plan appropriately2. When outsourcing, still maintain leadership in-house – Product vision and roadmap – Software architecture/engineering leadership1. In almost all cases, Agile is the way to go2. Software is actually never “Done” – plan for ongoing burn rate in your financialsConfidential
  25. 25. AppendixConfidential
  26. 26. Basic Hygiene For SW Dev1. Requirements need to be written.2. Each requirement should be accompanied by an acceptance test case. In fact, acceptance test case is more important than English prose format of requirements.3. Use ONE issue tracking system. Everybody looks at the same system. No spreadsheets.4. Source code control system – needs to be ONE.Confidential
  27. 27. Tools and Processes• Requirement Analysis – User Story Detailing – Effort Estimation and Commitment – Requirement/Functionality validation: POCs• Development – Processes: Code Reviews, Frequent Check-ins; Code Branching and Merge synchronized with sprint demos • Source Code Control and Build Tools Used: CVS, SVN, GIT • Other Tools used: Jprofiler, JMeter – Continuous Build Automation: Daily Builds and periodic automated deployment • Tools Used: Ant, Maven, Cruise Control, Hudson, LuntBuild – Coding efficiency: Predictability based on sprint commitments using team velocity established over first 2-3 sprintsConfidential
  28. 28. Tools and Processes• Development (contd.) – Unit Testing: sprint deliverables are Unit Tested • Tools: Junit• Testing – Process: Work in-step with developers and create test cases – Regression Testing: incremental development of the suite, executing towards end of each sprint – Bug tracking tools: Bugzilla, JIRA – Test Case Management Tools: TestLink, Test Director – Test Automation: we recommend adding a small team of automation engineers to automate the regression test suite.Confidential
  29. 29. Tools and Processes• Deployment – UAT: maintain UAT environment; Define and develop UAT test suite by identifying specific end to end tests – UAT deployment: planned and periodic – Bug Scrubs: Regular bug review and re-prioritization• Progress Tracking: – Tracking: Daily Updates to Issue tracker, Weekly Status Reports – Issue tracking tools: JIRA(with grasshopper plug-in), Rally• Communication: – Conference calls: at the frequency required (daily…weekly) – Wiki: Maintaining a document repositoryConfidential
  30. 30. Contact Us – Austin, Dallas, San Jose• Hemant Elhence (Dallas, TX) – – Office: 469.322.0349 – Mobile: 214.762.4873• Subu Sankara (San Jose, CA) – – Mobile: 510.579.9673•• Development center in Pune, IndiaConfidential