Measure software productivity?

McKinsey tell CXO’s that they can measure software productivity. I have not yet read how they do, so I will not comment their approach.

Kent Beck and Gergely Orosz co-wrote two well written articles on substack about their thoughts about how to measure software productivity, and I agree with them.

I see the similarities between software development and film production, as both are creative team efforts, and will use my experience from both fields to try to define a hypothesis for measuring software productivity.

Film production is show business, and in the end it’s all about the money. Box-office figures vs. cost of production and marketing. If you are software company, then you can measure success in the same way. When software is a part of your product and/or supporting your business, then the correlation between the software teams effort and the bottom line of the company gets fuzzy.

Film production is much more structured than software development. You write a script, in a very standardized way. A script consists of a number of scenes, and the length and complexity can differ very much. Think of the initial scene in La-la-land or a classic Bond-movie starting with a chase.

To green-lit a script for production, it should be of good quality, but also be doable within a budget that would recoup the costs to a certain market segment.

In pre-production you detail everything so when you are on set, you know what to do, and when.

On-set you have different teams with different tasks, as camera, make-up, construction of set design etc. all dependent of each other. Productivity here focus on how many scenes can we shoot per day, so we can follow the budget and be ready in time, with good enough quality for the director.

You can measure productivity for and individual or a team behind the camera as long as you don’t have dependencies. With skilled workers, this is not an issue. The challenge is the planning before, so that you use the resources efficient, avoid surprises and get a quality the audience expect.we fix it in post will other add more cost at a later stage.

I very seldom see the level of detailed requirements in software projects as in green-lit manuscripts for movies & TV’s, so software development is more akin to small indecent arthouse films and documentaries where you don’t know the details beforehand.

So my hypothesis is that it’s very hard to measure software productivity unless you have good and stable requirements, and very few dependencies to other teams. Task switching between projects also degrade performance. Here are the things to improve before you start to measure.

Good and stable requirements are unicorns, therefore software development should be more treated as R&D than a factory with metrics.

Finally, a question to the sales guys, how could you measure your sales performance if you don’t have any defined products, services or resources to sell and deliver?

(I wrote my first line of code in Basic forty years ago, and been in the IT business since 1986. Film production is a new endeavor since 2015, and I have been involved in Swedish and international film productions.)

MVP for a data product

This article is the continuation of the article EA case study: Example of a data product.

Data as a product

Creating data products that lend themselves well to sharing and re-use in hitherto unimagined ways should be the focus. Dehghani lays down 8 characteristics Data-as-a-Product should adhere to:

• Discoverable (we must be able to find it when searching)

• Addressable (when we have discovered it, we need to able to get to the data)

• Understandable (we should be able to understand the data, their internal relationships. and their relationships with data in other products without calling a friend)

• Trustworthy and truthful (the data must give a high quality and trustworthy representation of the concepts they are describing)

• Natively accessible (it should be easy to access the data with the tools we prefer)

• Interoperable and composable (it should be easy to correlate the data with other data in the organization, and create new products by combining others)

• Valuable on its own (we should not have to combine it with other products in order for it to be valuable)

