Prodcel Stories is a series of interviews with Product & Engineering people. How do their development processes work? What tools they use and how they manage a remote team.
Hello! What’s your background, and what are you working on?
Hello! I’ve been working in the software development industry for just about 10 years now. In 2016 I started working as a senior developer for Transport for London (TfL).
TfL is where I was first fully exposed to agile ways of working, specifically scrum.
Two and a half years on, I’m still at TfL and I’m now working as a agile development lead. I manage three scrum teams in a technical capacity as well as agile coaching and line management.
What does a typical week at work look like for you?
Working across three scrum teams means that a typical week for me is pretty busy with scrum ceremonies.
Each day I attend three stand ups, one for each team, carefully aligned not to clash.
As my role technically isn’t part of any of the scrum teams, I attend the stand ups for support. I’ll only provide updates if I’ve helped to unblock any blockers or if I have any business updates related to the sprint for the team.
Each of the teams I work with work to two week sprints. Each of those sprints are made up of two refinement sessions, one planning session, a retrospective and a sprint review.
A big part of my role is making sure that the scrum teams have everything they need to be able to do their job. I’m there to assist with any blockers and make sure that they’re keeping to TfL’s coding standards.
The teams do have autonomy to choose the best technology that works for them. I’m there to help guide if they’re getting too far away from the technology stack TfL uses.
Outside of the scrum ceremonies a lot of my role is forward planning. From recruitment to updating stakeholders about upcoming work. How that work might be shaped and distributed to the scrum teams.
What tools do you use to get your job done?
As a department we are a Microsoft shop and rely heavily on their stack.
The majority of our developers are C# and use Visual Studio for development. We also make use of Visual Studio Team Services (VSTS) where we keep all of our backlog items and plan our sprints. We also use VSTS for our code repositories and our CI/CD pipelines.
Each scrum team also has a physical representation of their online scrum taskboard. It’s a whiteboard covered in Super Sticky Post-Its ®, the super stickyness is important!
The daily stand ups happen around the whiteboards and tickets are moved during the stand up. The online taskboard is updated as developers and testers complete their work.
During refinement sessions the teams use planning poker cards, following a fibonacci sequence.
The product backlog item will be updated in VSTS during refinement and marked as approved when the teams definition of ready has been met.
In planning sessions we update the online taskboard. Moving any stories to the next sprint that weren’t completed and selecting new stories.
The teams then break the stories down into tasks and enter these into VSTS as well as making Post-It copies for the physical board.
Each team has a scrum master assigned to them and scrum masters use different techniques during retrospectives.. Most involve the team writing down their thoughts on Post-Its and sticking to the wall in various categories.
How do you manage working with remote members of your team?
TfL does offer remote working but the scrum team members are encouraged to be in the office on days with scrum ceremonies. That being said when a team member or two are working remotely, they are dialled in and can follow and add input via VSTS.
Retrospectives are a bit harder for remote working. Usually the scrum master will contact the team ahead of the meeting and ask for their feedback.
The scrum master will then write up the feedback and put up on the walls at the relevant moment during the session.
What one piece of advice would you give to someone who is trying to improve how their team works together?
I’m going to cheat here and give three bits of advice because I think they’re all important for a successful high achieving team.
1. Make sure your team’s Definition of Ready, Definition of Done and Coding Standards documents/wiki’s are up to date.
These sometimes get overlooked by teams but they’re really important.
It’s also a good idea to revisit these when a new team member joins. They should be living documents and should be referenced during refinement, planning and code reviews.
2. Be self organising! It’s worth reminding teams that from time to time, the best teams truly embrace this and are empowered to make changes to how they work.
3. Finally, keep teams together. If your work is project based and you find that the work teams have been doing has come to an end, keep that team together for the next project. Don’t break them up into other teams. People work well together and reforming of teams breaks that harmony.
