A quick update I thought was in order; and this time I thought I would reflect a little bit on my $DayJob, the agile processes we employ, my role and how the company’s continued growth affects all the above.
So as I think I have mentioned elsewhere, I am the “Development Team Leader” at my current $DayJob. My team is mainly involved in backend strategic development tasks for our web product. We also cover some front end development and mobile application development.
We are agile in nature, we have a flexible working style. We don’t use scrum though we do have a background in using Scrum and Kanban previously. The workflow is roughly like this; feature requests are raised and tracked in Trello. The top 20 (or so) end up on index cards and are displayed on a whiteboard with magnets in our shared area (where standups etc happen) in order that we see them happening based on business priorities.
As the features come to the top of the pile, we start looking at who will work on the cards. In our environment, we try and work in pairs (or more) on every task. So whilst looking at the tasks, we consider who has been working on what recently, who (if anyone) has recently worked on the same area of the codebase or similar projects. Who has more experience, who has worked together etc.
We attempt to mix up our pairs regularly. So when a new developer joins the team we try and make sure they work with one of the team that have been around some time. We then also try and ensure new team members cycle around working with the whole team so that everyone gets to know everyone else. This we think helps build team camaraderie as well as sharing knowledge of the code and features.
Within the team we try and work in a TDD style. We are fortunate that we now have a fairly mature testing environment and tooling. We have three levels of testing (not including our QA testers). We have unit tests, integration tests and end to end tests. So we can very quickly test our components, our services and the “end product” web site locally.
We do not do “sprints”; we work on a task for approximately a few days to a couple of weeks depending on what it is. We have some pairs finishing whilst others are half way through and this works for us. It allows us some advantages such as being able to respond quickly whilst also giving us the ability to pick up bits of work with a bit more depth.
Every friday, we hold a retrospective. This is our chance to look back over the week and make changes to how we do things. These fit nicely in with our daily standups which are mainly used to inform outside parties (management) how things are progressing; like I said this is not scrum. Each friday we also hold a small demo or training session. We alternate this week on week. The demos (and trainings in fact) are open to the business and we invite people we know it affects. So this is how we share new features and try and share knowledge with colleagues about new code, etc. The trainings are all informal short explorations of coding, agile, etc. They are all about the team sharing ideas and “received wisdom”; it came from noticing that some team members knew “stuff” gained over time about our way of doing things that newer members were missing and looks to working well at disseminating ideas.
Although, like many real programming jobs we spend a lot of time working in a “legacy” codebase, we do get to write new code and write modern code and broadly are not restricted to languages, frameworks or technologies. That said we are realists and know that with 15 year old codebase we will find things we don’t like; that are ugly to us, or buggy, etc. As a team we apply the “leave it better than you found it” rule. Even if that is as little as a “# Here be dragons! This code does x, I don’t know how it ever worked! So tread carefully” comment. More often though we are able to highlight the area and dedicate an extra day or two to clean up the code before we move on (often at the start of the process as it can help with the task at hand).
The $DayJob for me also involves helping the other team members get on with it; if we were a scrum team I see my role as scrum master; not product manager. So I will often be the one who looks at tickets, browses the code and guesstimates roughly how big and scary the requested work might be for one of the team. It’s a nice mix for me as I am mainly coding; but have these other things I get to do to help the team do cool things.
The best thing about my $DayJob is the dev team I am part of. It’s a strong team with a variety in gender, age, experience and personality. Everyone on the team is nice. This is a big deal, life is too short to spend with people I don’t like. I like these people and enjoy time with them in and out of office hours. Also, they are all trying to be better developers. And I mean that both in terms of trying to write better code today than they did yesterday but also in that they are reading up on new technologies, trends in the industry; playing with other languages, frameworks, ideas etc.
So there you have it, a small update.
Lance.
P.s. the company I work for is hiring. And specifically (though not exclusively) perl developers. So drop me a line if you are interested. 🙂
Categories: Uncategorized