• Secure (we should only be able access data in accordance with the company's security policies, respecting any limitations imposed by laws, regulations and internal guidelines (e.g., GDPR))

Design concept for an MVP

What if we start with a very simple design concept to show the fundamentals for a data product?

We create one page called “Data products” in our searchable intranet (discoverable). This page consists of a number of entries, with a data product description (understandable) and a link to the different data sources (addressable). 

For each source system we need to have a person who is responsible for the data quality (trustworthy and truthful).

They are downloaded as using CSV-files (natively accessible) and from the source system for those who have access (secure).

We can use the information in the data product directly (valuable), but also, by combining several data products in Excel, we can create new data products (Interoperable and composable).

The image above shows a page with links to existing data in Teams.

From an organisational point of view, we only need two roles to solve this MVP. One role who is responsible for the actual data product page and one role who is responsible for the data quality.

The major problem with this design is that it’s not scalable or flexible enough, so the question is how to solve these to issues.   

CSV-file for actors (empty). We have more than 200 actors in file that ben participating in our productions.

Too simple? We are talking about setting up a new business with (data) products, we don’t know if we have enough customers for.

Next design iteration

Discoverable - For us, this means internal store integrated in Office 365 and/or mobile devices.

Addressable - Interface directly without any need for middleware or conversions, and without wait.

Understandable - Use of business vocabulary and aligned with APQC processes for broadcasting.

Trustworthy and truthful - There should be named persons responsible for data in each domain (business capability), or more gradual. E.g. the production manager is responsible for data quality in his/her production.

Valuable on its own  - Based on business KPI and/or compliance with regulations.

Natively accessable - The tools we are using are based on Microsoft Office 365, thus, the data products should be accessible from this platform for all business users.

Interoperable and composable - One, and only one information model for the organisation. As part for TME sector, we will use TM Forum’s models and make additions when needed.

Secure - Privacy by design is a an Architecture Principle and all designs must adhere to this paradigm.

The third article in this series will be about an example high-level design for data products and management.

EA case study: Example of a data product

What is a data product? 

 The concept is still a bit fussy, and we will use the EA case study to create three different examples of data products. For this article, I asked my colleagues Anders Friis & Daniel Hellerstedt for help.

 "A data product is a reusable data asset, built to deliver a trusted dataset, for a specific purpose. It collects data from relevant data sources — including raw data — processes it, ensures data quality, and makes it accessible and understandable to anyone who needs it to meet specific needs."

Examples 

We have previously talked about business events that triggers some process flows.

One of them is related to the need to report information about individuals according to GDPR. Today, this is a manual procedure but with a larger number of actors in our productions, there is a need for automation, thus the hypothesis to use data products. 

Yamdu: General information about an actor.

The second example relates to generic financial KPI’s from APQC. 

• Cost to perform the process " invoice customer" per invoice processed

• Personel cost to perform the process " process customer credit" per $1000 reveune

The third example are KPI’s more targeted towards film production budgeting and productivity.

• Scheduled pages of manuscript per day of filming and size of crew and cast

• Hours of pre-production, production, and post-production per minute of ready film and budget size

Information sources

The main source systems for crew and actors is Yamdu, but the service doesn't have an API. This platform is also the source of the bulk of the information related to film productions. Instead you can export and import csv-files about productions, schedules, actors, crew etc. 

Yamdu is the second production system we have, and before that, we used StudioBinder. The interface for data product should then be system agnostic, so if we change systems in the future, the interface should be the same.

As we have several sources for personal data, our approach for solving this must take this into consideration. Future expansion should include both Servera that is our CRM-system and Visma that is used for both finance and time reporting. Including Microsoft Office 365, we have four major platforms, plus a huge number of specialized applications for film production. 

What I as a user would like to have as an MVP, is a service that delivers the productions an individual have participated in, and in what roles. E.g. a very simple data product that contains both information about an individual and the data related to the production, thus more than master data. The data product should then be able to be extended to other types of personal information.

The information for productions can have very high confidentially and be very sensitive to individuals. Therefore, security and privacy are very important.

Design considerations

We are using Azure AD & Office365 and have a cloud first strategy, therefore the logical platform for our data products is Microsoft Azure. 

As we need to use batches to retrieve information about individuals from both Yamdu, Visma and Servera, and the individuals not necessarily are present in Azure AD, we need to store the information somewhere else. Same principle goes for other types of information.

The question is if we should go for a master data approach where we have all master data for parties, (customer, actors, crew, suppliers & partners) in one place, production related information somewhere else, and use the data mesh to combine, or use one big datastore for everything.

Information about individuals is present in several business capabilities, e.g. Sales, Finance, HR and Film production, but information about film production is limited to the latter capability. 

This is why my recommendation is to create a solution based on data mesh, even if our sources from the beginning only are in one capability.

When looking at open standards for information modeling and API’s, we select TM Forums models and Open API’s as we are part of Telecom, Media and Entertainment sector.  

Our business processes are mainly based on APQC for broadcasting, with some improvements in sales and production processes to better fit with our business model.

Next, MVP for a data product.

Nobody remembers a coward

I say to my colleagues that I don’t like risks at work.

This  may be a contradiction, as my risk tolerance compared to other persons are much higher.

At home & play, I’m riding difficult horses, been skiing off pist, scuba diving in caves, walking & skiing alone in the mountains,  off- shore sailing,  driving motorcycles and tried parachute jumping.

The owner didn’t want to ride her.

With these personal activities, I try to evaluate the probability and the consequences of something going wrong. A helmet and a safety west will minimize the damages when you fall. Don’t jump into the water if it doesn’t feel good. Follow the tracks if you are alone so somebody could find you etc.

The issues with large IT projects are that a lot of people are ignorant of the risks, and don’t take any actions to either avoid them or mitigate them.

What kind of risk do you dare to take, at work and at play?

Prequel to Dead Horse Theory

Oscar Berg just released a book where he used the dead horse theory in the modern office.

As a horse owner, who has taken away several horses, I can see the similarities with transformation projects.

Horses are big and fragile animals. They cost a lot of money every month and there is a huge effort to maintain them. If you can’t use them for anything, they will be a really expensive puppet for many years to come.

If your horse get an injury or get sick so you can’t ride, then you need to do rehab, but you can’t be sure of a positive outcome. If the injury doesn’t heal, the animal will continue to be in pain, and at some point you as a horse owner need to decide to take the horse away.

You often  invest lots of time in training a new horse, unless you buy a really expensive one, so just switching to a new when you have a problem is not a viable solution in the long term.

With Mimosa, the wild horse, the vets at the equestrian clinique didn’t give her any chances for survival when she got grass-sickness disease. Still, with the proper care, will-power and sheer luck, she survived. Some of our other horse were not so lucky.

The question for the steering group of a transformation program is the same as for the horse owner. Will it survive and give any value back, or should we let it die with our help?

Who are you going to call?