Tuesday, April 18, 2017

Design Your Competition's Support Department

You are presented with a common business problem.  One technique that has always helped me to define the problem space is to invert the problem, take it to an extreme to explore the continuum of your domain.  Let's imagine that we want to redesign our software support department at MegaSoft Corporation.  Applying our inversion principle we will leave our MegaSoft support as is, and instead we will design the competitors support group. It's going to stink, people are going to hate to even call them, their people will be arrogant techies with no human compassion - they will actually hire with those skills required.  Let's pause and give this company a name...  TechHard sounds great.

Who's time is most valuable?  At TechHard the support engineers time is very valuable, so we will have process that time how long a support tech. is on the call with a customer so that our process gurus can optimize for the use of this most valuable resource.  A typical call from a director or VP in our internal support operation should be logged by an administrative receptionist (maybe even automated system) and then the support techs time can be queued up with return call tickets.  We will return the VPs call when it is convenient for our tech.  The tech can validate that the VP is authorized to access the system, and will confirm that they are still experiencing the problem by walking through a standard checklist.  Being efficiently minded the tech may skip over some simple question like power plug, on/off, reset/reboot, logout/in again if they feel the user is competent.


Answering the basic question of who's time is most valuable via the design of the competition's process is enlightening.  Which is it?  The support person's time - or the customer's time.

How are support systems designed?  Has anyone ever heard of a company that used Design Thinking or High-Tech Anthropology to create a customer centered support group?

Is this Conway's Law at work - are we truly designing the support function of our products/services - or are we just reacting?

Give me an example of great design for support:  Nest Thermostat and Fire Alarm Installation
Have you installed a Nest product?  Their installation and configuration process is well designed.  I don't know about their support department - but my expectations are set very high, if I have a problem.


History will repeat
In the 1980s universities started teaching about design for manufacturing (robots would make the parts).

Are you designing your business departments for it's function?

Speaking of support tools - your going to want a great issue tracking system.  Why not look to a market leader that has all the features your people can put on a check list?  Let's buy Jira - or should we look at the competition's product?



See Also:

Cable Internet provider Frontier's support group struggles with the corporate infrastructure that can not resolve customer problems.







Can we have a dialogue about Estimation and the behaviors it drives?


Some topic are taboo - not safe to discuss.  I've never appreciated that concept.  Those taboo topics are my favorite topics to discuss.

Taboo Topics (ordered by fear of conversation)
  • Gender - Sexual preferences - non-standard practices
  • Religion as truth, my religion vs your wrong religion
  • Politics - the correct way to govern a group the results in my opportunity
  • Pay for services rendered - why my gender is paid more than yours
  • counting - off by one errors and how to mask them; we're # 1
  • estimates - how wrong your estimate was and why I'm missing my commitment
  • prioritization - ordering methods
  • laziness - the art of not doing work
I've recently been embroiled in a "dialogue" about the twitter topic of #NoEstimates.  I would write a summary of the topic but cannot do better that this one:

Estimates? We Don’t Need No Stinking Estimates! by Scott Rosenberg
"How a hashtag (#NoEstimates) lit the nerdy world of project management aflame — or at least got it mildly worked up."

A nice summary of the dust-up.  Imagine if the tag would have been #LeanEstimates?

There are two sides to this debate - at least two sides.  But I like that the taboo topic was raised and has questioned assumptions.  I think the think that drives a topic toward the taboo is this questioning of assumptions.  The saluter of scared cows (where does that term even come from?).

So what behaviors does the process or estimating drive:


  • a list
  • TBD
  • someone misplaced the list...


"Unable to estimate accurately, the manager can know with certainty neither what resources to commit to an effort nor, in retrospect, how well these resources were used.  The lack of a firm foundation for these two judgements can reduce programming management to a random process in that positive control is next to impossible. This situation often results in the budget overruns and schedule slippages that are all too common." -- J.A Farquhar
Does a Scrum process framework and the Agile mindset resolve Farquhar's concerns that the manager may have without accurate estimates - via empirical measurement and relative estimation techniques?

