Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Don't scale agile. Descale your organisation.

•
•

The document discusses descaling organizations to be more agile. It advocates for descaling by moving away from centralized functional teams and long-term planning towards autonomous product/feature teams that own the entire process. This allows organizations to adapt quickly, improve resilience, and scale in a sustainable way. The key aspects of descaling discussed are leadership, product development, testing, operations, design, infrastructure, finance, and workplace.

1 of 14
Don't scale Agile. ‘Descale’ your organisation. Stuart Bargon. Agile Product Lead @ Domain
Scaling agile approaches Alignment Organisation Autonomy Consultants, Certifications & tools Built in control Do agile Some examples but mostly ‘new’ companies Built in resilience Be agile
Don't scale agile. Descale your organisation.
Some History • PMO • Steering committees • Long term resource planning • Centralised functional teams • Shared network resources • Many different frameworks • Days to do a release • Volumes of policies
Today • Product / Feature Teams • Multiple releases in a day • ‘Domain’ Employees • Own whole process • Improving architecture • Adapt quickly to changes • Dedicated ‘team areas’
OpsUX / Design Descale the company Leadership Product Development TestingPMO Leadership Product Development TestingPMOMobileMobile OpsUX / Design Finance HR InfrastructureHR Infrastructure Finance DevOps
Descale the product
Don't scale agile. Descale your organisation.
Descaling coordination/ projects “Think in terms of federations and partnerships instead of armies.” James O. Coplien. @jcoplien
Descale the technology
Descaling Finance
Descale the workplace
Retrospect, things I’d do differently “Grow your business — not your teams.” Alex Lope- Bello
About me Stuart Bargon stuart@domain.com.au sbargon@gmail.com Twitter: @StuartBargon

More Related Content

Don't scale agile. Descale your organisation.

Editor's Notes

  1. Things have changed a lot in fairfax as well, this is just to give some background.
  2. Give examples. People started updating their apps, and by the evening when peak time hit we started having issues. Images were loading on mobile devices but very, very slowly. we were able to transform a struggling service into a very performant and scalable one in one day. See tech.domain.com.au for full story. Domain “Rewards program” Release evolution
  3. Key Functions Leadership: Vision for alignment Product: Invested heavily Development: Existing devs, struggle with change. Testing: Focus and gain in depth knowledge, migrate to advisor role. PMO: Finish existing projects, reduce amount of change. Ultimately decided that projects didn’t suit the way we wanted to work going forward, discuss removal. Teams: Formed teams… UX: Design had multiple personalities from all the project work in the past. Formed styleguide etc then joined teams Ops: Work with queues and queues kill agility. HR: Developed our own ‘values’ and working on other improvement like Performance reviews etc. Finance: Changed from reporting on projects to value delivered. Light weight processes for reporting (capex opex, r&d) Infra: Ultimate control, can spin up when needed.
  4. Headspace Maintenance
  5. Simplifying usability
  6. Evolving to be more autonomous Scrum o Scrum’s Team’s own cross team work by forming a partnership not a project.
  7. ----- Meeting Notes (16/06/15 15:54) ----- Multiple app and products in on big lump of code
  8. Removed upfront guess work Lightweight reporting using labels in jira
  9. Dedicated desks Poster on cupboards Closer