Progress with writing the book

Inspired by a new comment on my last post, it’s time for an update .
I’ve found that going from writing the occasional blog post and preparing course materials to writing a novel with four (potentially more) main characters is a little like going from composing a doorbell chime to composing the Ring Cycle! Turns out there’s quite a lot to handle.
Most of the work I’m up to is research. The great advice “write what you know” definitely applies. So to write about Mesolithic hunter-gatherers is taking a whole chunk of research, this not being a lifestyle with which I’m personally highly experienced. Toddling down to Whole Foods and the local farmers’ market doesn’t count, it turns out.
Now, this research is reward in itself. I’ve been learning about hunter-gatherer er… hunting and gathering. Ray Mears is the fellow for that, and his excellent series (and book) on wild foods now on YouTube. That’s led me to scratch the surface of anthropology with Robert L. Kelly’s “The Lifeways of Hunter-Gatherers: The Foraging Spectrum” chock full of interesting data about, for instance, the ratio of energy expended versus energy gained for various foodstuffs. I’m sure that your Mesolithic forager wasn’t thinking in calories, but you can bet your boots that when your life’s major concerns are food, shelter, and safety that you get really good at acquiring them for the least effort. Had I a spare lifetime, I’d so nerd out with this whole field.
Then there’s how youngsters are brought up. (I’m avoiding the word “children” where possible since there are strong arguments for the concept of “childhood” being a relatively modern development.) “Ancestral Landscapes in Human Evolution” is a very dry title for a rather entertaining, if academic, collection of papers on child-rearing over the millennia. Clearly this is a field filled with scholars capable of adding delight and wit to their scholarship. The short version seems to be that little ones, long ago and once weened, learned by playing. Their play would largely consist of imitating adults, and so, with a little adult supervision and gradual inclusion into the world of adults, often formalized with a rite of passage, humans grew from dependent infants to great competence without any hint of formal education for almost all of human history.
And so these are just two of the many themes in the book: survival and “education”. Others are family, social group size and society, communication, possibly religion (a hot potato, so we’ll see), sex and gender, dogs and other animals’ domestication, fun and fear, tools, music and art, and the big one – relationships.
I’ve started writing, and have finished first drafts of the Mesolithic sections of the first three chapters. This has revealed to me just how much is entailed in keep track of details to ensure consistency. It’s also revealed how much research I’ll have to do when I get to the farmer character, as I’m still not clear if they’re going to be set early in the Agricultural Revolution, or in the middle, or towards the end. Much research and drafting will get me there. When it comes to the Industrial character, there’s a much shorter timescale and I’m familiar with most of it through my degree in literature and delight in Victorian history. Of course, when I finally get to the last character, the software engineering manager, this is a world where I can “write what I know” with very little research at all!
All the characters move through the arc of the Hero’s Journey dealing with all these themes, and through them demonstrating that we have become less and less well adapted to the world we’ve been creating.
But there is something we can do about it…

The book I’m writing

I’m publically declaring here that I’m writing a book.  People close to me have urged me to say this in public to create a structure of accountability and support to make sure it actually gets done.

The Book

“The Wolf in the Workplace”: a novel of four parallel lives.

Why?

The intention of the book is to leave people clear that they can learn to do what it takes, with ease and grace, to lead a life they love, regardless of circumstances.

What?

It is the story of four people. They all live in what we now know of as the South of England, in Hampshire.

The first lives roughly 12,000 years ago, as a hunter gatherer at the time of the end of the last ice age. His name, unrecorded anywhere, but if we were to know it in modern English, would be Swimming Bear. He lives as humans have lived for 10,000 generations, fully adapted to their environment.

The next lives about 4,000 years ago, as agriculture is causing humans to settle down, and in settling down they are discovering that they have been domesticated by their crops and livestock, and that the new “civil” society brings problems as well as benefits. His name, Mael, is in records of trade with merchants from Southern lands.