I'm not sure that the Twitter-verse is capable of holding the dialogue.  My experience was not very fruitful nor enlightening.  I've been accused by a manager at work of being "anti-management" I've asked, but got no direct answer, what that term meant, and why he believed or thought this label to be useful.  I've wondered if it was because of this type of conversation.  I also asked these fellows, but didn't resolve my query with the rhetoric of the conversation.
... deleted ... a lot of tweets about actions from years ago when when the #NoEstimates twitter conversation was beginning - some relating to a blog post being edited or complete deleted.  Something I find quite acceptable (and do quite frequently myself).






The conversation went on from there...  I'm reminded of Adam on MythBusters.



... and there is some link to Anti-Management because one is willing to discuss better options or worse options than estimation...


There appears to be large amounts of animosity amongst the principle people that were having this dialogue - nope that word is not the best word, here... try debate... twitter shouting match...








How might the analogy of estimation is like addiction be a useful analogy?




See Also:


Impact of Schedule Estimation on Software Project Behavior
by Tarek K. Abdel-Hamid, SRI International Stuart E. Madnick, Massachusetts Institute of Technology

Monday, April 17, 2017

Leadership re-envisioned in the 21st Century

Is there a new form of leadership being envisioned in the 21st Century?  Is there someone challenging the traditional form of organizational structure?

Leading Wisely - a pod cast with Ricardo Semler.
Leading Wisely

"Join organizational changemaker Ricardo Semler in conversation with leaders challenging assumptions and changing how we live and work."


S1E05: Busting Innovation Myths with David Burkus

S1E06: Merit and Self-Management with Jurgen Appelo

S1E07: Letting Values Inform Organizational Structure with Jos de Blok

S1E08: Corporate Liberation with Isaac Getz

S1E09: The Police & Self-Management with Erwin van Waeleghem

S1E10: Season Finale: The Common Denominator with Rich Sheridan of Joy Inc.


A ran across this series of 10 talks because I'm a fan of Joy, Inc. author and leader of Menlo innovations, Richard Sheridan.  I saw a tweet about his talk and found a bucket of goodness.
The Common Denominator with Rich Sheridan of Joy Inc.

Richard Sheridan on podcast Leading Wisely
See Also:
A Review of Leadership ModelsExamples of 21st C. Companies
Safety - the perquisite for Leadership
Joy, Inc : How We Built a Workplace People Love by Richard SheridanReWork: Change the Way You Work Forever by David Heinemeier Hansson and Jason Fried
Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage in Human Consciousness by Frederic Laloux

Wednesday, April 12, 2017

Multiple Views of Truth are Perceptions

These are a few of the images that resonate with me. For me they are very close to a door of perception. Now I've never done a mescaline trip, so perhaps I've no clue to what a door frame of perception even looks like... but these images are pretty good with a few beers and some colleagues to discuss there deep meaning and what truth is. Would we even know the truth if it walked up and slapped our face?


Translated: "This is not a pipe"


Cover image of book: Godel Escher Bach


This is Truth; while this and that are true

In any article I write that mentions a door of perception - I would be remise if I didn't mention one of my all time favorite poets and musical group - Jim Morrison and the Doors.  Now do you know that the band is named for?


Aldous Huxley's The Doors of Perception
"Huxley concludes that mescaline is not enlightenment or the Beatific vision, but a "gratuitous grace" (a term taken from Thomas Aquinas' Summa Theologica).[50] It is not necessary but helpful, especially so for the intellectual, who can become the victim of words and symbols. Although systematic reasoning is important, direct perception has intrinsic value too. Finally, Huxley maintains that the person who has this experience will be transformed for the better."

See Also:

Godel Escher Bach An Eternal Golden Braid by Douglas Hofstadter
This Is Not a Pipe by Michel Foucault
Art of Rene Magritte

