Part 1: The effects of team and culture characteristics on coding

Scrum is an agile project management and development methodology that – according to most people in business and management – ensures that excellent quality (software) products are delivered in time and according to the customer’s taste. It has been a standard method of working since half the 1990s and many of its implementations are custom tailored to the organisation at hand.

As code monkeys, we experience a lot of the benefits of SCRUM in our daily work. For instance, the division of large chunks of work into smaller, more manageable “quick win” stories ensures that the input for code is delivered in a constant pace to the business and of good quality. Their functional and technical specification in iterative refinements, followed by on the point prioritisation and sprint planning ensures the pace in coding. The daily stand-ups signal problems at an early stage and get all-round support to overcome them, thus enabling coders to quickly move on without much delay. The burndown charts and retrospectives work effectively on learning how to avoid said obstacles in future. Finally, the regular demos to the customer allow the team to verify the design of the system, check its translation to workable and maintainable code, and to make any last-minute changes to it if necessary.  All these work procedures contribute to improving the project’s planning and delivery estimates and indeed ensure that the code that is delivered is on par and of superior quality.

Although SCRUM has some greatly beneficial effects on the planning and evaluation of software delivery, from a developer’s point of view it also poses some severe challenges on the pace of the coding process and the possible quality and validity of the product. Mainstream IT is incredibly positive about the methodology but we – and 12 other software developers think that these drawbacks should be addressed so that software teams can deliver better quality at a higher pace.

To gauge whether the sentiments of the authors regarding SCRUM and its effect on coding were shared amongst other developers within PanCompany we organised a 90-minute brainstorm session in which we asked participants to list the things that work in SCRUM, the things that do not. And for those that do not, what workable solutions we could think of to improve these drawbacks. Most of the things that do work were discussed above. The following section will focus on the input that we got for problems related to the team characteristics. We will in turn discuss the issues and provide solutions on how these risks can be mitigated. In a subsequent blog we will discuss the effect of distributed attention to coding, one of the unintended side-effects that result from SCRUM, and which sorely needs to be addressed.

Teams that grow too big

It is understandable that teams grow with the amount of work that needs to be done, the number of stakeholders that have a say in the final product or the varying expertise that is needed to build and maintain the system. However, too many people within the team creates several problems that need to be addressed.

First of all, most of the scrum rituals will take much longer than with smaller teams. Every member has to contribute. A loss of focus is also possible as the number of parties involved increases. That is, each member has their own goal and this might conflict with those of other stakeholders. Moreover, even for big teams there is usually just one PO, making the person a single point of failure if temporary unavailable and a possible bottleneck for work.

With bigger teams, the pace of the delivered code will be lower because work of each individual developer needs to be constantly merged with that of others. Such merges take time, even more so when multiple people are working on the same files. Also having more than one person allocated to the same role makes it more difficult to determine who carries end responsibility when something breaks. There is generally no member that oversees all dependencies within the project, much less over projects. Team leads cannot monitor everybody’s code all the time. This makes it easier to break other people’s code when working on it.

The simple solution seems to be to set a maximum of about 9 to the number of members within a team. When this is not possible, it is vital to have a strong scrum master to bring the team back to focus when disagreement or too long discussion arises, and the team is not self-sufficient in limiting speaking time. This issue should also be repeatedly brought to attention in the retrospective if the situation keeps arising. Finally, the scrum master should actively monitor each team member’s progress so that any delays that could have a snowball effect on others are minimized.  Teams could also be split on expertise to minimize this last effect, but this places the dependency problem to the level of the next topic.

Team composition

Depending on the technical landscape of the organisation, and the target of the team, a team’s composition can differ in expertise. A significant difference in expertise between members of the team poses some challenges for refinement and planning sessions. Firstly, it will be more difficult to accomplish that the team is responsible for the pace and quality of delivered code. If only one or two of the developers have sufficient expertise to make realistic estimates, doing scrum poker with the team will result in too low or too high estimates because the mean estimate will be taken which is skewed by a too low expertise. Such estimates will result in an unrealistic planning. Teams varying in expertise also suffer from the single point of failure problem when responsibility for functionality or techniques are assigned to just one or two team members instead of to the entire team.

Transfer of knowledge within the team, also between members of varying expertise, at least to some basic extent, seems to be a solution to these problems. Playing poker with weighted estimates depending on the expertise of the team member who had made the vote on the current topic makes the overall estimate more realistic for each story. Simply increasing the number of people with a certain expertise within the team also has benefits, but it will increase the size of the team and thus introduce the above-mentioned issues.

Interdependency between teams

When the planning is not well coordinated with that of other teams this can result in large delays and changes in priorities when their sprints are interdependent. Larger organisations implement scaled Agile by organizing scrum-of-scrums meetings and “Heide-sessies”  to coordinate work, making roadmaps and dealing with delays. Whether or not in a SAFE context with a release train engineer role. Still in practice, much interdependency is only signalled when the team is already working on the story. Dependencies between teams should be signalled much earlier in the process, preferably when the business is still formulating the requirements for the implementation and making the functional design of the change. As a solution to signal such interdependencies at a much earlier stage, a more intense collaboration between lead developers, enterprise architects, system architects, business analysts and functional & technical maintenance should take place at the earliest stage of the planning the creation of new functionality or the renewal of existing business flows. Before the roadmap is formed and any detailed functional or technical implementation is designed and planned. Refinements of suggested changes should be preceded by such meetings between the roles mentioned above so that in the functional requirement and suggested technical design, the interdependencies with other teams can be taken into consideration.

Company culture and tradition

A fitting example of how adhering to old traditions can disrupt the Agile process is when work is planned in story points during refinement, but people and teams are evaluated by the amount of work done in certain amount of time. As a result, the organisation effectively stamps a certain amount of complexity with a certain number of hours work. This makes the use of story points irrelevant. SCRUM is a method to optimize performance of the teams and make sure that projects stay on budget and within time. Management should trust SCRUM to do its job. Although shifts in priorities as response to changing circumstances seem to be tempting, managers often fail to see that working on multiple stories at the same time or in quick sequence results in a diminishing of focus on each of them and often results in extra rework. Besides such shifts in priorities of already existing changes, teams often must deal with extra work on top of their backlogs issues if management formulates a new or changed roadmap besides the demands currently requested by the business. This of course places a risk on reaching both the roadmap and the sprint goals. At the other extreme there are companies that adhere too much to the doctrine, even though the environment obviously needs a different approach. For instance, for DEVOPS teams that deal with production issues, their work is much less plannable as it is hard to predict what issues will arise at any given moment and how long it will take to solve them. Kanban is much more suited in such contexts.

Conclusion

We conducted a poll amongst our developers in which we asked what obstacles they encountered in their work despite working SCRUM. One half of the answers were related to team characteristics and company culture, which we discussed in this blog. The main take away from this writing is that it would be nice to have more elaborate guidelines on how to deal with teams differing in size and composition, how we can better coordinate sprint planning of different teams and how to deal with changing interests of different stakeholders over time. The authors proposed weighted estimates during refinement of stories if the differences between team members in expertise is too big. Teams should be kept small, and if they grow too big it should be broken down in topic and/or expertise so that stand-ups remain relevant for all team members. Dependencies and priority shifts should be signalled as early in the change process as possible, preferably before technical design and build. Finally, the scrum process should be watched closely by the scrum master both within the team and between teams so that any delays are picked up early, dealt with and evaluated. In the next blog we will discuss the other obstacles that our developers listed, related to attentional prerequisites for coding and we will zoom in deeper on the issues we encounter during the planning of work.

Part 2 : The effects of distributed attention on coding is available NOW.

Christa van Mierlo