Dataiku Step Change

Slides (8)

1. 1 - Image Customer Science Dataiku Step Change retro

2. 2 - Qrcode

3. 3 - Freestyle Some helpful pointers for things to think about...

4. 4 - Freestyle Some helpful pointers for things to think about...

5. 5 - Freestyle

6. 6 - Freestyle

7. 7 - Ideas What went well?

   1. Code refactoring (at scale!)

   2. Daily check-in calls

   3. Co-ordination

   4. Daily/weekly updates and check ins

   5. Successful migration of 65 atm and 314 disc projects within program timelines

   6. Shared tracking document

   7. Working together to work through issues

   8. Daily meetings

   9. Clean break from EMR

   10. The team took on feedback well and made improvements during the process

   11. Daily meetings as a place to surface issues

   12. Persevering through it

   13. Daily calls

   14. We are on a new platform which gives us access to containers

   15. Proactive problem solving

   16. Jack always contactable

   17. Some great support (e.g. Jordan)

   18. It's finished...

   19. We are on the new platform

   20. The late hours to adapt to issues and resolving them.

   21. Isolation of code, no more downtime due to a single intensive script

   22. We did it

   23. Good comms between CS and DAP

   24. Now have a cleaner platform

   25. Everyone was very good at leaning into issues and adapting/responding to them when they came up

   26. Good clear communication channels set up which allowed work to progress at pace

   27. Automation migration

   28. We were kept updated about the progress of stepchange

   29. The team co-ordination and respond to the queries instantly.

   30. We got the migration delivered, eventually.

   31. Support from the step change team with queries was always great.

   32. SCI ticket picked up quickly

   33. Improved performance on EKS

   34. The new platform does enable some new capabilities.

   35. Teamwork to get projects in to new platform

   36. Friendly atmosphere

   37. Individual members of the team were happy to spend time explaining things 1-2-1 as required.

   38. Organisation of migration stages

   39. Support

   40. Team work

   41. Team collaboration and stepping up to the ask of timely validations

   42. Integration cutover has felt relatively smooth

   43. Great collaboration and support across the board.

   44. Lots of questions being asked

   45. EC2 to EKS capabilities

   46. Support from Jordan and DAP team when deadline loomed

   47. Leads and SLTs did a great job supporting CS people, DAP people and also explaining business about the impact and issues

   48. Team collaboration was fantastic throughout CS and project. All pulled together in toght timescales

   49. Git-DSS Integration delivered!

   50. We got to version 12!

   51. Great collaboration between DAP and Customer science!

   52. Customer Science dropped everything to get the migration work over the line

   53. Issues with previous ways of working made more visible (e.g. too many projects in disco, projects between us and other teams, etc)

   54. Cut over of prod project seems to have gone smooth (smoother than I thought)

   55. DAP team was very helpful and supportive

   56. Communication with the DAP team was great, the team was really helpful throughout the process

   57. Daily calls about the latest updates were helpful

   58. Easy solution for sharing datasets with/from LHA team

   59. The communication improved over the course of the project.

   60. Collab between teams Cs and Dap

   61. Raising of SCI Issues / surfacing problems

