Movebubble Sprint: Day 6

Monday morning comes round again and I’m expecting a busy day; partly because it’s Monday, partly because I missed Friday, but mostly because we’re halfway through a sprint and it’s usually around now that we start to find the things that we missed and difficult questions about edge cases, version migrations and potential scope creep start being asked.

This is not to say that I am cynical about our chances to delivering on time; we’ve factored time for this and accepted it as simply part of the process. The question I don’t currently know the answer to is whether the slack we’ve built into the plan is a realistic amount or not.

After the two team standups and a coffee, I spend the first 10 minutes catching up on emails from Friday and then going through some uncommitted code – I’m slightly surprised to find that I actually did some work on Friday and I need to refresh my memory as to what I was working on. There are a couple of unresolved bug fixes related to some errors which are currently polluting the logs and while I’m at it I decide to review the logs from the weekend to see if there are any other issues highlighted there which might be quick fixes.

I spot two possible logging improvements, an edge case which is generating a null reference exception and a comparison which is failing due to a case mismatch, so I quickly work through these and push what amounts to 5 or 6 small fixes to master at 11:03am – just in time for our Monday Town Hall meeting where Aidan goes through the figures.

It’s another record week, but currently every week is a record week so I wonder for a moment whether we’re becoming desensitised to the company’s growth. On the flip side, while we are definitely moving in the right direction and edging closer to our target conversion rate – the key metric that we believe will enable us to attract venture capital investment in our next funding round – we’re not moving there fast enough. We need to be moving the dial at roughly twice the rate it’s currently going; that said, we’ve only just started trying.

Straight afterwards we go into our dev catch up. We don’t end up discussing much. There’s some talk about the work we’re doing at the moment and I think Laura is starting to feel the strain a little in terms of the work that is still outstanding, but overall the mood feels positive and there’s not much to say this week.

When I get back to my desk I discover that I broke the build – in my haste to push before standing up for the Town Hall meeting I had typed a couple of random characters into my IDE without noticing. I make this kind of mistake mostly because of time incentives; it can take 4 to 5 minutes to run all of the unit tests locally and our CI build can take up to 20 minutes to deploy, and I often have my attention divided in 2 or 3. As a result I sometimes take short cuts without even realising I am doing so in order to get work out so I can move onto the next thing. I make these mistakes less frequently when working with our microservices because the tests are much quicker to run.

While I wait for the build to go green, Laura has a question about the chat status message history. It quickly becomes apparent that we’ve both made different assumptions about how it would work.

The current problem we face is that we have a set of legacy status messages which are generated by viewing events and set of new status messages which get pushed directly to the chat window as part of a conversation with the agent. Many of these messages are duplicate and at the moment we have a fairly inelegant solution merging messages from the two different sources.

We want to migrate to a situation where all messages are surfaced in chat; our different assumptions centre on what to do about viewings with agents who do not have the agent app. Do we start chats for these viewings too, push status messages there, and simply disable the ability to write messages? Or do we stick to the old system of system messages for these viewings and only migrate to the new system for chat-enabled viewings? I am a fan of the first option because it means we can ultimately remove legacy code and keep things cleaner technically, but it turns out there are some good operational reasons for going with the second option and that is the solution towards which Laura had believed we were working.

Eventually, I agree with her that we should adopt the second solution and make a note to make the corresponding change in the back-end. When I get back to my desk Jordi however Jordi also has some questions for me about the behaviour of viewings and chat. As we’ve changed the nature of the relationship between the user and the agent and the code that needs to know about it is distributed between 4 codebases (our original monolith API, the new chat service and our two mobile apps) there are some difficult cases around keeping everything in sync and ensuring that new viewing requests and chats are all routed to the right place.

Jordi is concerned that, currently, starting a chat does not trigger recognition of the relationship with regards to assignment of viewings, so viewing requests could still go to other agents outside of chat. He has a point. We had considered this when talking about the feature but the behaviour had never been specified and this is an oversight on my part. Now there appear to be 3 distinct pieces of additional work that need to be done, though one of those does not need to be part of an MVP. I write up the tickets and pull them into the sprint. I’ve allowed for around 20% to 25% ‘scope creep’, and we’re still well within that; I hope, however, that this isn’t just the start.

I’d like to get on developing for the tickets I just added, but Will has done some testing and the decline viewing messages still aren’t showing. This is a complicated one because depending on the scenario we don’t immediately notify the renter because we want our viewings team to intervene and see if they can get the viewing booked at a different time. With the adoption of the agent app some of this process may potentially change, so I need to make sure that what I code is not just a slavish copy of the requirements on the ticket but that I have also taken the time to take to sales, ops and product about what they think the behaviour should be. I head over to ops to ask Bilyana a couple of questions regards how their team interacts with renters after a viewing is declined and decide that the behaviour we suggested when we wrote up the ticket is probably correct. I double check this with Will; he agrees, and it’s time for lunch.

Just as I’m about to go for lunch though, George raises a dev support ticket. The app isn’t working for a particular agent but he hasn’t included any more details on the ticket, so I need to prompt him to send me more info. He attaches some screen shots to the ticket. Now it’s time to eat.

