1 / 34

Agile execution

Agile execution. Lessons learned while re- platforming a complex system Mik Quinlan March 2014. Background – The Inventory System. the challenge: Need to migrate off the current Inventory system…. …to a future architecture:. r. The Inventory Management Platform (IMP).

delila
Télécharger la présentation

Agile execution

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Agile execution Lessons learned while re-platforming a complex system Mik Quinlan March 2014

  2. Background – The Inventory System

  3. the challenge: Need to migrate off the current Inventory system…

  4. …to a future architecture: r The Inventory Management Platform (IMP)

  5. Create a Platform: IMP version 1.0

  6. Agile Execution

  7. Key principles… • How would you approach executing the following types of software projects? • Green field development • New feature add / maintenance of a mature product • Complex legacy migration • Iterative and incremental • Introspect as much as is possible without affecting progress

  8. Structure: Phased Approach • Huge uncertainty initially • Sprint 0 doesn’t cut it • Borrowedfrom DSDM – • divide the work up into smaller pieces: • Foundations • Exploration • Engineering • Incremental Deployment

  9. Structure: Ceremony and System Complexity Be comfortable with uncertainty Source: Information Age

  10. De-risking: Go to Production early… • Early understanding of: • Application / technology in OUR organisation • Prove it works throughout all environments: • Validate features ASAP • Decreases number features in ‘ready for release but not yet proven’ state • Allows focus on features • Easier if have good automated tests Source: Growing Object Oriented Software Guided by Tests (Freeman et al)

  11. Walking Skeletons “A Walking Skeleton is the implementation of the thinnest possible slice of real functionality that we can automatically build, deploy and test end-to-end” - Alistair Cockburn in Crystal Clear: A Human Powered Methodology for Small Teams (2004)

  12. The key is in the day to day execution…(1) • Psychology of an Engineer • Team setup and iteration structure • US – EU distributed team • 1 week iterations • Small stories (IMP alpha launch: mode size = 1, median = 3) • Splitting stories – Research vs Implement • You CAN make the stories smaller! • Product and Technical decisions: • ALWAYS know your Minimum Viable Product (MVP) / Minimum Marketable Product (MMP) • Keep things simple • Defer all decisions to the last responsible moment • Take a lean approach wherever possible • Product and Technical MUST work closely, each with an appreciation and understanding of the other

  13. The key is in the day to day execution…(2) • Attention to our own Productivity: • Sharing code – re-usable libraries when it makes sense • Simplifying project setup via archetypes • Building specialised tools, e.g.: • Git branch/merge scripts • Legacy -> new platform migration tools • Specific category of story • Roles vs doing: • Everybody does QA! • Mid iteration execution: • What to do if a story is • not going to be completed? • is bigger than anticipated?

  14. The key is in the day to day execution…(3) • Fix bugs immediately! Source: http://pettermahlen.com/2011/04/

  15. The key is in the day to day execution…(4) • Continuous “Inspect and Adapt”: • Version 2.0 feed spec in current system • Feed Quality Service component • Shore up DR solution for publishing as interim primary publishing mechanism • Support: • Ownership of code all the way to production

  16. What does it mean to have small stories? • Less to carry over • PO and Lead must THINK about what is being delivered – less nebulous • Acceptance Criteria MUST be detailed as well as succinct. E.g. 1 point story: [DP] – Snapshot Service meets organisationalstandards As mycompany.com, I want to be able to deploy, configure and troubleshoot the snapshot service so that the it can integrate into the organisation’s operational environment. Acceptance criteria • Logging configuration follows the organisation’sstandard wrt access/error/console/syslog • Configurable parameters follows the organisation’s standard (properties file outside of WAR) • Packaging follows the organsiation’sstandard (deployable WAR, probably nothing to do here) • Build/archive functionality follows company standard (build and archive uses CM scripts on Jenkins) • There is a health-check that checks that the service and its dependencies are healthy. • There is an index page with the following features: • a link to the health check • a link to the configuration information • a link to the build version information • a form that allows users to submit JSON ingestion requests • Relevant statistics are exposed via JMX

  17. The largest story accepted – 5 points [Quality] Reliable VoltDB connections As mycompany.com, I want services accessing Volt to have reliable connections so that they may continue to process on the event of a cluster node or network failure. Acceptance criteria: • Services that lose the connection to VoltDB will make reconnection attempts. • A successful reconnection attempt means that the service resumes functioning correctly. • Services can start up without a running VoltDB instance. • Every lost VoltDB connection and each failed reconnection attempt is logged at ERROR level. • Lack of VoltDB connectivity should lead to failing health checks. • The reconnecting algorithm should be configurable using CM properties - so, for instance, if the chosen algorithm means that the service will make a certain number of reconnection attempts and then give up, the number of attempts to make and time interval between attempts should be CM parameters. • The blackbox tests are updated so Volt does not need to be restarted on re-deployment of a component using a Volt client Notes It is possible that we will want to contribute this code back to VoltDB, as it may benefit us if the maintenance burden for the code is shifted to VoltDB. So the code should contain as few dependencies as possible. Affected services: DI, OIDS, RDEP

  18. Technical Execution • Break the complex problem down incrementally – v1 is: • Walking skeletons • Primary Scenario (aka Happy Path) • Alternative scenarios • Sharing solutions to problems across components: • Dependency POM projects • Restricted technology stack • Solve once and share • Having a cohesive view to the solution of a problem: • Systems Architecture! • “Considered haste” • Think more, work less

  19. Continuous delivery • Story not BA’dtil it’s in Production • Small stories mean: • small changes to each release • rollbacks are minor • Helps determine what we should monitor when we move to automated Continuous Delivery: • High risk vs low risk points • Engineers own the application and this process so we better get it right!

  20. Continuous delivery and Quality • Two paths: • Low risk features • High risk features • An extensive, trusted test suite means: • Manual verification for high risk stories only • Send everything else automatically…

  21. What did not work… • Prototype stories. Instead: • Research -> stops design in planning • Primary Scenario • Alternative Scenarios • Planning was too long – sometimes 2+ hours! Instead: • Pre-planning sessions with Tech Lead, PO, QA rep • Team divide up stories to task out • External Support stories as part of the overall commitment and burndown. Instead: • Have separate [External Support] type stories with 0 points • Too many engineers on a story. Instead: • Have story owners

  22. Future goals: Agile Fluency Source: http://martinfowler.com/articles/agileFluency.html

  23. Questions?

  24. Advanced Agile Techniques

  25. When the engineering ORG is ready… • What are we trying to do? Go faster in a controlled manner • With an eye towards… Value Learning • Supported by… Continuous Delivery • Delivered by multiple teams… Scaling execution while minimising bottlenecks and Supporting each other

  26. Value learning • Know what we’re going to measure – indicators of success • Isolation of variables for a successful test • Iterate quickly

  27. CONTINUOUS delivery • Is a cultural change • Do manually first • Supported by Architecture: • Minimum: Service based architecture • Optional: Micro Services • Supported by execution strategy: • Everything is easily scriptable • E.g. run embedded Tomcat / Jetty through command line

  28. Feature toggles • Allows: • Switch on/off of experimental features • Delivery of unfinished features • APIs must be backwards compatible for clients

  29. Internal open source model • Google model? • Amazon model? • What are YOUR pre-requisites?

  30. Engineering Excellence

  31. unnecessary complexity “It’s just not necessary to do extraordinary things to get extraordinary results” Warren Buffett • Akin to Lean, but approached at a different angle • Five types: • Product • Execution • Architecture / Design • Technology • Code

  32. The pragmatic manifesto Iterative and incremental dark launch over expensive up front performance testing Features that are immediately required over features that may be required Just enough design up front over diving straight in Fact based product enhancement over theory

  33. Some principles to consider… Lean is better than Perfect Simple is better than Complex Think More, Work Less

  34. Thank you Blog: www.mikquinlan.com Follow me: @MikQuinlan Connect: www.linkedin.com/in/mikquinlan

More Related