Building Highly Productive Teams: Factors that Influence Commitment-to-Progress Ratio

NOTE: In  "Building Highly Productive Teams: Work Committed vs. Done", I introduced the commitment-to-progress ratio as a measure that helps establish how far the team is able to embrace their tasks. I also described some positive and negative scenarios of relations between the committed and delivered work each team might be faced with. Now, for the second and last part of this article.

The Nature of Your Work
If the subject you are working on is at least in some part predictable by nature, you should be able to foresee some possible work outcomes; a high predictability characterizes the deterministic systems. Consider the following process of making a cup of tea: First, you boil the water; second, you put leaves of tea into a cup; third, you pour boiling water into the cup; and finally, you let the tea cool until it is ready for drinking. In this case, it is pretty easy for you to give estimates because variability is reduced to the likelihood of human failure or some external circumstance beyond your control that can negatively affect the tea-making process. Now, let’s take a look at the dispatching department of a company that runs a web shop: Because the nature of processing an order—receiving, packaging, and sending an item—is deterministic, you might expect to make straightforward estimates. For example, if employees follow the procedures, it will take five hours to process around 1,000 orders. In case of a machine failure, you should correct your estimates with the necessary time required to fix the issue.

On the other hand, there are tasks, such as the designing of a new product or the creation of a new algorithm, that require your creativity and patience. Instead of being accustomed to using “carved in stone” procedures, you must be able to think outside the box while being creative and patient. In the end, it’s very difficult to predict the results of these highly creative tasks, no matter how many times you make a guess.

Software development tasks reside somewhere between these two spectrums. In my opinion, the average complexity of software tasks would be around 0.7 on the creativity axis, where one represents tasks like a proof for a complex mathematical theorem. You must be more creative for the tasks that are less predictable in nature; consecutively, it may be harder for you to achieve a high commitment-to-progress ratio.

Some tasks simply do not fit with the concept of ensuring a low difference between the committed and delivered work. While creating a new architecture from scratch may raise your creativity meter to 0.9, asking a team to estimate if it will take two or four sprints to create a new O (n log n) clustering algorithm simply misses the point. It’s difficult to predict how much time it will take to make a breakthrough in mathematics, especially in two week sprints.

Definition of “Done”
The definition of “done” is one of agile software development’s key concepts, and it also plays a crucial role in helping you achieve the high commitment-to-progress ratio. When you have reached “done,” you’ve effectively made progress. A good definition of “done” clearly and concisely explains the criteria for marking the work item as done, focuses on business value, and only contains the necessary technical details that ensure that business value is delivered.

A poor and vaguely specified definition of “done” can lead to a misunderstanding about the reason to deliver, because a product owner may have a different opinion than the team. Your ability to measure the commitment-to-progress ratio can be utterly diminished, rendering useless all your efforts to achieve a high commitment-to-progress ratio.

Here is an example of a definition of “done” I have used with one of my teams:

• All acceptance criteria have been met for a user story.
• All core regression tests have been run, and all spotted regression bugs have been fixed.
• All particular regression tests within the areas where code changes occurred have been run, and all bugs have been fixed.
• The code, along with any other artifacts necessary to run the application on any environment—whether it be test, pre-production, or production—is in the artifacts repository and is ready for a one-click deployment.

The Critical Skills Required to Achieve a High Commitment-to-Progress Ratio
In the following section, I will examine and describe the skills that should be fostered in team members who strive to achieve a high commitment-to-progress ratio. I’ll explain why these skills matter and how they contribute to the high commitment-to-progress ratio.

Awareness of Quality
I was once asked by the managing director of an Internet startup to better organize its software development processes. The directors of this startup attributed the low quality of deliverables to an unstructured way of developing, which they hoped to improve by introducing Scrum. After I introduced the basics of Scrum to one of the startup’s teams along with a product owner, we began the first iteration. The team had been working before using two weeks for development and one week for testing. Because the startup directors wanted to quickly ship features, the team focused on knocking off as many of them as possible within two development weeks in order to meet management expectations. Quality was not emphasized during these two weeks, because the one week of testing to follow supposedly would ensure quality.