It’s a nice day so Jordi, Laura and I grab so Itsu sushi and sit in the park at Russel Square. It’s nice to take a proper lunch break; I’m not always very good at doing that. There’s no pressure on me to work through lunch but I often put the pressure on myself; lunch is one of the few times when I can usually get 30 to 60 minutes of completely uninterrupted coding done. It’s easier to take that time however when it’s not gloriously sunny outside.

When we get back, I need to deal with the dev support ticket George raised. The text on the screen in the screenshots is too large and overlapping. I call him to get his phone version and then ask around to see if anybody has the same version. When I describe the problem to Valerio he diagnoses it for me without needing a demo; it’s related to the accessibility settings and we need to limit the size of the text in our React Native app settings for IOS. In the meantime if the agent wants to be able to use the app he’ll need to turn the accessibility settings back to the defaults.

I call the agent back and talk him through the workaround however he is (understandably) not particularly happy that it involves changing the settings for his whole phone. I tell him we will have a fix out in a release in a week or so. He gets a bit grumpy and tells me to ‘keep him informed’ before putting the phone down. I wonder if I need to improve my phone manner and then update the ticket to let George know what the status is.

There’s another dev support ticket from Ben, to merge two agency branches who want all leads to go to the same set of negotiators. I have recently added a tool to our CRM to do exactly this, so I show Ben how to do it and hopefully now that the ops and sales team can resolve this issue themselves it will reduce the overall support load, as this is a request that we had been getting a lot in the previous couple of months.

By 14:25, I’m ready to start development on the tickets I added earlier. Dev support has gone quiet so I get a relatively uninterrupted hour and by 15:30 I’ve written an endpoint to ‘claim’ all of a renter’s viewings – so that if a renter makes multiple viewing requests, the act of joining a chat by a negotiator assigns all outstanding requests to that negotiator. Of the three tickets I raised earlier, this is the most straightforward.

I still need to write a couple of tests for it but we have our weekly cross-team catch up now, where we go round the table and let everybody know what our goals are for the week. Our team’s goals are pretty clear – deliver the new Suggested Property feature for release on Friday. The Space Monkeys team have slightly more disparate goals – Adrian is working on property descriptions and some improvements to the offers flow, while Valerio and Tom are working on deeplinking in the renter app. I let everybody know that we’re still looking good for a release that Friday, though it’s going to be tight. Then again, it always is.

Back at my desk, I finish off the tests for the previous bit of function and pick up the second ticket I raised that morning, which is more complicated. This relates to how incoming viewings are assigned to contacts and the relevant code is more difficult to manipulate. I realise that I need to do some refactoring first as we have a couple of long methods which are more or less duplicating functionality and extending them with the new behaviour isn’t going to improve maintainability. Refactoring takes basically the rest of the afternoon; it’s 17:40 by the time I think I’m ready to commit my changes.

There are a couple more dev support tickets but neither of them appear urgent so I leave it until late and then follow up with the raiser (George) to check that my priority assessment is correct. One relates to email validation and the other to stray bit of data in the CRM – neither is affecting a live user so my current work feels more important and I add them to our backlog with the intention of addressing them later in the sprint.

I also have a chance to chat with Sunil about the CRM design work he’s been doing and give him some feedback. He’s talked to the sales team about their needs and has come up with some wireframe designs for a new interface that we hope will better support them in their aim of onboarding new agents. I built the previous interface myself without any design input and while it was a reasonable prototype it has long been evident that how I believed the team would use it is different from how they actually use it and we need to rethink it in order to give them better context tools and smooth the experience.

Sunil’s done a good job at distilling the various additional features that the sales team have requested; unfortunately he’s missed the main point of the redesign, largely because in his interviews the sales team were more focussed on added value features than on the frustrations that they currently have. I make some suggestions regards context for onboarding and also make some suggestions about responsiveness, since this will be accessed while the sales team are out of office more often than not. I make a mental note to talk further about this tomorrow as I want to make sure we get this right.

Then, while I am thinking about tomorrow, I ask Aidan about the shareholders’ meeting – I’d like to go. He tells me that’s fine and I should get the details from Jack. It means I’ll be out of office from 2.30pm the following day, but it only happens once every 3 months or so and I’d like to get some insight into the financial position of the company and also what kind of things the shareholders care about, as it’s a bit of the picture I don’t really have yet.

I’m about to start development again but Laura has noticed another issue in the renter app, arising from similar issues to those raised by Jordi earlier. It seems that, because viewings to chats are no longer a one to one mapping, the viewing preview doesn’t always make sense as it can contain status messages which relate to a different viewing.

There are a couple of potential solutions to this but neither of them are technically pretty and they both feel like sticky plasters over the root issue, which is that human chat messages as part of renter-negotiator discussion and per-viewing status messages are fundamentally two different types of communication and perhaps need to be treated differently.

This feels like a design issue but Simon has already left, so I drop a slack message to him with a note that we should talk about it in the morning. My feeling is that perhaps we will want to rethink the viewing preview from a design perspective in the long run but in the short term this is something that we can live with. Compromise is the essence of delivery in a startup environment and while this technically unpleasing it’s a compromise I feel we are willing to make.

When we’ve finished discussing, it’s 18:15, which means I have about 20 minutes more development time before I need to get changed and head off to 5-a-side. It’s enough time for me to get started on the changes that my refactoring enabled, but I don’t get much done. I’ll have to come back to it in the morning.



Leave a Reply

Your email address will not be published. Required fields are marked *