The next, Harry Arkwright, is an industrial worker living about 200 years ago. I’ve yet to decide if he works at the Portsmouth Block Mills, the world’s first production line, or if he’s a piece worker making chair parts for one of the great cabinet makers, or if, poor man, he’s stuck working in a textile or iron mill. His life sucks, and is physically very hard.

Lastly we have Sheldon Park, a software engineering manager, living right now. His life looks pretty good from the outside, but on the inside he’s in agony and misery. Under pressure at work and in a lousy relationship with kids that don’t respect him, he lives from moment to moment hoping something will make it better. One day.

The four stories will all pass through the same spaces of human development. In each space, their experience will differ increasingly dramatically. Swimming Bear’s life never occurs to him as “hard” as he’s fully equipped for it. Sheldon’s life is awful as he has no “built-in” equipment that actually works for this life. It was all created for Swimming Bear’s life! And yet, Sheldon gets an extra that the others don’t – he is introduced to The Work (an imagined synthesis of Landmark, NLP, Theory U, Conversations for Action, neuroscience, paleo-anthropology, sociology, all the ologies, etc etc) that transforms his experience of life. The point being that his misery was inevitable and out of his control until his view of it totally alters, and he gets that with an act of will, continuous practice, and recreating his intentions every moment, he can have the most astounding life.

How?

1. Build out the form of the book. Four lives, parallel spaces (the Hero’s Journey provides the essential spaces), different experiences in each space. Several physical “McGuffins” connect them all: canines (the “Wolf” in the title), a flint arrow head, their diets and physical exercise, their family and “tribal” relationships, and so on.

2. Write the stories – the content within the form. See what emerges.

3. Test: Show people, see what it means to them, what it evokes, and do so iteratively and incrementally (huh…!) Take results into account to add to or modify the intention, form, or content of the book.

4. Find professional support for publishing. A publisher and an experienced novel editor to guide this into actual production.

5. Public response. How many copies sold? What reviews? What do people say on Goodreads?

The first three will happen together, iteratively and incrementally. The fourth will get started first thing in the New Year, and of course, may change the target completion date.

Schedule

-By Dec 31st 2016: Have the framework largely established, the core characters well fleshed out, their supporting characters determined and fleshed out (e.g. “the clothes-maker” – a wise person who whispers in all their ears. FYI, making clothes is actually the world’s oldest profession!). The narratives all at first rough sketchy draft. Updates publicly posted on my blog.

I’ll also get a clearer sense of the rhythm of working on this.

-Between Jan 1st 2017 and April 30th 2017: Find and engage a publisher and editor. Adjust the book within their advice. Redraft the narrative until there’s an emotional reaction from test readers – without that the book can’t live.

Support requested:

You all can help me by looking out for where I’m wriggling out of getting this done. There will be tons of fascinating research, so please check in with me whether it’s actually contributing to the book or if it’s become a rabbit hole. (I’ve already got into researching the habits of wolves, how to make flint weapons and tools, how ancient people were named, the history of the industrial revolution etc etc. Awesome!!!!)

I’ll also “get busy” and offer ingenious and highly enrolling reasons for not working on the book. I may get resentful and defensive when you check in with me, and try to hide it. I’ll forget to check in. I’ll drill into detail (“aka get fascinated”) so check that I’m heading out the other side of the detail to the Big Point that will be actually useful.

I’ll start not getting enough sleep: I’ll stay up late writing then f*ck-up work because I’m fuzzy headed and use it as a reason to bail on the book. (aka Sustainable Pace).

I’ll, of course, totally miss what I don’t know that I don’t know, so feel free to point out the glaringly obvious stuff to which I appear to be wholly oblivious!

Thanks!

If you’d asked me beforehand how I’d feel if someone declared that a whole team was going to be standing over my shoulder as I worked on this, I’d have lied to you, then run for the hills!

But when a coaching team member actually declared that the team’s job was to make sure this got done, my actual experience was overwhelming relief! And then an urge to run!

As a good friend keeps reminding me “It’s worth doing if your reaction is ‘Yes! Yes… Hell NO!’”