Friday, April 7, 2017

Waggle Dance -or- Standup Meeting

Bees do a dance that bee keeper refer to as the Waggle dance...

It is with great pleasure that you can watch and using the power of science have this dance translated into English.

Bee Dance (Waggle Dance) by Bienentanz GmbH

What does this have to do with Scrum?  The power of a metaphor was well known to the creators of Extreme Programming (XP) - so much so, that it is one of only 12 "rules" that those really smart people decided to enshrine into their process.  It is also the most likely rule to not be mentioned in any survey of software development practices.  Unless you happen to be chatting with Eric Evens, and he may agree that he's captured the underlying principle in Domain-Driven Design, the Ubiquitous Language pattern.


Have you ever observed a great scrum team using a classic tool of many innovative company environments - the physical visual management board (Scrum Task Board). The generic behavior for a small group of people (say around 7 plus/minus 2) is for the group to discover that a form of dance where the speaker moves to the board and manipulates objects on the board as they speak gives everyone else the context of what story they are working upon and what task they are telling us they have completed. Then they exit stage left - so to speak. And the next dancer approaches from stage right, to repeat the dance segment. Generally speaking one circuit of this group is a complete dance for the day. The team is then in sync with all there team mates, and may have negotiated last minute changes to their daily plan, as the dance proceeded. In my observation of this dance great teams complete this ritual in about 15 minutes. They appear to need to perform this dance early in the morning to have productive days. And groups that practice this dance ritual well, out perform groups that are much larger and groups that don't dance.


So going all honey bee meta for a moment...  Let's use our meta-cognition ability to think about the patterns.  We love to pattern recognize - our brain is well designed for that (one of the primary reasons a physical visualization of work is so much more productive as a accelerator of happiness than virtualization of the same work items).

When do we use great metaphors - in design great NEW experiences for people that are reluctant to change.  And to communicate the desired behaviors, the exciting new benefits to adopting something new.  I'm thinking of the 1984 introduction of the Graphical User Interface by the Apple pirate team that produced the GUI, the Mouse, the Pointer, the DropDown Menu, etc.

Can you see a pattern in this... a pattern that relates to people changing systems, behaviors, disrupting the status quo?  It is resonating in my neurons, I'm having a heck of a time translating these neuron firing waves of intuitions, into the motor cortex to make my stupid fingers pound out the purposefully retarding movements on a QWERTY keyboard to communicate with you over Space-Time.  If only we could dance!

See Also:

The Waggle Dance of the Honeybee by Georgia Tech College of Computing
How can honeybees communicate the locations of new food sources? Austrian biologist, Karl Von Frisch, devised an experiment to find out! By pairing the direction of the sun with the flow of gravity, honeybees are able to explain the distant locations of food by dancing. "The Waggle Dance of the Honeybee" details the design of Von Frisch's famous experiment and explains the precise grammar of the honeybees dance language with high quality visualizations.
This video is a design documentary, developed by scientists at Georgia Tech's College of Computing in order to better understand and share with others, the complex behaviors that can arise in social insects. Their goal at the Multi-Agent Robotics and Systems (MARS) Laboratory is to harness new computer vision techniques to accelerate biologists' research in animal behavior. This behavioral research is then used, in turn, to design better systems of autonomous robots.



I was just reminded of @davidakoontz's wonderful metaphor for the daily #Scrum: waggle dance :) pic.twitter.com/h3c1B49mkC

— Tobias Mayer (@tobiasmayer) April 7, 2017


Monday, March 27, 2017

Generative power of Not-Knowing -or- Utopia


Polish Poet and Nobel Laureate Wisława Szymborska on How Our Certitudes Keep Us Small and the Generative Power of Not-Knowing

“Whatever inspiration is, it’s born from a continuous ‘I don’t know.’”

By Maria Popova  - BrainPickings

Purely for the fun of it, Maria Popova drew Wisława Szymborska’s poetic island in a map inspired by Thomas More’s Utopia.


