Creating our story through dialog

A story pattern

Once upon a time there was

And every day

Until one day

Because of that

and Because of that

and Because of that

Until finally

And ever since

The above is a pattern for describing an evolving situation with no predictability on the final outcome. We know the starting point (Once upon a time), but we don’t know how the story will end. Tobias Mayer has made analogy between this pattern and Shakespeare’s style of stories.

For me this can be a drama too. Even in business and software development we can use the same pattern to describe how things evolve.

A story of a software company

Once upon a time there was a software company who was  losing money and kept shipping poor quality products to its customers late

And every day this company was in fire-fighting, receiving complains from customers and losing key people

Until one day its customers stopped accepting any further release and therefore stopped payments

Because of that they embarked to process improvement program for agile implementation

and Because of that they acquired tools, consultants and conducted training programs, infra-structural changes,…….

and Because of that they promised the customers that improvement are coming and requested  3 months break to show improvements

and Because of that they extended their agile implementation every where

Until finally the “3” months are gone and customer received the new shipment, surprise it carries almost the same issues!

And ever since the company discounted process improvement and blamed the consultants.

Process improvement instead of Agile roll-out

The above company has embarked to agile roll-out program rather than process improvement (PI) program. PI programs, in my view, are primarily discovery journey for the root causes rather than implementation of specific practices. Instead of implementing new practices,  they should have looked inward and face the factors contributing to the current state.

Let’s look at this pattern assuming we know only the starting point, end point and a in-between point as follows:

Once upon a time there was a software company who was  losing money and kept shipping poor quality products to its customers late

And every day ….

Until one day ….

Because of that they found that defects reported by QA are mainly due to poor unit testing

and Because of that ….

and Because of that ….

and Because of that

Until finally

And ever since the company produced quality releases on time

For me the blue line in the middle is a root cause that was not detected in the first scenario. Acknowledging this as impediment or constraint and building the story around it can help to mitigate the risks which contributed to failures of the first scenario.

What I liked about this pattern is that it’s intuitive. It helps people put their thoughts and probably there agony in simple way. It can serve the company to create its own destiny by acknowledging the “Because of that” then build their story to arrive at the desired end. It’s road map stated in the company’s language.

String of Pearls

The “String of Pearls” game helps  the team(s) work together to complete this story by doing whatever it takes to achieve the desired state baring the “Because of ” (constraints). The game requires dialog between team members instead of discussion. Nicely explained by Lyssa Adkins that dialog aims to find solution when two persons interact and each has good point to contribute and at the same time each is ready to give-up some of her ideas. While discussion is more like each person has interest to prove his preconceived thoughts.  Stating it in my language, dialog is solution focused while discussion is more competition based. Obviously, we need more dialogs!

Let’s assume that the team collaborated and stitched their thoughts into the following pattern:

Once upon a time there was a software company who was  losing money and kept shipping poor quality products to its customers late

And every day this company was in fire-fighting, receiving complains from customers and losing key people (as before)

Until one day its customers stopped accepting any further release and therefore payments too (as before)

Because of that they found that defects reported by QA are mainly due to poor unit testing

and Because of that they institutionalized a mandatory process for unit test

and Because of that they implemented automated unit test cases written by developers before start coding

and Because of that they mandated that developers must ensure their code passes the automated test cases before check-in

Until finally QA spent 75% less time in testing

And ever since the company produced higher quality releases on time

Finally

Rather than embarking into massive scale agile roll-out program. The company has implemented one practice that directly addressed the obvious (blue writing). Definitely the cost and duration of the implementation will be less with increased ROI. The key here was the collaboration between various groups in threading pearls through dialog to achieve the desired state. What is there “is there” and we do what it takes, given this situation, to find a solution through dialog instead of discussion (which is more ego based).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s