day 260 — code 365

Tue 30 Aug 2016


I was given the opportunity of leading the retrospective for the sprint just finished today! This was really interesting, and it certainly made me think deeper about the process and ideas behind an Agile team. I took ideas from previous retrospectives, as well as points from the Agile coach that came to our workplace a couple of weeks ago.

I split the wall (with whiteboard-marker-safe paint!) into 2 sections — dates (10 working days, 2 sets of weekends), and a non-dated section, with the top row for high points, and the bottom row for low points. And then I had a separate column for “Other” (to do more of, to do less of, talking points), which I later renamed “Discussion points”.

I found this a really good way of placing and grouping the various Post-It notes that our team wrote down. We found it helpful to be able to place notes under specific days (if they correlated with a specific day), or in the non-dated section.

The discussion points were very helpful too, and led to good team reflection. Afterwards, I was asked to type the points into our Confluence documentation, which I was hoping to do anyway, and this was, again, an excellent way of gleaning the main points. I hope this will continue, and I can see that this can be a very powerful way of improving our team’s momentum and productivity.


I came across an interesting (well, initially, very frustrating) situation today. The ticket I picked up involved moving a section from a card below another section in that card. This actually proved quite difficult because the component was nested, and the section was inside a sibling component. Initially, the approach I took was to rework it in the way that I would have taken had I created it myself. I ran into a LOT of trouble, because of the tight coupling that various components had with each other. I ended up going down a few rabbit holes, trying to re-wire things, and hook things correctly to the corresponding actions, state, and store.

After a while (maybe 30 mins?), I stopped, and had a think and decided to do a git add . and git stash. I decided to work within the existing code, and take a simpler refactoring approach, using the existing structure and deliberately trying to minimise disruption, and maximise output.

I think I learnt an important lesson today — the solution that I would LIKE to implement is not necessarily the BEST solution for DELIVERING OUTPUT. Ultimately, I learnt that we often drift towards “perfection” (in a sense), instead of accepting the limitations / existing structure, and working with it, to deliver something tangible. Essentially, because we operate inside an agile framework, we should be focussed on delivering, and refactoring, and accepting that the architecture won’t be perfect.

There will be a time in the future, where the decision is made to refactor the entire application, but the tasks inside individual tickets should not be overly concerned about that, because even attempting to do that would not be successful anyway. A proper restructure would require the entire team, and an in-depth analysis of the entire application.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.