Polish poet Wisława Szymborska (July 2, 1923–February 1, 2012) "explored how our contracting compulsion for knowing can lead us astray in her sublime 1976 poem “Utopia,” found in her Map: Collected and Last Poems (public library)" -- Maria Popova

UTOPIA
Island where all becomes clear.
Solid ground beneath your feet.
The only roads are those that offer access.
Bushes bend beneath the weight of proofs.
The Tree of Valid Supposition grows here
with branches disentangled since time immemorial.
The Tree of Understanding, dazzlingly straight and simple,
sprouts by the spring called Now I Get It.
The thicker the woods, the vaster the vista:
the Valley of Obviously.
If any doubts arise, the wind dispels them instantly.
Echoes stir unsummoned
and eagerly explain all the secrets of the worlds.
On the right a cave where Meaning lies.
On the left the Lake of Deep Conviction.
Truth breaks from the bottom and bobs to the surface.
Unshakable Confidence towers over the valley.
Its peak offers an excellent view of the Essence of Things.
For all its charms, the island is uninhabited,
and the faint footprints scattered on its beaches
turn without exception to the sea.
As if all you can do here is leave
and plunge, never to return, into the depths.
Into unfathomable life.

Thursday, March 23, 2017

Book Review:: Agile Noir by Lancer Kind


Tweet: Book Review: Agile Noir by Lancer Kind
   and I'm envisioning a 1956 black and white film
Kartar is the metaphor of his project.



First, allow me to layout some ground rules and a touch of the backstory...

I'm not a professional book reviewer, nor paid in anyway to read.  But if I could get that gig... I'd be a happy camper.  I've never written a book, but I've hacked out some code, a few articles, some of which might be considered book reviews.  I've worked in the Agile industry for more than a decade (but who's counting), and so - I may be a little close to the topic to have proper literary impartial bias.  In fact let me just go ahead and be explicit - I've done this, been there, got the t-shirt; I shit you not - this shit is for real!

Agile Noir by Lancer Kind

Now the ground rules...  I think this review will be written ... what's the word... while I'm reading, at the same time, without much delay in the reading - writing phases....in situ.... iteratively... oh I give up...

So don't be surprised - dear reader - if I just drop off in the middle...
                       ... maybe check back every week until I finish
March 22,
I've studied the cover... quite a nice graphic - to bad the whole novel isn't a graphic novel; oh - maybe it would be too bloody,  I could see Agile Noir becoming a Tarantino film.  As I sat looking at my book to-do stack... I skipped a few levels down the stack and pulled out Lancer Kind's 2016 Agile Noir.  I have read some of his previous comics titled Scrum Noir (vol 1, 2, 3).  So maybe I know what to expect - should be a fun romp in the fast lane with lots of inside the industry puns, innuendo and metaphors.

Well the damn dedication just reeks of an Agile Coach - Servant Leader (puke, barf.... moving on).

The High Cost of Schedule Slip
Now you may not find the situation Kartar finds himself in funny...  allow me to add some overtones of irony....  I'm going to go out on a racist limb and suggest that Kartar is an Indian.  That he is working in the heart of the Indian nation (Los Wages, NV), perhaps on a job for an Italian crime boss.  And none of these circumstances have anything to do with one of the world of science's biggest failures - Columbus's discover of the New World - which the thought was India, and named it's inhabitants there by creating the confusion we will have to deal with evermore.  Now Columbus was of course searching for a way to reduce the schedule required for shipping spices.

Kartar appears to be very emerged in planning and the art/science/pesdo-truth of planning and predicting the future of projects.  And he may be a master with the Gantt chart (which is footnoted on page 18).

This is all ringing just too true ... and I'm envisioning it in the style of a 1956 black and white film...

Kartar is the metaphor of his project... it seems that it's not quite on schedule... he's late to a just announced meeting with some superior and is driving at break neck speed on loose sand in the Vegas out skirts creating over bumps and ditches in his car with the accelerator pinned to the floor - because some people in a van might be trying to kill him.  Happens ALL - THE - TIME.

