Business value and #noestimates

I run a media production company and one type of productions we do are narratives, e.g. short films and feature films.

In during pre-production and production, there is a lot of scheduling and re-rescheduling of when to do what, where and with whom. The tools are often very manually oriented, which leads to extra work and increase the risk for errors.

This would be perfect if we could have a software program to handle this in a better way, on an iPad or a laptop on set when shooting the film.

We can describe how we are doing today and an idea how we would like to work in the future. This would be a a perfect project for a traditional developer and we could get an estimate for the cost for the program. Is to cost worth the benefit we can get from this is then the question we have to ask ourself.

But we can also go to a developer who practice #noestimates. He will start developing immediately and deliver business value really fast. It’s a really good story, but there is a catch.

In order to deliver business value to the user, we need a minimum viable product that works for a short film. The feature set for short doesn’t differ so much compared to the feature set for a full length feature. But the business value for a short film is very very low and a feature film is much more valuable.

So now I’m looking for a #noestimates developer who will develop this piece of software and get his or her payment based on the value we get from the using the program in one short film, with additional revenue when we do more short films and features.

Agile development and Privacy by design

A year ago, I talked to some people in a web-project that was run in an agile fashion. One of my questions was how they managed requirements related to the upcoming GDPR regulations. The answer was that we put them in the backlog. Formally correct from an agile perspective, I don’t think it’s the right approach for regulatory requirements. 

I would rather see the requirements for Privacy by design (Inform, Control, Enforce, Demonstrate, Minimize and limit, Hide and protect, Separate, Aggregate, Data protection by default) as product requirements and taken care of in each sprint.  Or at least before you deliver a minimal viable product.

Design business for privacy.png

But in order to comply with the regulations for Privacy by Design, you have to document more than the developers assumed.

You also have to add more features and think about the life-cycle management of personal information in your application. In essence,  more architecture work in sprint 0 to prepare for things not delivered in the first internal releases.

Then, there is everything related to security, and that it’s a topic of itself.

If you would like to listen to other aspects of Privacy by design, view episode #73 from Architecture Corner..

We need more DPO’s

View the discussions with Greger Wikstrand, Claudio Reyes, Christina Lundström, Mark Battersby, Jesper Kråkhede and Casimir Artmann where they discuss lack of DPO’s and the skills that are needed in the role.