Each morning for the next four days, I will post about the previous day and hope to provide some interesting insights on how the team is trying to improve their estimation! See Day 0, Day 1, Day 2, Day 3 and Day 4 here!
What have you tried that works or doesn’t work?!
Monday brought a few development concerns. Our Sr. Engineer was still getting his computer up and running. Also, Monday is Tesseract day.
Tesseract is Amrock Technology’s “innovation time” – the idea made famous by Google’s 20% time. Tesseract time is Monday afternoons and allows tech team members to work on anything related to self-learning, building innovative solutions and generally finding time to improve your skills.
Why is this important to this post? It takes half a day away from our development time (in a good way).
After starting the day, we laid out our goals with Tesseract in mind
- Check in the messaging functionality
- Also need to add a column in the database
- Build an on/off config switch for this message functionality
- UI Fix for how information is displayed
After talking about our goals our team had a great discussion about our “internal code complete” which I touched on in Day 0. The BA asked if we were trying to hit Tuesday end of day internal team code complete. A few challenges and ideas came from the team
- We talked about spending time testing for two days (how we used to do things)
- Challenge to this – if we have tests in place (especially if using TDD), we shouldn’t need two days for testing
- Realistically, we aren’t using TDD on some of this work due to the work it would take to get all the testing in place (mocks/fakes) for stories that are much older – we were using TDD on a new project at the start of this build, for our messaging story
- The topic of fixing things came up and using two days to fix things
- Challenge to this – if we are breaking things down into smaller chunks and checking work in earlier, we should shrink this “two days” down because we are getting faster feedback when we check in early and often
- Also, if we are writing tests (unit and integration) as we go we should know how we are doing as the build goes on
My take away from this – IT’S REALLY HARD TO BREAK AWAY FROM OLD HABITS! Habits form and they make you comfortable, even if they don’t create the desired outcome like we tried in the past. Leaders should challenge our own habits and our team’s habits, when we believe there is a better way because we aren’t seeing successful outcomes. Also, leaders should empower their team members to challenge these habits, because they may have a different point of view of the issue.
How did we do with the shorter day? (note how little we aimed to achieve this day because we looked at our schedule and knew we only had a morning or so of development time)
- Message story was checked in and pending reviews from our DBAs and engineers
- On/Off switch for the messaging was checked in
- UI fixes were worked on but not completed
- Retro was pretty short due to the shorter development day
- Remote computers seem to have space issue
- Two engineers are having hard drive space issues, which is causing issues for them because they need to delete files before they really can move forward
- They mentioned how even after they delete the files the space gets filled back up pretty quickly, which is interesting because maybe there is something specific to how remote computers sync with our network compared to how in-office computers work. Anyway, this is one of those fun problems that pops up from time to time but can be pretty disruptive
On to the next day 🙂
(Featured Image Credit: https://medium.com/@JimWexler/the-science-of-habit-breaking-e3fe6177599d)