Context
- recently started work in an enterprise company
- work could be called platform engineering
- mostly work with pipelines, managing the operations for the downstream application, ensuring optimal developer experience for application developers, managing the developer portal (we use Tyk), integrating with observability services (ELK), quarkus extension monorepo for downstream applications (we only support quarkus applications)
- based on that, it already sounds like quite a lot, there is still more that i wont list, but my point is just that we're not maintaining like 3 applications in total, which is more similar to the work that i used to do before, there is a lot of context switching required in my current job
Planning
- scrum is good, i enjoyed using it a lot in smaller teams
- however now i am in a big team (20-40 people)
- scrum is difficult to employ in the format that i was used to
- so this required me to figure out a way to manage the work
How to manage the work and plan better
- there are always some questions coming in from people that work on the periphery of the services we employ within our team
- these are usually hard to plan
- additionally, since i still feel relatively new due to the complexity of the environments we work with, planning is also difficult to do when people just kind of go with it, during scrum rituals
- the size of our team doesn't help here
- so in order to plan appropriately;
- when someone asks question
- figure out if big task or small task
- if big task,
- create ticket
- inform person that asked the question
- plan it with team
- if small task,
- just do it if you have time
- otherwise, create ticket!!
- yeah thats it, just create the tickets
- if people say but nothing gets done, that's just not true
- this works for me because i dont want to not do it, i like my work
- but i cant do everything all at once
- i need to focus and id rather not context switch too often
Why create tickets? What are the benefits of this
- this gives you the opportunity to go over it with your team during scrum rituals
- ideally should cover blind spots, which, as someone relatively new, is usually nice
- the scrum rituals in our work are at regular intervals, and everyone is present anyway, so why not use it to your own benefit
- additionally, makes it clear to the person that asked the question that their request is being taken further or something like that - which is better than forgetting to do the thing because you're already busy with many other things
end
- its nice if this brain dump helps anyone