Is Scrum a good fit for software factories? A few days ago in a CSM workshop, there was an exciting debate around this topic.
Out of curiosity, I polled on Instagram (@martinalaimo) the same question. Of just over 100 people, 77% tapped yes.
Biased by my experience and that of many close people, my opinion is unpopular: Scrum and typical Software Factories are incompatible by nature. The core of my belief lies in the "typical" word.
But to moderate that bias, I asked again, this time on LinkedIn and Twitter. Almost 5000 people saw this query and there were only 7 comments, most of which were valuable contributions about opinions and experiences, but none directly answered the question.
I also shared my opinion on Instagram and received lots of feedback reinforcing the idea that Scrum and typical Software Factories don't match without first introducing profound changes in the service and the business model.
The source of the incompatibility
Here I share the most frequent impediments I've met.
Business model
In a typical Software Factory, a customer provides a requirement or specification and the "factory" builds the software according to that specification. For the "factory" to be competitive it needs to sell more. In many cases, the strategy to achieve more sales is to lower prices and optimize costs, such as cheap labor, standardization of processes and specialization of tasks.
An important aspect that reduces costs is the reuse of software components. Although not often efficiently implemented, it is another advantage of a factory that maintains a stock of standard parts that it can then integrate into its multiple projects to reduce the effort required to build a product.
We see impediments to the adequate use of agility when:
- Big-designs-upfront are created to mitigate learning risks by searching for anticipated detail,
- The client's request is strictly regarded, assuming one of two possibilities: 1) that what the client asks is the right thing (the exception to the rule) and 2) that the responsibility for knowing the problem and the solution is exclusive to the client,
- Component teams are created to maintain the "stocks" thus creating multiple dependencies between projects and component teams.
Operating model
Operations mostly consist of "projects" where success means delivering the client's specifications timely and within a pre-established budget. Strong monitoring and control processes, and a lot of accidental complexity created by bureaucracy and traceability of decisions arise as a by-product to achieve these goals.
Specialization in the task spread isolated departments (design area, programming area, testing area, etc.). Their people (resources) are assigned to various projects to increase efficiency.
In practice, impediments to agility arise where:
- The accent is on delivery rather than the value of what we do
- Processes become so bureaucratic that they interfere with people's creativity
- Autonomy in decision-making is limited and processes can't be altered based on what has been learned, which goes hand in hand with the team's lack of empowerment in continuous improvement
- People don't focus on products. Instead, they are more committed to their individual assignment than to teams or results
Culture
These organizations are prone to creating an “us vs. them” feeling between developers and customers. Mistrust and blaming loom large in critical situations. This environment leads to avoiding clashes by calling on the opacity of information. There is often the phrase: "the client can't know this".
The strong interest of the factory in delivering projects makes it very hard to give rise to a product culture where development teams seek to have a long-term vision and understand the real problems of customers by approaching them and measuring success based on the outcomes. What prevails instead in this space is the I-did-what-you-asked-me-to feeling.
Rework is a bust, the consequence of a misunderstanding of what has been requested, or the result of professional negligence. It is seldom interpreted as a natural aspect of evolutionary product development.
There are barriers to agility when:
- The product owner is excluded from the team for supporting the client
- The relationship with the product owner is purely transactional
- There is no transparency towards stakeholders
- Mistrust takes hold of relationships
- People don't know the aim of that thing they are building
- There is no sense of purpose in the work they do
- The behavior is more mercenary (tell me what to do and I'll do it) than visionary (I empathize with the client and it motivates me to solve their problem)
People
Teams build from a majority of professionals at the early stages of their careers to reduce costs. You've probably heard of "junior resources." Otherwise, the numbers don't add up. This limits not only the complexity and quality of the products created but also career improvement because fast growth means that salaries will also grow and soon the business model is no longer profitable.
To solve this deadlock, developers chase growth by shifting companies. Instead of moving up within the company's ladder, they get that promotion in the fashion of a tempting offer from another company, resulting in elevated attrition and a shortage of stable teams.
Limits to agility are visible when:
- Teams are unstable and have a low sense of belonging
- Narrow experience prevails
- People are frustrated about the learning curve enabled by the company and the quality of the work
Mindset Shift towards Digital Products Crafter
All of the above doesn't imply that a software factory holding these four mismatches can never successfully take advantage of agility. However, there are some necessary changes for it to happen. I rounded up all these changes under the umbrella of transforming a Software Factory into what I call a group of Digital Products Crafters, inspired by the Software Craftsmanship proposal and extended to all those involved in the creation of a product, not just the software that materializes it.
Business model
Unlike the model based on the industrial notion of software where competitive advantage lies in cost savings and large-scale production, the new paradigm of digital products promotes technological novelty and customer delight. In other words, amazing products.
To achieve this goal it is necessary to start by thinking of this drill as a crafting discipline where each product requires a unique and unrepeatable effort of understanding users and their problems. It means a continuous path of exploration and discovery that can't be replaced by a full and anticipated definition of things.
The bond with the customer must go from being transactional to relational. The former Software Factory will symbolically associate itself with its customer rather than simply be a service provider. This association idea is strongly reflected in the operation and culture of the company.
Another important and surely disruptive aspect of this business model is that the service does not only consist of creating the product but also in bringing to life the product team and transferring it to the client. Aside from the product, the result is the team that has created it and will make it grow over time. How is that? Well, a particular trait of our times is that a successful digital product can rarely be considered finished. When was AirBnB, Uber, Spotify, Instagram finished? The answer is never. In order to stay current, a continuous work of exploration and adaptation is necessary and, once this objective is reached, it must continue to be done to maintain success and avoid losing interest.
Operating model
Here we should humbly assume that the product team is not the end-user and that they do not know what the end-user needs.
With that in mind, instead of receiving a detailed specification they will now dissect a series of problems and will spend time with users or consumers in their environments, pay attention to them, listen carefully and observe them closely. Only from there could they have a rough idea of the solution they really need to create.
The SPOC or Single Point Of Contact, a common role in Software Factories that mediates communication between the client and the team, should no longer exist. From this standpoint, the product team is capable of communicating with the client (sponsor and stakeholders) and with end users and / or consumers.
Finally, progress will no longer be measured in terms of the output (i.e meeting milestones of the plan based on the scope and schedule), but in terms of the outcomes (i.e changes in the behavior of users or consumers of the product).
Culture & People
I could summarize this section in just one sentence: create a product-oriented culture within the organization. But what distinguishes a culture with these characteristics?
Focus attention on clients/consumers: all team members interact directly with customers, beyond the stakeholders. Their reason for being there is not to manufacture software, but to serve the customer's needs within the limitations of the business.
People are not there to build whatever. They are part of the product team because they care about the vision and help customers solve their real problems.
There must be a strong sense of innovation, a burning desire to experiment with technology and new paradigms to create great products.
For this you have to take risks. It is impossible to achieve outstanding product development if you are looking to constantly stay in the comfort zone. Learn greatly and fast about the riskiest assumptions.
There is a true collaboration between people on the product team consisting of software manufacturers, user experience designers, and every necessary role for product development.
Change takes 180 degrees. And so I think that agility, and in particular Scrum, can work in a former Software Factory that became a Digital Products Crafter.