It’s important to be able to take a top down view of your team and it’s bottlenecks, internal and external.
For example, the inputs to your sprints “should” be nailed down when planning, you might need:
- a data model definition;
- web service schema;
- validation use cases;
…the list goes on.
If they consistently aren’t appearing on time, this is a bottleneck hampering your productivity. It’s important to raise the alarm.
Internal bottlenecks are firmly in your domain.
- you may have a particular team member more suited to a certain task based on their past experience, meaning that any task requiring a certain skill set ends up on their lap. This is an unhealthy situation for a number of reasons, getting hit by a bus factor being the most obvious. Share the love, set time aside for pair programming to mitigate this where possible.
- your old build server might be underpowered for the sorts of tests it’s now expected to run, upgrade it, optimise your tests, utilise nightly runs of the longer tests, there’s any number of ways to address this.
The examples are pretty immaterial and have been used a thousand times over, the important bit is the acknowledgement and communication that the bottleneck is there, this bit is your role.
The ability to set some of your “clock cycles” to enable your team to be more productive long term is a key skill.
Friendly Neighbourhood White Board
The whiteboard is your friend. Early on in my current role I bought a desk whiteboard, a little bigger than A3 size for a few pounds (with a pen and a wall mount, if you’re that way inclined).
People learn in different ways, but from experience, explaining a problem or solution with a few labelled boxes on a quick diagram will make all the difference.
Source Control : Refactoring
As your project changes you should take consideration of the structure of your source control. This is particularly notable if considering transitioning from a monolithic architecture to a more service or micro-service oriented architecture.
You’d likely have had the entire application in a single repository, maybe even solution. That may no longer be the case, and in this situation it’s important to consider the ability to check out each service as a distinct development environment. I prefer not to rely on checking out several services distinctly and managing dependencies between them in this manner, it’s a little too unscientific. Each service application’s source and dependencies should be standalone.
Inherently, it won’t just be your Source Control that will be refactored; but it’s important to take into account how you will manage depenencies reflected in your Version Control System whilst making application change.