An agile dinner

If we compare Agile Software development with preparing a dinner, it’s like when asking your better half what he/she want for dinner when you are at the local supermarket.

But, if you will serve a three course meal for some close friends, you have to plan more, as there are more guests and more food.

If you scale up the dinner to be a buffet for +50 people, then the agile approach will be a disaster and only rescued with large quantities of alcoholic beverages. Why? Simple, more guests and more dishes add complexity.

Next level is a large traditional wedding for several days. Do you dare to be agile if you going to be married?

Can AI be used in business?

I’ve been joking about setting up a firm called Creative Accounting. Today, an even better name is Hallucinating Finance Ltd.

As a CEO, you have to sign in ink, not in blood, that your books are in maintained in a proper order. The question is he or she would trust a AI engine based on LLM to prepare the annual report.

When coding, every bit counts, and when wrong, you are introducing nasty bugs. If you or other developers don’t understand the code, you need you need to re-write that part from scratch.

The main question is then when AI can bring benefits to our work? Let’s go to another stage.

In audio production, AI has present for several years. First used to clean up audio, shaping the sound with filters and. then to assist in mixing the different tracks.

With photos and videos, AI is used for cleaning up images and removal of unwanted objects. Coming up next is color correction and creative adjustments.

Creating content with AI, either writing stories or creating images is now done in a breath with AI. ChatGPT, Stable diffusion and Mid-journey are your tools.

The caveat is that creative copyright is only granted to humans, not computers. In essence this means that you can use it for testing ideas and draft sketches, not the final piece if you want to earn money.

What’s in common for all these examples?

My take is that when the output is subjective good enough, then AI-assisted tools are already of good use. When we are working with law, finance or engineering, and the expectation is correctness, hallucinations are out of question, and today’s AI-tools are not fit for purposes.

New at work

If you are new at work, and have a more senior position, I except two things.

1. Make a high-level plan of what you will do to succeed, and present it so I understand.

2. If you don’t know, describe how you will get the knowledge or how you can delegate part of the work

If not, you are not senior enough.

For an example, see http://disruptivearchitecture.info/blog/2021/6/15/Right-competence-for-the-job

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.