The SilverLogic has grown dramatically as an agile software development company over the past several years. Now 10 years old and with almost 60 members, we faced the question: how do we —the organization—introspect, course-correct, and learn at scale? A company-wide retrospective is unfeasible, and surveys only take us so far.
We needed a method for the company, composed of development teams, a small operations team, and an even smaller sales team to have a mechanism for introspection, retrospection, adapting to change, and planning for the future as a business.
While the concepts of “scrum at scale”, “scrum of scrums” and similar frameworks are well-explored and exist in a robust environment, they are aimed at coordinating multiple teams working on the same or overlapping body of work. As an agency, each team works on one or more client projects, and only in rare cases do they overlap. What we needed (and continue to need) is a robust framework and feedback system for how we do the work of a software development agency or consultancy.
Drawing from the lessons of now-classic writers Chris Argyris, Gerard Endenburg, Stafford Beer, Toyoda, Ohno; and the contemporary writers Jutta Eckstein, John Buck, and Ted Rau, we took our first steps towards dynamic governance in the first quarter of 2022.
The problem we are trying to solve is ultimately one of moving from single-loop learning to double-loop learning. To use the classic analogy (summarized nicely in the Journal of Leadership Education), single-loop learning is continuously adjusting the thermostat when it goes outside a desired range, and double-loop learning is learning to program the thermostat to adjust itself (and perhaps adding a temperature sensor).
Our agile/scrum teams' retrospectives tend to produce three types of action items:
In the second case, a team has an issue that is addressable by someone else at the company, the “easiest” route is to ask for a small change or help, receive it, and move on. If the issue is common across several teams, the issue may be addressed multiple times independently without anyone noticing work is being repeated and with the organization never pausing to consider if the issue is systemic and should be addressed with an official process, or if it’s fine as an ad hoc action. The individuals asking for help and the individuals responding to requests might reflect on the need, but the organization does not. These individuals and the many small actions they’re performing might add up to something big in the bad sense (waste) when with a better structure they might instead influence a small system adjustment with a big payoff in employee satisfaction and profits.
Double-loop learning requires us to consider why we even have our processes, not just how to make them faster and less error-prone. It requires us to pause and reflect on the assumptions that we make and the reasons behind our actions.
Double-loop - reflective problem solving aka root cause determination "Why do we have that problem in the first place?" and tweaking after chasing a set goal
In the first quarter of 2022, each of our teams decided on a method to select a delegate and selected a delegate, along with the teams’ product owner, to attend and participate in the first quarterly General Circle Retrospective. We discussed what went well in the previous quarter, what could be improved, and how to maintain what went well and how to improve what could be improved. A week later, through a Google Form, the General Circle selected a delegate to follow up on a more regular basis with the action items gleaned from the retrospective with the Operations Team.
By 2022, the foundations for this framework had been set for years. All but one of The SilverLogic employees belonged to either the operations team or a development team with a product owner, and all product owners had been having a weekly meeting with the Ops Team for years to discuss the running of the business.
What was missing was the bottom-up feedback loop introduced by the teams selecting a delegate, and the more focused accountability introduced by the General Circle selecting a delegate.
For the readers who are not familiar with sociocracy, the basic tools of Sociocracy are:
Consent decision-making. Policy decisions are made by consent, which differs slightly from consensus. In consensus, everyone is trying to find agreement, often trying to find common ground for their preferred outcome. In consent, we shift our energy towards finding common ground that is safe to try and that no member has an objection to.
Small group mandate: All members of a governing body are organized in circles. Those circles have full authority in their domain. All decisions are made on the most local level possible.
Linked circles: Whenever there are two related circles, two members will be full members of both. That way, information can flow easily and no group can over-power the other.
We’re missing consent. The needs of our organization are such that we needed the dynamic feedback loop, and “enforcing” consent as a selection mechanism for delegates was firmly in the “worry about it later” category. For now, our model is safe enough to try.
Read more about Agile at The SilverLogic