Actions in ATT Pipe
What is the purpose of this session?
Have a retro on the development pipe - understand what’s working / not working, ideas etc and sharing the love’
What outcomes/deliverables do we want?
Who is facilitating? Rachel
Who is scribing? Kirsten
Summary:
Positive
- issues are clear with templates / bite-sized pieces
- clearer issues and stories
- huge improvements - inclusive, collective & transparaent
- people are handling the demands so gracefully
- there is always work to pick up
- good process on tech debt and sys admin
- great for focus and deliver space
- general quality - this is an amazing, high quality team with tech, product skills etc - very motivating
- smooth testing
- lively and exciting - i remember when whole days with no one else online, and now lots of activity all the time
- we are building and delivering things AND we include tech debt - we’re not just driven by sales people and who shouted loudest. (Previous job - affected quality for team and we kept losing people)
- super mindset in terms of team, open to every suggestion, take time to listen to suggestions
- awesome delivery pace - meaningful release every 2 weeks is awesome and amazing
- categorisation of the issues - we show this off because the issues are so well triaged that anyone can jump in “in regard to github issues, the best project I’ve seen ever”
- how well synced product and devs are
- dev team, awesome discussions and reach agreement quite easily - every one is open to discuss and change their minds no problem
- spree upgrade is team effort
- whole people - we bring our intelligence, emotions, intuition all brought to the job
- as a non-it guy - the team is so strong that you can help us a lot
Negative
- Bottlenecks . . everywhere
- Severity / priorities of ‘bugs’ are hackable
- so many demands in community
- wishlist -> inception can be information overwhelm
- hard to balance t - need more balance between features and bus
- inception process only when there is space in the pipe
- spree dependency
- zenhub columns - i hate them - can be very overwhelming and people a bit lost
- dev ready column - maybe 10 things in it is too optimistic
- notfications / information too overwhelming
- takes too long to prepare a release - compared to other stuff it’s taking too much time
- i feel like our pipe is hampered because we have these ‘old style’ features that we can’t get rid of - want to see the pipe at 100% of possible quality
- toggl - we don’t have a clear view of how our resources (hence money) is spent
- some things get stuck in beta for ever
- outside the tech pipe - get a sense of clash between tech and product and it feels uncomfortable, but then you don’t get the understanding of when it is resolved / everyone’s loved up etc
- can be difficult to measure how hard you are working - hard to communicate that you are working a lot
Ideas
- ok to do little things
- handover of tasks?
- closing epics: subs, PI
- now - API column in zenhub?
- bring all the things to the pipe
- better DOD (definition of done) space
- software architecture and tech debt (silicon valley 40% of budget)
- information management - need to ping people so they know what to look for
- release -> comms translation
- dev comms strategy
Sharing the Love
Everyone!! see picture
- thank you for trusting me to do my job
- thanks everyone for doing the impossible - when I think of the situation at early 2017 it’s amazing how far we’ve come
- trust in ourselves and each other
- respect
- courage and openness
- fun and humour
- collective intelligence (beehive) - things emerging from our collective brains, both remotely and especially when we’re together
- express my gratitude to this network - you are helping me a lot to feel I’m in my ideal world
Actions
- Better DOD / closing epics - Myriam , Rachel
- Balance - tech debt / product / things devs want to do or don’t - % tech debt, we have already set some balance. Also bring sys admin / operations into the pipe - Luis, Rachel, Myriam, Danni
- Communicating externally what the dev team does, and what the new features are. A better comms strategy to developer community to attract devs. and internal - that devs get better feedback from users, including product and instance managers by devs demonstrating their work (release review) - Pau, Rachel, Jen
- Information management
- Devs picking up issues across timezones - put note in wiki to say “post in slack if you want someone else to pick your issue up overnight” - Maikel
- Delivery train meeting - ALL DEVS must be there, and if you can’t you MUST send an update beforehand about where you’re up to - on slack delivery-train channel - Pau to update on wiki ‘team commitment’ page . .
- Pipe hacks - keep discussing bug severity in the bug channel and calling out pipe hack when we see it
- Toggl Actions
- Pau is in charge, he will create new projects to match activities
- Pau will bring summary / info to delivery pipe check-in