April 4th
Finished chapter 1.  That Bastard.  He killed off our hero Kartar.  oh - OPPS - SPOILERS!
I truly don't know if I should throw the book in the garbage bin or keep reading... going to bed.

April 6th
OK - that was quite the trick, Chapter 2, Rowing over a better Waterfall is a twist... but now it's getting interesting and our hero is back, yet I fear not quite in control of his project.

April 10th
The chapter Death by Documentation is just that... a death march, I almost quit.  The chapter is worth skipping if you have ever been on one of these classic projects - then you already know enough to thumb to page 89 and restart.  However if your not in IT or project management work of any type (Record Scratch: then how in the heck did you find my blog - and why are you reading this book?) you might enjoy the chapter as it will explain how all of your companies IT project fall behind schedule and never deliver what you want.  Read it - little bells of enlightenment will chime in your head.

The introduction of the IT Mechanic is quite fun.  He's almost a stalker... yeah, he's definitely a PM stalker.  This character is going to be fun.  He's reminding me of someone I've met... and someone from my youthful days of reading Carlos Castaneda.  The character's name is "J" could it stand for Jaun (as in don Jaun Matus)?  He's got an interesting calling card with no numbers or email addresses.  I'd recommend he try Moo - best printing house in the business.  J has some psyc skills and quite a few trick up his sleeves (he is living in the land of Penn & Teller after all).

I really enjoyed this chapter, but then almost any thing would be great after that death slog of documentation hell.

April 12th 
Sprinting is the right word for the next chapter... it's a dash by Usain Bolt.  In Sprinting with a Bollywood Autobot Kartar learns to write user stories and mix drinks of analysis, design, requirement, and development.  He attempts to negotiate on delivery with the owner and in the end crosses the third rail of the PMI tracks in a Lovers quarrel.  Oh - damn, that's not at all what happens.  But it's a lot of fun and went by really fast.  Don't know if we can sustain this pace for the rest of the book.

April 19th
Scrumming in a Waterfall - nice visual, great chapter.  I'm pulling for Kartar, he's doing all the right behaviors, making mistakes and learning each step of the way.  One day he's going to land this project in the success column of management's spreadsheet.  It appears that's how interested the big boss is in the project (affectionally called "Winner").  It's right when Kartar is about got the dirty little secret of Scrum figured out in this iteration that the Lovers, Sis & Lex show up and we cycle under the pressure of the waterfall, tumbling and gasping for air.  

How do you explain water to a fish?  I'm thinking that Kartar is learning all kinds of things in this iteration.  He's gotten lesson at the firing range, upgrade his tiny pistol to an arsenal that Fiona Glenanne (Burn Notice) would be proud of - maybe she'd invite Kartar to show her his car trunk.

But by the end of this chapter - we are back in the rabbit hole with Alice and late, we're late, for an important date.

Table of Contents:
  1. The High Cost of Schedule Slip
  2. Rowing over a better Waterfall
  3. Death by Documentation
  4. The IT Mechanic
  5. Sprinting with a Bollywood Autobot
  6. Scrumming in a Waterfall
  7. Product Vision
  8. Sustainable Pace
  9. Liberation and Libations
  10. Agile Development is about having FUN!
  11. Why Let Your Framework Limit You?



See Also:
Scrum Noir - several volumes of graphic novel about scrum masters and the projects they encounter - also by Lancer Kind
I will have a Double Expresso - Amazon review of Scrum Noir.

Saturday, March 18, 2017

Velocity Calculus - The mathematical study of the changing software development effort by a team


In the practice of Scrum many people appear to have their favorite method of calculating the team's velocity. For many, this exercise appears very academic. Yet when you get three people and ask them you will invariability get more answers than you have belly-buttons.