Fundamentals: The first line of the Agile Manifesto

How much wisdom is in the first line of the Agile Manifesto?

Well, what is the first line? I ask, because I all too often see people think that it’s “Individuals and interaction over process and tools”. That not the first line. That’s the first value, and I’d argue that missing the first line means that you’ve totally missed the deeper context for all of Agile thinking.

“We are uncovering better ways of developing software by doing it and helping others do it.”

That’s the first line. If you doubt me, check AgileManifesto.org.

Before you think I’m just being pedantic I’d like to walk through this sentence and really bring out its glory.

  • We”: this is something that’s done collectively, not alone.
  • are”: it’s done in the present, in other words all the time. This is not an invocation of past insights, it’s a reminder that you need to be present, in the present, conscious to what’s going on right now, and not relying on what might have happened in the past.
  • uncovering”: not inventing, or selling, or theorizing, or proposing. By being present, by paying attention to what’s going on here and now moment by moment, we can uncover what is emerging. Paying attention to the work will reveal how the work is actually working.
  • better”: not best, but better. In a creative field there is no best but there could always be better.
  • ways”: what ways? We’re not saying. We can’t. We don’t know. We are uncovering them. Agile has no answers! Sorry about that. If we thought we had the answers – the ways – we’d be selling you something that had worked for us in some situation we were in. Not your situation now. So we might achieve compliance if we had enough authority, but can you smell the hubris in that? The whole point is that we’re doing something creative. Something we’ve never done before. If we had done it before, we’d be using that! The trap is thinking you have done something before when you haven’t and relying on the “ways” that worked back then. The word “playbook” – I’m looking at you! And you, “standard operating procedure”! Those ideas are useful, even necessary, but they’re simply not sufficient in an rapidly changing world.

Where was I?

  • of developing software”: the authors of the Manifesto were at the time only thinking of software. But by taking out these words and replacing them with “working” we have a much more broadly applicable philosophy emerging. For developing software of course this all applies. But starting to work consciously, always being present to what’s emerging, that’s helpful in any field. It’s dogmatic to insist this only applies to software, and it’s closed-minded to think, for example, that “hardware can’t be Agile”. Remember “ways”? Uncover some better ways for hardware, why not? For accounting? Why not? For facilities? Why not?
  • by doing it”: the ways are being uncovered by the actual practitioners. Not theoreticians. Now theory and academic work is essential, I grant you. It can shift the paradigms of thought in which the work occurs, so it can actually accrue as “experience” not just “time served”. Ten years thinking the same way is not ten years experience. So think, and do. But theory on it’s own, no matter how fascinating, is ultimately of no value unless it’s applied.
  • and helping others do it”: which rounds us back to doing this not just collectively but also collaboratively. You get more done working with people than you do alone. More than that, it speaks to a deep principle of life: you can get whatever you want if you help enough other people get what they want. Remember where the money comes from.

This is the first line of the Agile Manifesto:-

“We are uncovering better ways of [working] by doing it, and helping others do it.”

It goes on “Through this work we have come to value-”

Now go read the values and principles and see if they don’t taste different than they did before you read this article. Delicious, eh?

Social Automation

I do love finding a couple of words that sum up a subject neatly. The latest: “Social Automation”.

This popped into my mind (thank you, Subconscious Me) as the point of regular scheduling for meetings and ceremonies. Once their times, locations, and where possible, standard agenda and so on are all set, the brain-burning cognitive load has been lightened.

This is very like David Allen’s thinking behind GTD. If you have a system to capture all your outstanding “open loops”, and use the system reliably, the cognitive load of holding all those open loops is gone. Lower stress, more brain power available for doing the things rather than grinding on all the almost remembers things to do.

So ( favorite question) hands up those here who are not professional. Right? Merriam-Webster has “professional” as “relating to a job that requires special education, training, or skill”. I want my energy to go into the job or increasing my “special education, training, or skill” not into the noise around it.

