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!
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.”
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/
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
20. Build for Speed - Questions?
gareth.evans@hypr.co.nz
@gareth__evans
@HyprNZ
Hinweis der Redaktion
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.