Velocity—the rate of change in the position of an object; a vector quantity, with both magnitude and direction.
“Calculus is the mathematical study of change.” — Donald Latorre 

This pamphlet describes the method I use to teach beginning teams this one very important Scrum concept via a photo journal simulation.

Some of the basic reasons many teams are "doing it wrong"... (from my comment on Doc Norton's FB question: Hey social media friends, I am curious to hear about dysfunctions on agile teams related to use of velocity. What have you seen?


  • mgmt not understanding purpose of Velocity empirical measure;
  • teams using some bogus statistical manipulation called an average without the understanding of the constrains that an average is valid within;
  • SM allowing teams to carry over stories and get credit for multiple sprints within one measurement (lack of understanding of empirical);
  • pressure to give "credit" for effort but zero results - culture dynamic viscous feedback loop;
  • lack of understanding of the virtuous cycle that can be built with empirical measurement and understanding of trends;
  • no action to embrace the virtuous benefits of a measure-respond-adapt model (specifically story slicing to appropriate size)
... there's 6 - but saving the best for last:
  • breaking the basic tenants of the scrum estimation model - allow me to expand for those who have already condemned me for violating written (or suggesting unwritten) dogma...
    • a PBL item has a "size" before being Ready (a gate action) for planning;
    • the team adjusts the PBL item size any/ever time they touch the item and learn more about it (like at planning/grooming);
    • each item is sized based on effort/etc. from NOW (or start of sprint - a point in time) to DONE (never on past sunk cost effort);
    • empirical evidence and updated estimates are a good way to plan;
  • therefore carryover stories are resized before being brought into the next sprint - also reprioritized - and crying over spilt milk or lost effort credit is not allowed in baseball (or sprint planning)

Day 1 - Sprint Planning
A simulated sprint plan with four stories is developed. The team forecast they will do 26 points in this sprint.




Day 2
The team really gets to work.




Day 3
Little progress is visible, concern starts to show.


Day 4
Do you feel the sprint progress starting to slide out of control?



Day 5
About one half of the schedule is spent, but only one story is done.



Day 6
The team has started work on all four stories, will this amount of ‘WIP’ come back to hurt them?




Day 7
Although two stories are now done, the time box is quickly expiring.


Day 8
The team is mired in the largest story.



Day 9
The output of the sprint is quite fuzzy. What will be done for the demo, what do we do with the partially completed work?



Day 10
The Sprint Demo day. Three stories done (A, B, & D) get demoed to the PO and accepted.



Close the Sprint
Calculate the Velocity - a simple arithmetic sum.




Story C is resized given its known state and the effort to get it from here to done. 




What is done with the unfinished story? It goes back into the backlog and is ordered and resized.




Backlog grooming (refinement) is done to prepare for the next sprint planning session.





Trophies of accomplishments help motivation and release planning. Yesterday’s weather (pattern) predicts the next sprints velocity.


Sprint 2 Begins with Sprint Planning
Day 1
Three stories are selected by the team.  Including the resized (now 8 points) story C.


Day 2
Work begins on yet another sprint.


Day 3
Work progresses on story tasks.


The cycles of days repeats and the next sprint completes.


Close Sprint 2
Calculate the Velocity - a simple arithmetic sum.



In an alternative world we may do more complex calculus. But will it lead us to better predictability?


In this alternative world one wishes to receive partial credit for work attempted.  Yet the story was resized based upon the known state and getting it to done.




Simplicity is the ultimate sophistication. — Leonardo di Vinci 

Now let’s move from the empirical world of measurement and into the realm of lies.








Simply graphing the empirical results and using the human eye & mind to predict is more accurate than many peoples math.




Velocity is an optimistic measure. An early objective is to have a predictable team.

Velocity may be a good predictor of release duration. Yet it is always an optimistic predictor.




Variance Graphed: Pessimistic projection (red line) & optimistic projection (green line) of release duration.



While in the realm of fabrication of information — let’s better describe the summary average with it’s variance.