Remember, our brains are phenomenal pattern-matching threat-management engines. The more habitual the pattern, the less fuel the engine requires. Habit rocks!

So use habit to lighten the load.

The trap? Using habit to lighten the wrong loads. Or to go unconscious. Or to rely on “How it’s done round here” for something that actually requires some active thought.

That’s the point. Use habit aka Social Automation to lighten the load so you have the fuel available for the active thought.

Did I just reinvent Scrum?

They took the Null Set! From beyond!

I had one of my occasional agile dreams last night.

Because we’re rewriting the product owner training, I needed an exercise to challenge the participants to create a truly innovative product.  (Remember, this is a dream.)

The challenge is this: something is poking through from beyond our dimensions, just like a finger descending from above into Flatland.  It has taken the “null set” from us.  The product challenge is to resolve this situation.

I told my wife this dream as we both woke up.  Sensible woman that she it, she responded “Alien from another dimension eh?  Have you tried communicating with them?  They’ve taken all your zeroes?”  I didn’t point out that zero and null aren’t the same, it didn’t seem to be the right moment.

This dream, of course, felt like it had taken up half the night, and was so important, I should have gotten out of bed and immediately updated our training material.  I didn’t, and perhaps this is an opportunity missed.

So, dear reader, if you have a solution for aliens from another dimension stealing your null set, an innovative solution mind, then please write in on a 3×5 card, attach it to a mint-condition R-series Bentley Continental Tourer Fastback and submit to your author through the usual channels.

Sublime and ridiculous

Here’s the sublime: http://arlobelshee.github.io/AgileEngineeringFluency/Stages_of_practice_map.html?  Arlo Belshee’s clarity is just dazzling.

And here’s the ridiculous http://lafable.com/  You Agilists should find this highly entertaining, and you may be surprised when you find out who’s behind it.

I’m clear that oddly, the message in the comical one is what’s missing from the serious one.  Arlo’s graphic is fantastic, but it is dazzling, and dazzled you might miss something.  What is it? Take a look, what do you think?  How would you express that message?

Why are estimates nearly always low?

Why oh why?

How often is an estimate correct? Why do we seem to under-estimate so often? We can’t always blame the pointy-haired boss.  Can we?

2015-02-16 Estimates DilberWell, no we can’t.  Really, we could have some sympathy for those pressuring us to higher certainty and lower costs.  They’re just trying to reduce risk, even if the risk is of looking bad. Maybe they’re stuck in a world of cost accounting, unaware of its impact or alternatives.  If a project has overrun, and if all you know is detailed estimation, then it’s easy to assume that you can’t have done enough detailed estimation.  So there’s an urge to do more of it!

Doing more estimation is a waste of time and energy.  Let me show you what is going on here.  It is something simple and fundamental.

Let’s Estimate Something

Here’s some work we’re estimating. Let’s consider everything that could be known about this piece of work.

IMG_1212

First, there’s some of it about which we have a high degree of certainty.  We know what we know about this.  Let’s call this KK – Know what we Know.

IMG_1213

Then there’s the rest, the stuff we Know we Don’t Know. Call this KDK. This must have a degree of uncertainty, by definition. We could manage the uncertainty if we buffer the estimate.  With a mature and wise customer, we could provide a range.  The risk is that we assume the high end is more realistic, and those employing us turn the low end into a deadline.

IMG_1214

So, we’re done.  That’s our reasonable estimate.  Quick! Commit!

Easy, tiger!

Wait!  We’ve missed something.  It’s not a reasonable estimate.  As it stands, it’s pretty much a guarantee of failure.

What are we up to here? We’re developing something new.  If we were developing something that wasn’t new, we wouldn’t have to estimate it, would we?

If it’s new, there must be parts of it that we Don’t Know that we Don’t Know (DKDK), by definition.  I mean – it’s new!

Here’s my question: will DKDK lead to more  work or less work?  (Hint: it’s MORE work!  Duh!)

IMG_1215

