created sandbox versions of production for each conversation among traders, financial modelers, trading administrators and support engineers. The increased level and quality of communication led to the realization that the whole group owned the system.
Implementing the sandboxes removed the handoffs and enabled the participation of the whole team throughout the project. The whole group was able to take ownership of the technical debt, code quality and release process, since each of these sandboxes made these items visible to everyone involved. Most sandboxes were set to refresh their database daily from the live system, and would be extended with all the daily code changes from the development system as well. In addition, the financial modelers were evolving multiple analytic libraries, and the latest versions of their work were also applied to the sandboxes on a daily basis.
Traders and their administrative staff picked up any drop in code quality on the part of either the developers or the financial modelers immediately. Any technical debt that impacted the usability of the system or the daily generation of risk or profit and loss figures was also picked up immediately. Degradation in the computational performance of the application was obvious to everyone straight away. And of course, the release process was being tested on each sandbox every day.
An Environment for Group Learning
The previous example illustrates how software development can be a group learning process. This solution allowed for both Practice by the entire group and also for continuous improvement in several areas. For example, the financial modelers were able to share each other's work and thus were able to explore four or five times the normal number of candidate models to develop a solution, with each cycle of modeling providing input for continuous improvement. The traders were able to test numerous hypotheses about the market parameters that would influence the new models, thereby contributing improvement to their business model and trading strategy.
Given the crisis, the stakeholders were willing to do away with the traditional handoffs, include all the participants and create a shared sense of common purpose. This holistic project interaction initiated group Practice in which self-organization and group learning spontaneously emerged. When somebody suggested something that the group could do, the group provided a way for them to try it, improving the group's environment with each cycle. Eventually, the group was able to create its ideal environment for continuous improvement. This environment was the result of acknowledging the previously tacit group ownership of the risk management system. The Practice allowed a new self-organization to emerge.
When everyone is able to see and experience the progress made throughout the development process, they will offer and receive feedback without being solicited or prepared. This open group exchange is one result of Practice. To guide a collection of Agile practitioners and their project stakeholders towards Group Coherence, it is important to provide opportunities for the group to Practice ‘being a group'.
Without ‘being a group' the team has no access to the tacit knowledge. Once it accesses its shared understanding, the team develops a knack for group learning. Group learning is necessary for a team to embrace suggested improvements. Continuous improvement depends on group learning provided through Practice.
Guiding a group from practice to continuous improvement can allow practical results in such challenging areas as code quality and technical debt and can make releases so frequent, tested and drama-free that they become invisible.
About the Authors
This article was written collaboratively by Joanna Zweig and César Idrovo.
Joanna Zweig holds a Ph.D. in Integral Studies with an emphasis on Learning and