I’ve just finished reading Jack Hart’s “Storycraft: The Complete Guide to Writing Narrative Nonfiction”. Now, if you are going to write a book about writing, it’d better be good—and Hart doesn’t disappoint.

The book explains how compelling stories are comprised of structured elements. One thing that struck me is how closely these structures and elements are aligned with confrontation analysis.

Page 93 quotes literary agent Peter Rubie as saying that a good scene will:

• cause a subsequent scene to occur, creating cause and effect
• be driven by the main character’s needs and wants
• explore various ploys by the character to get his own way
• include action that changes a character’s position, relative to the end of the story

This general theme, of a protagonist who must overcome a series of challenges in pursuit of a goal, forms the “arc” of every great narrative.

This is exactly how we tackle problems using confrontation analysis.

Parties (protagonists) have positions (goals) that they attempt to advance by overcoming a series of dilemmas (challenges) through the exchange of (kinetic and non-kinetic) messages (action). Resolutions to one confrontation set the scene for the next as the parties struggle to achieve their goals.

Compelling narrative needs dilemmas.

It appears that confrontation analysis has potential as a design tool for creating compelling narrative. Strategic narratives, used to help us understand real-world issues and organizations, might be enhanced through a confrontation analysis treatment.

Without a formal process, there is a danger that a narrative will fail to draw out the essential elements. And, if the narrative is not compelling, those reading it will not be drawn in, making it difficult for them to extrapolate the story into the future—essential if the narrative is to influence what comes next.

Without a formal process underpinning the development of a narrative there is a danger that it’ll be a hard-nosed, “just the facts, ma’am”, news report—safely unbiased, but hardly absorbing. Strategic narrative, like all narrative nonfiction, needs to draw the reader in.

There is also much the confrontation analysis practitioner can learn from Storycraft—for example, when writing up an analysis in a way that brings it to life. Deft use of verbs and dialogue creates a sense of movement…action…that propels your narrative along. As columnist Jimmy Breslin said

News is a verb

The book also reminds us of the importance of developing character and scene—elements that are important when trying to understand a confrontation, but that are not formally addressed by the confrontation analysis process.

Read Storycraft. I promise you’ll learn something.

The article “Estimation is Evil” discusses the difficulty of accurately costing software projects—a subject of interest to anyone involved in contract software development.

However what struck me most in the article was a discussion of problems with an early, high profile agile project—Chrysler’s C3 payroll project.

The author argues that this project failed because it attempted to develop a comprehensive replacement for Chrysler’s existing system. While this system was perceived to have many problems, there were also many things about it that worked. So, a wholesale replacement was an ambitious undertaking.

What would have been better, it is suggested, would have been to focus on just replacing the parts of the system that were causing the most pain—sort of replacing the entire system one hated piece at a time.

It seems to me that this is very similar to the idea of designing larger systems as ecosystems of simple apps. Processes can be broken down into simpler tasks and each task can be solved using a loosely-coupled, highly focused app (see the article on “Mobile First”, for example).

Each app has relatively clear, well-defined requirements, making it easier to estimate. Granted, it may need to provide a variety of hooks for communicating with other apps in the ecosystem, but these can be added as required. Also, the tight focus of the app makes it easier to provide an outstanding user experience.

And, if the process changes, an app or two can be dropped and the ecosystem reconfigured—the “app swarm” can recover.

The “app swarm” concept is already working. It’s effectively how you use your smartphone—jumping comfortably from app to app as you go about your day.

Maybe it’s time you invited the “app swarm” into your organization…

Not one, but two, interesting posts from the blog Jury.me this week.

One is about focusing on the user. Too many apps are developed from a technical perspective—the latest frameworks, user interface widgets, etc.

Great products come from standing in your users’ shoes—trying to understand their goals. Why do they need this product?

Often it’s the product no-one notices that is doing the best job. I have a radio next to my desk. It doesn’t look very impressive and doesn’t have many features. But, I only listen to one station, so all I need is great reception—and it does that one thing really, really well. Great product.

It has been said that “the best user interface is no interface”. Indeed.

The second post that stood out was about the importance of shipping. This is related to focusing on the user—you learn a lot about your users when you put a product in their hands.

Shipping is one of the hardest things for a software developer to do. It’s easy to keep enhancing, extending and polishing…to give in to “feature creep”. But, your product only comes alive through use. And, until you have people using it, you don’t know if you are polishing something valuable.

This is were the concept of the “Minimum Viable Product” is useful. What is the minimum functionality you need your product to have before you ship it? What’s the minimum functionality that your users need? Build that, tidy it up, ship it and then be prepared to learn.

Enlist users. Find out what they need and let them try out your interpretation of that need as soon, and as often, as you can.

Budget Playground, an iPad app that allows New York State school districts to create multi-year budget scenarios is now available on the App Store.

According to an assistant commissioner at the New York State Education Department, Budget Playground

is like magic…It’s a terrific app on an iPad…I love the little charts on the side and the sliders to change scenarios are a very handy way to modify assumptions.

Prism Decision Systems and Decision Mechanics designed and developed Budget Playground for Cornell University’s New York State Center for Rural Schools.

Decision Mechanics recently developed a location-monitoring iPhone app for InMotion—a personal data management startup.

InMotion intends to provide services for individuals to take control of their personal data—sending it to a secure repository and allowing controlled access to third-parties who offer useful derivative services or financial incentives.

The iPhone app allows users to stream their location data to the repository.