Building on my experience at Westfield Labs, this presentation explores how implementing a Service Oriented Architecture allowed Westfield to embrace a Lean, Agile approach to Product delivery.
Presentation was originally delivered to CTO Summit Sydney
https://ti.to/startup-cto-summit/sydney
Our Engineering team was stuck on Rails 2.3.5, architecture had become stagnant. Change was needed!
75% Cucumber/BDD code coverage
100% unit test coverage
At least 15 hours worth of tests end to end
Jenkins for parallel processing still took at least an hour
Legacy of poorly written and/or Flaky tests a maintenance nightmare
Engineers given “Tablets of stone” requirements from above
Bug Tsar was required to manage and prioritise the hundreds of outsanding bugs
Huge overhead of Feature prioritisation meetings and negotiated commitment
Points not treated as abstract by management
Process of cut Release Candidate > Regression Test > Patch every Sprint caused large overhead and delays to release code.
Late entry to ‘production-like’ environment meant issues around content/scale/usabilty etc are discovered late
‘The Business’ meaning marketing, the guys that are paying - note, see http://vertical-slice.com/2014/05/19/we-are-the-business/
What the business wants is always simple, it’s the implementation that is hard
We didn’t have all the answers, that was accepted. We needed to discover them.
Achieve a goal rather than complete a task
Team should be able to unblock itself
A cross functional team may consist of the following: UX/BA/VD/Ops/FED/BED/SME
A developer should always be able to hold the project in his head – the architecture needs to be separated into discrete components
With separation of services separation of scope and ownership becomes much easier.
It is very difficult to achieve X-func teams, autonomy and quick iterations without a decoupled architecture which allows it.
Defining done as “Released to production” focuses the mind
Create a culture where engineers cannot hand over sub-standard work to QA
Who is responsible for quality in a Traditional Cycle
With great power comes great responsibility
BDD can protect you from poor abstractions but it’s slow and expensive
Automate heavily across crucial areas such as Payments or brittle areas such as maps. Less so on edge cases
Sometimes it’s cheaper to find and fix a bug in production than support test automation overhead
See http://vertical-slice.com/2014/02/15/the-philosophy-of-continuous-deployment/
An SOA enables the abstractions and behavioural changes that allow small changes to be released fast. This enables Continuous Delivery.
Encourage the team to ask why they are implementing a piece of work and measure it’s success
Small iterations make greater collaboration a necessity
Ops have to give up control so collaborate closely with engineers
Engineers accept they are on call for operational issues
At Westfield Labs there was great collaboration on a Release Pipeline application built by QA/Engineers/Ops
Asking QA’s not to take responsibility for functional testing actually seemed to reduce bugs
Bugs given parity with features when being prioritised by the team
Less bugs, less bug management
Smaller, more focused teams meant the team implicitly understood bugs, saving time on bureaucracy
Stable, steady output of measured enhancements
Points abolished, commitment reached far more often
Features tended to grow out of a series of minor enhancements toward a larger goal rather than lurching forward then stabilising afterward
Don’t have teams structured by functional silo
Don’t leave Continuous Delivery to your Engineering team, it must be collaborative across all areas of the business