Uploaded byAgileNZ Conference
Build for Speed - Gareth Evans - AgileNZ 2017
The document discusses the improvements in software development speed and quality for NZ software product companies, highlighting a reduction in release cycles from two months to two days and a doubling of development velocity. It addresses challenges related to technical debt, code maintainability, and the importance of continuous delivery and collaborative practices. Overall, it emphasizes the innovation and cultural advancements in the industry, with a focus on leadership that fosters learning and adaptability.
More Related Content
Similar to Build for Speed - Gareth Evans - AgileNZ 2017
Build for Speed - Gareth Evans - AgileNZ 2017
- 1. Build for Speed GarethEvans @gareth__evans https://hypr.nz
- 3.
- 4. NZ Software ProductCompanies https://s3.amazonaws.com/startupcompass-public/StartupGenomeReport1_Why_Startups_Succeed_v2.pdf
- 5. Build for SpeedImprovement Model
- 6. Results - Speedto Value “Release cycle down from “2 months to 2 days.” “20x faster to develop specific components.” “Can now do production releases on same day.” “Velocity has doubled in the last 6 months. Over that time, the team has grown from 12 to 14 developers.” “Velocity more stable and predictable. Now we always deliver in a sprint”
- 7. Startups Make Tradeoffs “Recentstudies have indicated this overall “hidden” cost of technical debt in the $1 trillion range in the US. But this is only the tip of the iceberg when looking at the total financial impact.” http://jimhighsmith.com/the-financial-implications-of-technical-debt/
- 8. Architecture ● All companieshad issues with technical debt ● Some scale fail ● Code smells and consequences i.e. comprehension and maintainability ● Key person risk http://www.industriallogic.com/wp-content/uploads/2005/09/smellstorefactorings.pdf
- 9. “We don’t havetime to write unit tests” “We tried unit testing but it didn’t work” “Our quality is good (without test automation)” Quality and the ice cream cone of death... https://www.thoughtworks.com/insights/blog/architecting-continuous-delivery
- 10. Results - Quality “Productionincidents half of what they were.” “Test automation coverage up to 70% in newer projects.” “Test coverage of new components is 60-70% compared to 4% for old code” “5 projects have automated deployment - deployments no longer disruptive” “20x faster to develop specific components.”
- 11. Left Shifting QualityThrough Collaboration
- 12. Continuous Delivery ● Pooror occasionally no source control ● Long-lived physical branches ● Some with limited CI but all lacked automation around deployment ● Very few companies ran micro tests on the build server ● Packaging and versioning was sometimes handled badly ● Few ensured that a single build artefact was used in each environment through to production ● No acceptance testshttps://concourse.ci/
- 13. Continuous Delivery &Technical Practices
- 14. Problems with Flow- The Leadership Challenge ● No common language ● Project thinking ● Not visualising work ● Unclear prioritisation ● Long queues ● Large batch size ● Too much WIP ● Delays ● Slow feedback ● Centralised control ● No measurement
- 15.
- 16.
- 17. The Good News Weare seeing incredible innovation. We are seeing companies improve over time. We are starting to see better architectures, technical practices and cultures emerge.
- 18. Culture Eats StoryPoints for Breakfast Leadership that develops people scales best
- 19. What really matters? Abilityof founders and teams to learn. Technical Agility Business Agility
- 20. Build for Speed- Questions? gareth.evans@hypr.co.nz @gareth__evans @HyprNZ
Editor's Notes
- #6 Around 30 companies
- #8 Not just something that happens overnight when you are a large company - it creeps up on you More step wise based around company growth and hiring - brooks law etc
- #9 All companies had issues with technical debt at the code level. This ranged from minor to serious, often with the worst in older code. Almost no developers had an understanding of code smells and their impact on the time/cost required to understand and extend or fix code. Smells include modularity, dependencies, naming, and lack of duplication. Few companies had any test coverage and none had test automation across their whole code base. Good developer-level test automation enables fast evolution of software to meet business demand. Lack of code sharing and knowledge of deployments resulted in key-person risk Many had issues at the architectural level, with serious difficulties in scaling well to handle hoped-for growth of customers. Some companies were not using an ORM for database access. Many of the companies doing front-end development work with Javascript had very weak tooling and little test automation for this.
- #10 All companies had problems with code qualtiy. Some companies spent up to 50% of time fixing bugs - it is much easier to go fast if it does not have to work. Few companies had layered test automation Too much manual testing Silos & hardening Not enough collaborative specification leading to rework
- #12 Val
- #14 C7 - iL
- #15 Too much rework, unmanaged non-strategic work, ad hoc changes of focus Many did not understand the impact of delays. Many lacked a shared understanding of work, flow and dependencies at an organisational level. Many companies had problems that arose from a project-oriented approach to software development, rather than a product-based approach. Requirements All companies had issues with confusion in the language used to describe both process and requirements, leading to poor communication. Planning at multiple levels was often missing. Only some of the teams knew what was going on. Planning and Prioritisation Most suffered from a lack of clear prioritisation, lacking clear communication of the likely relative business impact of different pieces of work. In some companies, the person who shouted the loudest got to the top of list of features to complete. Some had difficulty balancing customisation per client while retaining the integrity of the core product. None of those companies took clear account of the longer term costs due to the added software complexity.
- #16 Sen - KP
- #17 iL-Track
- #19 New ideas encouraged from everyone Experimentation without fear of failure Time to learn Transparency Communication Leadership focuses on developing people
- #20 You can sense a good culture when you walk in the room.