Build for Speed - Gareth Evans - AgileNZ 2017
•
1 j'aime•360 vues
In collaboration with Callaghan Innovation, Hypr have created the Build for Speed programme to help companies deliver value to customers faster. About Gareth Evans: Gareth has over 16 years experience in the IT industry, including more than a decade in London working in investment banking and media as a technologist, team leader and software coach. He holds an MSc in computer science and was one of the first people in the world to become a Scaled Agile Framework Program Consultant Trainer (SPCT). Gareth is a speaker at NZ and international events including LSSC, Agile Australia and Agile New Zealand. Gareth co-founded Hypr to champion Agile architecture and lean software delivery for the benefit of the New Zealand software industry. He loves learning with others, music, travel and code!
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Build for Speed - Gareth Evans - AgileNZ 2017
Similaire à Build for Speed - Gareth Evans - AgileNZ 2017 (20)
Dernier
Dernier (18)
Build for Speed - Gareth Evans - AgileNZ 2017
- 1. Build for Speed Gareth Evans @gareth__evans https://hypr.nz
- 4. NZ Software Product Companies https://s3.amazonaws.com/startupcompass-public/StartupGenomeReport1_Why_Startups_Succeed_v2.pdf
- 5. Build for Speed Improvement Model
- 6. Results - Speed to 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 “Recent studies 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 companies had 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 have time 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 “Production incidents 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 Quality Through Collaboration
- 12. Continuous Delivery ● Poor or 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
- 17. The Good News We are 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 Story Points for Breakfast Leadership that develops people scales best
- 19. What really matters? Ability of founders and teams to learn. Technical Agility Business Agility
- 20. Build for Speed - Questions? gareth.evans@hypr.co.nz @gareth__evans @HyprNZ
Notes de l'éditeur
- Around 30 companies
- 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
- 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.
- 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
- Val
- C7 - iL
- 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.
- Sen - KP
- iL-Track
- New ideas encouraged from everyone Experimentation without fear of failure Time to learn Transparency Communication Leadership focuses on developing people
- You can sense a good culture when you walk in the room.