To be as efficient as possible on your Angular team you must realize that the process framework you are using has a bigger impact than the actual tools and technologies you are using. A common problem for engineers is that they get overly focused on geeking out with the toys that they forget about the big picture and the problems they are trying to solve. As fun as this can be, it will not make you more efficient. I believe once you have become more efficient you can also experiment with improving different tools and technology but if you only have fancy tooling when it would not matter much if it is not running with an efficient process framework. That is why I am now doing another blog post, that will do more for your Angular productivity than watching any NG-Conf talk. I hope you can live without the buzzwords and bling.
How can processes have a bigger impact on the team’s productivity than improving technology and tools?
It is kind of like this; if have bad hardware and a bad operative system then even the best application will run poorly. That is why I recommend that teams focus on improving their fundamentals (culture and processes) before they jump to optimizing their tools and processes.
Read more about the fundamental building blocks of elite performing teams here.
Now we have that sunk in, let’s get started!
Seeing for the first time
For a lot of engineers, their working life might feel as being zoomed in on a lot of details without seeing the big picture. Without having the big picture in place you have no way of knowing in which direction you should go and how to prioritize the steps to take.
You get the overview by creating a value stream map. A value stream map is a map of the stream of value-adding tasks that are involved in taking a concept to reality (production). In a value stream map, you will get an overview of the whole delivery flow and how long each process step in the flow is taking.
This will help you identify the bottlenecks in the system because:
Improvements made anywhere besides the bottleneck are an illusion
For example, by looking at the value stream map above we see a quite efficient development flow. The places that are not containing value-added time are between development and code review and between code review and QA. It could here eg. be worth looking into the team policy about doing code reviews. Maybe also do more complex/architectural work as pair programming would make the development a smooth transition into code review. Likewise, with code review to QA, more automation and closer collaboration with QA could also improve the throughput. This can especially be improved by what we will look into in the next section.
Use a pull system instead of a push system
This one is key, to any team that wants to get more productive as they scale instead of just getting a more inefficient delivery flow.
What is the difference between a push and a pull system?
The difference between a push and a pull system is as follows:
Push system: You push/handover tasks to the next piece in the chain. You only do your specialized job and everything else “is not your job”.
Pull system: The developer drives the work and “pulls in” the needed resources to get the job done.
That could, for example, mean that he:
- Pulls in a BA when needed for various missing clarifications when defining the task
- Pulls in another DEV for early feedback or pair programming in the development process
- Pulls in a QA to help him understand how a feature should be tested or for him to do regression testing for him
By doing this, you will eliminate bottlenecks and be in the driver’s seat as a developer. You will drive the end to end delivery and utilize your teammates as a valuable resource to get it done better and faster.
Creating your technical roadmap
I have talked before about the practice of doing weekly/bi-weekly front end chapter meetings. This will ensure a system for weekly improve the performance of the team by collecting, discussing and planning improvement ideas from the team members.
To really align all these ideas in the planning, I recommend you prioritize these and plan the implementation in a technical roadmap for the next 12 months. That makes sure that the improvements actually get done, and they get done in the right order according to the relevance and priority.
Seen above is an example of the technical roadmap. Having this in place ensures that the team always have something to work on if the features in a sprint are done. Also, I recommend that a “healthy” team allocates 20 % each sprint for “improvement work”, such as doing the tasks planned in the technology roadmap. For teams with bigger problems at hand, this allocation might be higher for as long it takes to get them high performing.
In this post, we saw how to diagnose the pain points that are holding your software team back and how to go about fixing them. First, the got the overview through value stream mapping and then we solved bottlenecks by redesigning the processes flow to avoid handovers (push system) and instead strive for a pull system. Lastly, we saw to make the team better, week by week, and plan the improvement process by collecting and discussing ideas using front end chapter meetings and plan the execution of the ideas in a prioritized technical roadmap for the next 12 months.
Continuous Delivery – Jez Humble, David Farley