8. 8 - Ideas What can we do better next time? 

   1. Communication feedback was not taken on board

   2. Questions being asked that could be answered by spreadsheet - "what is the status of this project?"

   3. Visuals for timelines at a more detailed level.

   4. Find ways to move away from the DSS APIs for more specialised use cases. Interacting with S3 buckets is now an overcomplicated task.

   5. Endless spreadsheets with unclear meaning

   6. Planning for the worst case scenarios

   7. Spreadsheets upon spreadsheets that often times were not updated or out of sync with other forms of info.

   8. There were far too many projects to be migrated in Discovery

   9. Project comms (not individual but “top down”) were lacking

   10. Needed comms and daily meetings in place earlier

   11. Limited sharing of timelines and how each step related to the overall ask

   12. Too many spreadsheets

   13. Clear communication about planning to manage expectations

   14. Having to refactor the code multiple times.

   15. The spreadsheets were confusing and not clear

   16. Random messages about things I don't know about

   17. Contingency plans if things go wrong/issues are found

   18. Clear comms plan from the start

   19. Being asked to work on a platform when it was pretty unstable

   20. Needed an FAQ for migration

   21. Late announcement of downtime

   22. More clarity on spark tuning When are the profiles changing? What are they changing from/to? Caused confusion when your job was slower/didn’t run

   23. Projects blocked for a long time then expected to jump on it immediately, daily reports didn't acknowledge that

   24. Simplify migration tracking spreadsheets

   25. Focus on dates for delivery rather than considering capacity of CS

   26. Initially 'project migration complete' was not communicated

   27. More projects in automation would’ve helped migration

   28. Project team making decisions without any consultation

   29. We asked for a lot more projects to be migrated than was needed

   30. Migration tracker didn't always match up with JIRA

   31. The specific work required of Project owners in Customer Science for the migration should have been communicated much, much earlier to allow the impact on other deliveries to be planned for.

   32. Anticipate the issues and risks, so that we are prepared.

   33. Project owners named against blocked projects in email update

   34. Avoid Aquasec issues if possible

   35. Some projects moved across earlier than expected leading to dev work lost / had to be redone

   36. Unclear which platform we were supposed to be using during the migration, despite numerous requests for clarity

   37. Communication (often too long emails, too many asks in one email, not clear what the immediate actions were)

   38. Allocating bit more time for migration planning and testing.

   39. Feedback didn't always seem to be taken on board by project team

   40. Things often felt more reactive than proactive

   41. Cutover activities could have been better planned

   42. One to One Project migration? - We incorporated this at the end of automation project migration, where Jordan was assigned to 5-6 projects of SONAR that were interrelated and was helpful to interact with him directly (as he knows the context of them already) rather than just waiting for some one to take in the Jira tickets and explain them the whole context.

   43. Reduce bus factor

   44. Attendance in calls was varied in CS

   45. Not write models in sparklyR

   46. Possibly more of a documented approach to the requirements at an earlier stage could have achieved the end goal quicker.

   47. Clear roles & responsibilities, tool we use for tracking updates (maybe simplify it, single source of truth)

   48. Some Jira tickets not responded to then being asked why a project wasn't migrated

   49. When changes are made to ways of working they need to be owned and overcommunicated

   50. Engagement on deliverables could be better

   51. Plan!

   52. Having to copy and paste code between platforms

   53. Some dependent projects held up others, more thinking into order of migration would have helped

   54. User level IAM permissions, or power-user roles

   55. Check external system dependencies and connections earlier

   56. Don't underestimate the complexity of delivering this kind of change within Aviva.

   57. Scale of the ask could be clearer upfront

   58. Important points need to be over communicated

   59. Focus on deadlines rather than the acceptance criteria for good performance

   60. Phase tasks more (the last weeks were very intense, could some things have been done sooner?)

   61. Maybe too many calls from time to time that didn't always feel necessary

   62. Lean harder on DSS to get more helpful answers

   63. Some of the stages felt like it was being made up as the project went

   64. Knowledge transition when project ownership changes. Priority of work to align to schedule

   65. Sign off (esp. governance approvals)

   66. Too much pressure from senior leaders to get over the line leading to people working weekends

   67. Customer Science would’ve had an easier refactoring effort with cleaner code and adequate tests

   68. Line of communication was confusing - some requests sent to squad leads, some to project owners

   69. Sometimes questions were asked on the call and forgotten. Question log / action log ?

   70. Clear and detailed planning upfront

   71. . More of automation in tests and deployments,

   72. Utilise preproduction environment before making changes

   73. Code environments blocked for a long time

   74. Meetings need clear agenda and actions with associated accountabilities

   75. Daily calls should have been in place from the very start of the migration…

   76. Having to migrate projects when the platform wasn’t stable wasn’t ideal

   77. To many spreadsheets.

   78. Often lack of single source of truth - spreadsheets were often wrong.