In our previous post about Software Craftsmanship Management, we highlighted the importance of the “resistance of the medium”, and that increasing friction is a way to improve performance. In this post we will explore what this means.
The simple answer is that friction provides feedback.
Referring to the resistance of the medium, when the medium is software, there are three roles who materially experience such resistance.
The first are the programmers (as described in the previous post), who literally can feel the shaping of the software under their fingertips through a number of feedback mechanisms, processes, practices and tools.
The second are the end-users of the software being developed, the operators at the keyboard. The software can be more or less easy to learn or use: it provides resistance towards the operator’s achieving the desired goal.
The third are the testers and QA people, when they are engaging in manual or exploratory testing, and simulate the end-user’s behavior. For the purpose of this discussion, they can be considered as end-users.
Any other role will not have a direct experience of this resistance. Executives, Salesreps, Marketing, Support, Business Analysists, Project Managers, Product Owners and so on might have an intuition, or receive hearsay about what the software really is like.
Doing the Right Things Right
In DUBAKOV-2011, Michael Dubakov emphasizes the significance of doing the right thing and of doing the right thing right. In more conventional terms, this is about software verification (doing the thing right) and software validation (doing the right thing). Usually you will have Q&A and Testing roles concerned with this aspects; but no software survives the real world test of an end-user operating it.
This is where the resistance of the medium becomes valuable:
The resistance of the medium experienced by the end-user gives feedback about whether or not the software is doing the right thing.
The resistance of the medium experienced by the programmer gives feedback about whether or not the software is doing its thing right.
Michael Dubakov appropriately points out that doing things right ranks second. It is far more important to do the right thing to begin with.
Unfortunately, time wise, software is first implemented by programmers, and then later examined by the end-users. The natural sequence of development gets the priority backwards. To compound the problem is the fact that the longer the delivery cadence, the less effective the feedback from the end-user. Effective software development implies decreasing the time it takes between development and end-user validation.
Some Sample Practices of Friction
Hereafter we examine some approaches, to illustrate how they relate to the topic.
eXtreme Programming
In eXtreme Programming (XP), the practice of the On-Site Customer addresses this problem directly, striving to make the two feedback loops happen concurrently. This is the most efficient way to know if the software development effort is producing the right things rightly. Friction is as tight as it can possibly be.
With an on-site customer, the delay between implementation and end-user validation is practically eliminated. (The assumption is that the on-site customer truly acts according to the rules define for the role by XP, and actively cooperates in the development process on a continuous basis). The on-site customer can give the programmer immediate acknowledgement or rejection about what is being done. This is the highest form of “friction:” the programmer cannot take one step in the wrong direction, before the on-site customer is complaining.
Scrum
In Scrum the customer is represented by the Product Owner. The Product Owner is not the end-user, but a proxy – who, though, is still supposed to know what the right thing to do is. Compared to a situation where there is no process whatsoever, Scrum’s practices increase an organization’s internal friction, in order to produce feedback. These practices are:
- Daily Scrum
- Scrums of Scrum (if there are multiple teams)
- Sprint Planning Meeting
- Sprint Review Meeting (especially the “demo” to stakeholders)
- Sprint Retrospective
The friction is produced by the interactions and communication patterns that happen during these collective and collaborative meetings. Certain rules of Scrum tend to prevent dysfunctional interactions from occurring. (For instance, the rule that prohibits changing the backlog during the due course of a Sprint.)
All these meetings and ceremonies act like a conveyor belt that moves information back and forth, producing feedback loops, between all the parties involved. You can imagine the friction as the natural friction between the links of the belt. The more links, the less efficient the whole process is. However, it is better to have this kind of mechanism to transfer the resistance of the medium to those roles that do not experience it directly – rather than no mechanism at all.
Scrum’s Product Owner role is beneficial in those organizations where an XP on-site customer cannot be accepted (because it might not be “politically correct”), or when the end-user is truly in another organization altogether (like the user of a packaged software application, or a SaaS application). Unfortunately, this is also the main weakness of Scrum, with respect to knowing if the software is doing the right thing right or not. The true test will come only after final delivery to the end-user.
Continuous Automated Delivery
One of the most powerful developments enabled by the infrastructure of the Internet, is the practice of continuous automated delivery. Software is delivered automatically to the end-user as often as any valuable work item is completed. In organizations where an on-site customer is not available, and other processes (like Scrum) try to represent the end-user view point with a representative or proxy role, this practice has a powerful effect. It shortcircuits the distance between the developer and the end-user.
Also the broader the user base, the more effective the practice. It leverages Linus’ Law – typical of Open Source Software – in a commercial context: “Given enough eyeballs, all bugs are shallow.” In other terms, the surface of friction is increased; and hence it is more likely to produce valuable feedback.
It stands to reason that an XP on-site customer with continuous delivery to the entire end-user population provides the best opportunity to increase friction.
Friction and the Learning Organization
Feedback, and especially speed of feedback are of essence for fostering expert behavior. Dubakov refers to DUBNER-2006, who in turn describes the research of Anders Ericsson, a psychology professor at Florida State University. The relevant consideration is about medical training:
Ericsson has noted that most doctors actually perform worse the longer they are out of medical school. Surgeons, however, are an exception. That’s because they are constantly exposed to two key elements of deliberate practice: immediate feedback and specific goal-setting.
The same is not true for, say, a mammographer. When a doctor reads a mammogram, she doesn’t know for certain if there is breast cancer or not. She will be able to know only weeks later, from a biopsy, or years later, when no cancer develops. Without meaningful feedback, a doctor’s ability actually deteriorates over time
The surgeons are exposed to the resistance of the medium, while the mamogrpahers are not. Without meaningful feedback, ability deteriorates. While programmers and surgeons are individuals, we contend that the same consideration apply to organisations too.
According to Ericson developing expert performance involves “deliberate practice, setting specific goals, obtaining immediate feedback and concentrating as much on technique as on outcome.” It is striking how the concept of feedback and concentrating “as much on technique as on outcome” relates to ARGYRIS-1978 double loop learning organisations.
On the one side there is focus on learning about what is being done (outcome), and on the other on how it is done (technique). Again it is about doing the right thing (outcome), and doing it right (technique); about validation (outcome), and verification (technique).
By creating friction, the resistance of the medium is extended from those who interact with it (programmers and end-users), to those who don’t (executives, managers, etc.). This provides feedback to all intermediary roles involved. The quicker the feedback is produced, the better the organization can learn. It can learn about if it is doing the right thing (outcome), and if it is doing it right (technique). The quicker and the more it learns, the better the organization can act on improving its products (outcome), and it’s own processes (technique) for creating those products.
Friction is not Always Welcome
Dubakov also reflects on the fact that transitioning to agile processes becomes problematic when it is extended from the single team to the entire company. It appears there is a clash of cultures within the organisation, and a number of conflicts emerge.
The situation, though, is not peculiar to agile transitioning. It is more generally observable in any organization that strives to adopt systems thinking approaches – for instance Lean or Theory of Constraints. Systems thinking approaches are inevitably based on feedback loops, and feed back loops need friction to manifest themselves.
Friction is not always welcome, because it uncovers conflicts, and conflicts force people out of their comfort zone. There are ways to overcome such systemic conflicts (but that might be the topic of another post).
Friction as a Risk Strategy
A learning organization becomes more easily change tolerant, and hence better equipped to deal with business risk. Embracing friction, is a way to foster risk entrepreneurship, where undertaking risk is seen as a winning business strategy. Friction will allow any company to better deal with the ever changing conditions imposed by the market, the legislators, the envvironment, and so on.
Friction is like training: it prepares the company for the real race – the race that happens in the marketplace.