Well, here’s a grain of solace.  Inside DKDK is DKK: what we Don’t Know we Know.  Some stuff  turns out to be very like something else we’ve already done, and we hadn’t realized it until we started work on it.  This will account for those occasions when the estimate turns out to be high – sound of heavenly trumpets!  But since we usually remember what we know, these occasions are not the norm.

IMG_1216

The point remains: it’s all pretend until we start work on it and start realizing – making real – what’s actually involved. Nothing is certain until– when?– until it’s actually finished!

The truth is out there

Take a look at Steve McConnell’s classic work on the Cone of Uncertainty.

 

Note that the broad end of the cone, at the time of producing the estimate, gives a range of accuracy of the original estimate of from 25% to 400% of the actual. 

The Standish Group’s CHAOS report shows this clearly.  Here’s the table of Time Overruns from the report.

Time Overruns  % of Responses
Under 20%  14%
21 – 50%  18.30%
51 – 100%  20.00%
101 – 200%  35.50%
201 – 400%  11.20%
Over 400%  1%

Look at this as a histogram:

image

Thanks to DKDK the work more often ends up running long.  Sometimes, sure, it’s early thanks to DKK.  Only 20% of the time does the combination of KK and KDK prove roughly accurate. 

Over to you

This is why the wise thing to do is turn the iron triangle upside down and declare that the team is fixed, the time is fixed (by sprints), and the scope is variable.  This isn’t just wise, it’s because there is no such thing as a fixed scope!  The scope of anything that hasn’t yet been created is unknown, and so must be variable.  It’s all pretend!

Now, do I need to explain the genius of relative size estimation using story points, limiting work in progress, and reducing cycle time?

The only sensible thing to do is to estimate using a scale that is course grained, recognizes that the larger something is the more uncertainty there will be, and is local to those doing the work. Hence Story Points and Relative Size Estimation.

It’s only sensible to limit the amount we do to the smallest possible amount so we can check with our customers if it’s actually useful to them quickly, and adjust course accordingly. Continuous planning makes sense.

It’s only sensible to minimize up front detailed specification and estimation, as that’s the point when we know the least. Understand what is meant by Last Responsible Moment.

So give an estimate, sure.  Estimate the whole thing.  But it is unprofessional and irresponsible to then allow yourself to be held to a fixed scope in an Agile world.  Don’t do it.  You’ll only disappoint your customer when the intention was to delight them.

Comments, as ever, are more than welcome.

How to handle Engineering Stories as a Business Product Owner.

Keep it simple.  As a Product Owner, you’re responsible for the “What” and “Why”.  The team are responsible for the “How”.  You’re responsible for prioritizing the backlog, in fact this is your main responsibility.  So for those engineering stories that you simply don’t understand as they’re technical gobbledygook, then just come back to the basics of user stories: the Three Cs.

  • Card
  • Conversation
  • Confirmation

You can write the card with the team’s guidance very easily.  Story: Ranking engine research.  As the customer options system, I need a ranking engine so that it is possible to present options in preferred order defined by a combination of business rules and customer preference.”  There, that wasn’t so hard.  There’s your Card.

Now for the Conversation.  “Guys, I need some help to prioritize this…” will lead to a conversation about size, difficulty, dependency, value from learning, buy versus build, and so on.  That’s great.  And it might not need to be written up in the story, as what value would that give.  If there’s a core agreement you want to document to remind yourselves during the sprint, sure, write that.BritGirlCatBoyDogknit

Now, how about the Confirmation.  That will probably mean the team needs to help write the Acceptance Criteria.  They’ll have some idea what required for the story to be complete.  Document that in the story’s acceptance criteria.

Now, you’ve done your job.  You’ve written the Card, you’ve had the Conversation so everyone’s got as much understanding as they need in their role, and you can Confirm with the team that they’ve met the Acceptance Criteria, so you can know that you actually can accept it.

Do it the way it’s designed, it turns out it’s pretty straightforward.  Don’t get caught in the weeds.