Without having the proper technical skills, you will not have a clear vision of how things work, which is needed in order to deliver the features desired by business. Imagine that you are passionate for quality and you possess great general planning skills while having limited technical knowledge. You break down features into sub-products and create a gradual process of quality check because you need to split up a big whole into smaller parts and control the quality so that you can catch bugs earlier rather than later. However, how do you know if your sub-product’s structure matches the necessary steps from the technical point of view? Moreover, how do you know if it is efficient to deliver sub-items and not other orders so as to achieve delivery of the whole functionality? What are the side effects of your choices that may impede delivering in the future?
Additionally, your view about how high quality should be ensured may contain shortcomings. You may find yourself asking, “Which technical architecture supports testing and which does not?” and “How can I build in quality into my work so as to create effective and readable code that follows good practices?” These questions require technical knowledge to answer and should be addressed whenever a team would like to achieve a high commitment-to-progress ratio.
We can create different architectural alternatives so that we can choose the best one that addresses the problem we are faced with and we can design and execute various tests to check these alternatives. For example, we can create a test to check if architecture alternative 1 is better addressing performance issues then alternative 2. If we spot a serious issue, we can gradually refactor so that a local disturbance does not destroy a large part of the product we have already developed. When you need to tackle a new algorithmic problem, having general math and algorithmic knowledge will help you find a solution in a more predictable way, resulting in negligible disturbances. Whenever you embrace your work and are able to predict the technical problems you may stumble upon in the course of an iteration, your estimates are better, which results in your ratio remaining high.
The First Steps in Coaching a Team to Achieve a High Commitment-to-Progress Ratio
The complexity of work items should fit the level of core skills possessed by team members. In most cases, you should begin by choosing easy-to-grasp tasks that require less creativity on the team’s part. You should then add new features to the already stable architectural cornerstone, like an architecture designed for synchronous processing faced with a new business requirement that involves significant asynchronous processing, instead of building a new one or refactoring the existing one to resolve serious conceptual issues.
You should give the team tasks that stretch across all layers, including the data persistence layer and the business layer, etc. Otherwise, you may soon face a sudden ratio deterioration as I explained earlier. Make sure that the team’s work items reflect real business needs and not just the technical sub-parts. One way to do this is that for each iteration, make sure that the team is producing something tangible for the business instead of only technical artifacts that someday will be combined to make a desirable business feature.
You should, at all costs, avoid a loosening of your definition of done. Your goal is to get used to the challenging nature of the definition of done and add discipline to the team’s software development process, which includes performing testing based on acceptance criteria, regression tests, etc.