From Product Owners to Product Pwners
It's time for the quarterly blog post! (In reality, people who want to follow me probably do so via Twitter.)
Sometime last autumn, I finally got around to finalising my e-pamphlet on security in agile product management. I wrote the article, Software security in agile product management, for two kinds of people:
- CISOs who, one day, get a visit from a guy whose business card says he's a "coach", wearing hipster horn-rimmed glasses, and hear that your R&D is going to be agile from now on.
- Product Owners, who would like to go beyond the security features and actually help the teams to create secure code.
The former group tends to be of the opinion that having security in agile product development is hard. My argument is that it is not, if you are running a mature agile process. Scrum needs to be seen as an engine that consumes backlog items and produces working code, and if you feed software security activities into that engine, it will be reflected as a quality in the end product. This, of course, requires that the engine doesn't leak, or that it doesn't have some sort of ghost inputs.
The part that is of interest to Product Owners looks at bringing software security into a Leffingwellian "backlog feeder" system. The focus is on security requirements elicitation and getting non-functional security requirements in. It is important to make all security work visible on the backlog so not doing it will be an explicit decision, and also to make the cost of security visible.
(The rest of this post has nothing to do with security.)
The article was also a try to use Adobe InDesign to produce an e-book simultaneously with a PDF. If you have a high resolution display, say, a proper monitor, iPad, or a colour printer, I would recommend getting the PDF. It turns out that the HTML and EPUB exports leave a lot to be desired. I fed the HTML inside the e-book container to a validator and apparently the output doesn't even validate. Getting the pictures into their right places with respect to the text flow required manual (!) editing of the HTML. I spent significant time cleaning up the document XML representation in InDesign, and I have to say that the usability leaves a lot of room for development.
It appears that the support for reflowable and flexible documents is pretty hard to add into an application geared towards print production. This is visible not only in the e-book support but also in their newer products such as Muse (code name), where the designer is supposed to know the web page dimensions in pixels. I wish we finally got rid of "best viewed in 1024x768" footnotes and "we have detected you are using a mobile phone, would you like to view our mobile site" popups.
If I were the InDesign Product Owner, I'd probably beef up the document structure view of InDesign so that the document could be edited in the "DOM domain" (for logical structure) and a number of "layout domains" (for output in print PDF, reflowable HTML5, e-books, etc.).
Other articles in category /Computing/Security --
Share link