It was difficult for the team to estimate how many items they could finish completely. Previously, the team was only estimating how many items they could develop. The team members perceived quality as an external task to the development activity. No one wanted to hear about being responsible for quality while developing. The only acceptable solution for them was to hire more testers, thus raising the amount of bugs reported per day. Their commitment-to-progress ratio was nearly stagnant and stuck on a low level. In this case, you cannot accurately assess how much you can finish when you have no idea how to deliver a completely working item. I worked with everyone in the company to change the way they understood the relationship between quality and software development (which is a long story in itself) and the situation gradually improved as exemplified through the increasing commitment-to-progress ratio.

Software development quality is determined from a variety of aspects, one of which is testing. As a result, if you as a team member care about quality, then you will continuously look for ways to link up design, deployment, logging, and other development processes with finding bugs earlier, reducing their scale of impact, and preventing them in the first place. By doing so, your code will become more reliable and your intuition will fit better to the actual progress. Based on my experience, I find that teams lacking quality and improvement awareness are unable to achieve a long lasting and high commitment-to-progress ratio.

Continuous Improvement
Team members should endlessly work on improving their skills. Take, for example, Deming’s circle and its central idea of extending the team’s knowledge by reviewing previous experiments. Due to this never-ending process of planning, doing, checking, and acting, a team adapts more quickly to new circumstances, eventually overcoming local disturbances (e.g., a new product to work on or new technology) with speed.

Planning and Collaboration
Working in a group is complex. For instance, you might plan tasks with other members only to have to re-do the planning because of unforeseen circumstances occurring, like a sudden technical constraint or a team member getting sick. As a ScrumMaster, I have mostly come across new teams that revert to a user-story-per-person scenario.

Real team collaboration does not take place without overlapping or interwoven tasks but items do interrelate with each other in many ways. For example, there are technical tasks that might depend on each other, like setting up a database space before a schema in order to create an application. Additionally, there might be outside dependencies that affect the team, like an unexpected a flu epidemic breaking out.

You should take into account all of these factors during the planning process. It might be best for the team member 1 to work on one user story, the team member 2 to work on another, and the team member 3 to work on the rest. On the other hand, the team member 1 could work with the team member 2 on the most important user story to maximize the chance that the story will be done inside the iteration. If they need to wait for each other to finish, then one can temporarily switch to help team member 3. The team can then say that the most important user story and the first story taken by team member 3 will be done, while the other stories might be skipped depending on the team’s progress.

The ability to create efficient collaborating scenarios stems from good planning skills and a comprehensive understanding of work-process management. Moreover, it is not only planning that affects your collaboration to carry out a task but also your work results, which affect planning options you may consider. For example, having a tightly coupled architecture but a lack of clear contract between the modules, in which case the contract specifies what data in what format must be delivered to an API and what result in what form should be expected in return, implies that work scenarios are harder to execute in parallel because you do not know how to clearly integrate with the other parts. A team with good planning skills is able to plan its work consciously, which leads to better estimates and, eventually, a higher ratio between the commitment and progress.

Technical Fluency
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
Preconditions
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.

First Iterations
At the very beginning, the team coach should present briefly to the team members the concept of a commitment-to-progress ratio and emphasize that both the team and the company’s business can profit from a high ratio. Some team members may perceive this measure as yet another managerial tool for a periodical assessment, but nothing could be further from the truth. Because the commitment-to-progress ratio shows how strongly the team members embrace their software development tasks, developers can step up to the next level of professionalism while the company’s business benefits from better planning and robust software arising out of the sprints.

Next, you should set a target ratio (the percentage of delivered items to committed ones) and its acceptable fluctuation. As an example of an acceptable fluctuation, I choose 80 percent for a two- to (at most) three-week iteration as a target, and everything more than 60 percent as “good enough.” I do this because 100 percent would mean that the work is very predictable, which is hardly ever true. Make sure “done” is precisely defined. Do not elaborate on the details regarding the commitment-to-progress ratio just yet. Specifying clear goals will be more than enough. All other details will appear further down the road.

Your attitude in the first few iterations should be that of a non-invasive observer. Use your senses get a notion of the team’s strong points and where the bottlenecks are. Ask yourself the following questions:

• How is the team dealing with its definition of “done”?
• What parts of the definition of done are most difficult and why?
• Is working together or the technical nature of the tasks (or both) an issue?
• Does the switched cycle take place?
• Last but not least, monitor how your team is assessing the underlying reasons for both problems and achievements and whether the improvement actions are effective. Keep this analysis to yourself during the sprint so as to avoid a sudden intervention without the deep understanding that is required of how a team deals with particular tasks and problems. At the end of the sprint, present the results and get the team to discuss what should have been done better in order to reach the target of 80 percent. Keep notes of what is happening in a sprint and during meetings; these examples will help you later.

Understanding about the relationship between the commitment and the progress as well as the skills and factors that influence the ratio will help you properly assess the general situation and suggest to you what is happening backstage. Be aware of how your team members use the key skills, like planning and assuring quality, for achieving a high commitment-to-progress ratio, and ask yourself which skills need to be enhanced.

Getting a Team to a High Ratio with Local Disturbances
Everything is fine when a team embraces work and its plotted course of action runs smoothly towards a low distance and high correlation. The odds are that you are about to face a sudden ratio deterioration, sometimes preceded by a regular over-commitment. However, you are likely to be safe unless you miss the core points in your definition of “done.”

Let us assume, though, that your progress on achieving a high commitment-to-progress ratio is rough. One of your most important tasks will be to discover the reasons that impede progress and how to resolve them. You can use retrospective meetings in order to facilitate the team members’ understanding of what is happening behind the scenes. And, yes, facilitation and fostering is what you should focus on. Do not succumb to the temptation of telling your team what they are supposed to do. Each team, technical environment, and business is different, and your team’s ultimate goal is to learn how to adapt to many different circumstances and quickly get back on track if a significant disturbance takes place. If, from the beginning, you tell the team members what they should do, they will expect to be led every time and the next time might be more challenging for you.

Additionally, you should support team members by striking a balance between tackling too many or too few improvements at once. Working on too many can lead to chaotic actions and a lack of focus. On the other hand, doing only one thing at a time will only spark local improvements that result from highlighting just one side of a story and thus will hamper progress. Imagine coaching a team on automated testing without making them aware of the code modularity and loose-coupling principle. The task of maintaining the tests would be much more complicated due to the tests’ deep sensitivity to code changes. There is no golden rule about the proper balance, because it varies between teams, environments, and technical domains. Your role is to discover the balance with your team. It may take a while to achieve a high commitment-to-progress ratio for the first time, but once you succeed, your team will be ready for the next steps.

Moving the Team to the Next Level
Let’s assume that your team obtained a short distance and high correlation between commitment and real progress and is maintaining it at a steady level. As the team’s coach, you should introduce more challenging goals, including:

• Raising the creativity bar high above 0.6 by doing such tasks like building architecture from scratch, working with a legacy code and refactoring it, dealing with complex algorithms, maintaining a higher flexibility of requirements coming to iteration, etc.
• Conducting velocity improvements—accomplished by coaching the team to produce more out of each iteration—on more stable parts and not in the sprints focused on setting up an architectural scaffolding.
• Setting higher targets, like 85 to 90 percent with a 10 percent maximal fluctuation. This could be a superfluous option if you have succeeded reaching the previous points. (In my experience, it’s easier to gradually raise the bar higher in terms of how many items a team can deliver per iteration then to tell a team to always be 90 percent accurate when making estimates)

The more your team works on challenging work items, the more it will tackle such topics like refactoring, architecture styles, advanced quality management, and effective work process. There is no such thing as absolute perfection, so your team’s ultimate goal should be constant improvements and expanding its knowledge.

This advanced stage is characterized by striving for minimizing the impact of significant disturbances, like a new architecture or a new business vision about a product, on a commitment-to-progress ratio. The way the team deals with such a disturbance, which is dependent on the disturbance’s nature and context, defines how good the team is. The team should also be accurate in foreseeing complexity in its work items with high-level requirements. Team members can be real partners to business in regards to assessing the long-term impacts of architectural choices. The significant technical issues (like issues in architecture) or flaws in collaboration should be found early so that they will not hamper product enhancement.

Conclusion
In the part two of the series, I answered the question “How can a person build a team that achieves a high commitment-to-progress ratio?” and presented the core skills and factors that influence this ratio.