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

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 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.

Tuesday, March 14, 2017

Dash off a Fiver to the ACLU

What can you do to save the world with an Amazon Dash Button?

Has a new era of enablement reached the hockey stick curve of exponential growth?  I think it has.  I've been picking up this vibe, and I may not be the first to sense things around me.  I've got some feedback that I very poor at it in the personal sphere.  However, on a larger scale, on an abstract level, in the field of tech phenomena I've got a bit of a streak going.  Mind you I'm not rich on a Zuckerberg level... and my general problem is actualizing the idea as apposed to just having the brilliant idea - or recognizing the opportunity.

A colleague told me I would like this tinker's Dash Button hack.  It uses the little hardware IoT button Amazon built to sell more laundry soap - a bit of imaginative thinking outside of the supply chain problem domain and a few hours of coding.  Repurposing the giant AWS Cloud Mainframe, that the Matrix Architect has designed to enslave you, to give the ACLU a Fiver ($5) every time you feel like one of the talking heads (#45) in Washington DC has infringed upon one of you civil liberties.

Now I think this is the power of a true IoT the fact that an enabling technology could allow the emergent property that was not conceived of in it's design.  No one has really tried to solve the problem of the democrat voice of the people.  We use the power of currency to proxy for so many concepts in our society, and it appears that the SCOTUS has accepted that currency and it's usage is a from of speech (although not free - do you see what I did there?).  What would the Architect of our Matrix learn if he/she/it could collect all the thoughts of people when they had a visceral reaction to an event correlate that reaction to the event, measure the power of the reaction over a vast sample of the population and feed that reaction into the decision making process via a stream of funding for or against a proposed policy.  Now real power of this feedback system will occur when the feedback message may mutate the proposal (the power of Yes/AND).

I can see this as enabling real trend toward democracy - and of course this disrupts the incumbent power structure of the representative government (federal republic).  Imagine a hack-a-thon where all the political organizations and the charities and the religions came together in a convention center.  There are tables and spaces and boxes upon boxes of Amazon Dashes Buttons.  We ask the organizations what they like about getting a Fiver every time the talking head mouths off, and what data they may also need to capture to make the value stream most effective in their unique organization.  And we build and test this into a eco-system on top of the AWS Cloud.
"You know, if one person, just one person does it they may think he's really sick and they won't take him."
What would it take to set this up one weekend...  I've found that I'm not a leader.  I don't get a lot of followers when I have an idea... but I have found that I can make one heck of a good first-follower!

"And three people do it, three, can you imagine, three people walking in singin a bar of Alice's Restaurant and walking out. They may think it's an organization. And can you, can you imagine fifty people a day, I said fifty people a day walking in singin a bar of Alice's Restaurant and walking out. And friends they may thinks it's a movement."
I will just through this out here and allow the reader to link up the possibilities.

Elmo From ‘Sesame Street’ Learns He's Fired Because Of Donald Trump’s Budget Cuts.  Would this be a good test case for a Dash Button mash up to donate to Sesame Workshop.

See Also:

GitHub Repo Donation Button by Nathan Pryor
Instructables Dash Button projects
Coder Turns Amazon Dash Button Into ACLU Donation Tool by Mary Emily O'Hara
How to start a movement - Derek Sivers TED Talk

Sunday, March 12, 2017

Dialogue on Prerequisites for Collaboration

IDEO-University 'From Ideas to Action' Lesson 1.

Join the dialogue on G+ Agile+ group.

Dialogue on Collaboration on Facebook (PDF)

Collaboration starts with who we are and our story - not the technology or the data
"The Future of Work Is Social Collaboration from Inside Out, where people connect around the why of work from who they really are as individuals in community.
They collaborate in generative conversations and co-create what’s next, i.e. their unique Contribution of value to society – what we might call Social Good.
They collaborate by taking the time to appreciate and align each other’s unique, hard wired, natural strengths, creating new levels of authentic and trusting relationships to take the Social Journey."
Jeremy Scrivens Director at The Emotional Economy at Work

What does dialogue mean... what does it contribute to collaboration? Here's what the inventor of the internet Al Gore had to say about this:

Audie Cornish speaks with former Vice President Al Gore about the new edition of his book, The Assault On Reason.

Well, others have noted a free press is the immune system 
of representative democracy. And as I wrote 10 years ago, American democracy is in grave danger from the changes in the environment in which ideas either live and spread or wither and die. I think that the trends that I wrote about 10 years ago have continued and worsened, and the hoped-for remedies that can come from online discourse have been slow to mature. I remain optimistic that ultimately free speech and a free press where individuals have access to the dialogue will have a self-correcting quality. -- Al Gore

Excerpt from NPR interview with Al Gore by Audie Cornish March 14, 2017. Heard on All Things Considered.

See Also:

Mob Programming by Woody Zuill

Thursday, March 2, 2017

Learning Tools beginning Exponential Growth

Learning tools are beginning to benefit from the exponential growth process of knowledge creation and transference.  Here is Seeing Theory an example of this.  Did you do well in Probability and Stats in school?  Funny enough I can predict with astonishing accuracy that a majority of you said "NO!"  I also struggled with those courses, may have repeated it a time or two.  But now with some age I find it much more fascination to study this subject.

Seeing Theory Leaning Site
"By 2030 students will be learning from robot teachers 10 times faster than today" by World Economic Forum.

This is what happens when humans debate ethics in front of a super intelligent learning AI.

See Also:

TED Radio Hour : NPR : Open Source World  Tim Berners-Lee tells the story of how Gopher killed it's user base progress and CERN declared their WWW open source in 1993 April 30th, insuring it would continue to prosper.  And was it's growth exponential?

Wednesday, March 1, 2017

Empower - an action; not a command

You have not empowered a person by telling them "you are empowered."  This is a classic mistake in communication.  When one does this, they misinterpret their message, "I'm empowering you..." with the action that a verb such as empowerment requires to happen.  This person is taking a short cut, by giving the platitude of empowerment in place of any action that would be view by the other as empowering.

"When told that they are empowered to do something; this message is actually interrupted to dis-empower the persons agency."
How does this misinterpretation occur?  Why do we humans mess up this simple act of communication?

Let's look at an example:

For a few months I had been working with a new team of software developers at a large organization.  Like many organizations they had already done the agile/scrum thing and it didn't work for them.  Recently the leadership had built a satellite office and started from a very small pool of tenured people to grow it's new "resource" of technical people.  This time the leadership decided that hiring some experienced people that had "done Agile" and "knew how to Scrum" might give them the needed energy to actually get somewhere with the initiative.  At least these experts could teach the new people how to do agile right.  I guess I was one of these "experts" (another term for a has-been drip under pressure).

Observing the new team for a few weeks I noticed they referred to their process by the label "kanban," yet they never appeared to move any sticky notes on their board, never made new ones or retired any old stickies.  Mostly they just pointed at them and talked about something not written on the note.  It was very difficult for the outsider (me) to follow the process they were using -- or maybe they were not using any process; and I was following them -- to nowhere.  This will take a bit more observation.

Although that was several months ago, and my memory is not the best at recovering details when there is no emotion overlaying the details, believe me there was little emotion at their stand up meetings, I'd call them boring (the meetings, not the people).  I don't remember in the 4 weeks I was observing that they ever shipped any software, never spoke about a customer visit, or discussing a solution with a customer - I don't think anything they talked about ever got done.

So, I some how convinced their manager that what they were calling a process, could not be named - and that wasn't a good thing (sorry Alexander that attribute is not the same as your "quality without a name" ).  It didn't reflect any known process.  He didn't know much about the process either.  It was labeled "kanban." Yet they didn't exhibit any of the behaviors of a team practicing the Kanban process, they didn't even know what steps the process might involve.  They had also tried scrum, but "it didn't work" either.  It was very difficult to discuss these failures with the team or the manager, they were reluctant to discuss what about the process had failed, nor what actions they implemented when these failures occurred.

I made a bold assumption - they didn't know anything about the processes they were espousing they were using.  They had been to training classes, therefore they knew ... something.  They could use the new lexicon in a sentence (90% of the time the sentences made sense).  But how do you tell someone they are ignorant (with the full meaning - that they no nothing about a subject and it's not their fault for having never been exposed properly to the knowledge).  That's a crucial conversation.  I rarely handle these well - I got lucky this time perhaps.  I suggested the team join me in a workshop to talk about the practices they are using and how these map to the Agile Manifesto.  We did this exercise and branched off into many valuable conversations.  During this exercise we decided they were already being Agile, so many of their practices supported the principles of the manifesto.  So the question was not if they were Agile, but how much was enough... could they improve their agility - did they want to try something different?  Along the way of this conversation we might have arrived at an understanding of a difference of opinion, when I used words in the lexicon I had intended to imply certain meanings that they did not intend when they used the words.  We often seemed to use similar phrases but rarely meant the same things actually happened.  That level of miscommunication can be tedious to overcome, while still keeping an open mind that the other person has something valuable to offer.

For example: they had been using the word "kanban" to describe the process they were using because that was the term applied to the Rational Team Concert (RTC) - template work flow the company created.  They had chosen that workflow because it was easier to use than the complicated scrum workflow the organization's PMO created.  Turns out it had nothing to do with the development process they were using.  They finally agreed that they were not doing Scrum, and didn't really know how to do it... they hadn't learned much from the powerpoint presentation (imagine that).

I got extremely lucky with one of the leaders of this team. She said to the team, that she thought the
team should give the scrum master (me) a chance, just go along with whatever I said, regardless of how stupid it sounded. Try it for a few weeks, it wouldn't hurt, and then in a few weeks decide if it was working for the team, or not.  I learned of this leader's suggestion to her teammates only months later.  It was without a doubt the turning point in the relationship.  After this détente, the team members began to implement with ease suggestions on how they could implement Scrum.  One might say that this leader empowered me, but never said a word about it to me.

We did more workshops in a scrumy fashion, we had a board of items to complete.  We tracked these items on a board right there in the workshop space.  Sometimes we split the topics up more.

Sometimes the topic didn't get finished in the time allotted and we had to decide if it was good enough to continue with other topics and come back later to finish the discovered aspects.  We used the rate at which we were progressing day after day to predict that we wouldn't get all of the topics covered by the end of the week.  But that was good enough, because each day the team selected the most important, most valuable topics and we put off the lease valuable.  Sometimes a topic was dependent upon another item on the board and we had to cover some of a less valuable item so that the dependency was resolved.  In these workshops we covered many Agile principles, the Scrum process framework (3 roles, 3 meetings, 3 artifacts, and a lot more), engineering  practices (many originally defined by Extreme Programming gurus), local organization customs, terms, policies, and procedures.  Much of what was suggested by some agile or scrum nutjob was in contradiction with the customs and policies of the organization - at least on the surface.  Great conversations were developed where the team joined into filling the shared pool of knowledge.  This pool of knowledge now with company and agile/scrum knowledge was easily sorted into new understanding of how both systems could co-exist and interrelate.  It wasn't easy but it generally worked.

The team started understanding the process of Scrum and working toward getting stories in the backlog to done.  Slicing stories that had proven too large in the past and delivering working software to the business each sprint.  They developed the ability to easily estimate a story or an epic set of stories within minutes.  Their ability to read their task board and predict which stories (if any) were not going to get completed within their sprint time-box that they quit wasting time tracking a sprint task burndown.  They understood that if they got into a new domain that ability might be diminished and they could easily revert to tracking task aspirin (a unit of effort; not time) on a chart in the future. The team knew their velocity and could accomplish a sprint planning session in about an hour.  They could predict when they needed to spend more time in refining tough stories before planning and they learned how to slice stories for value and leave the fluff on the cutting room floor.

But all was not well with a performing team...  (cue the scary music - set up a scene with dramatic lighting) ... the manager was looking for a way to measure the team.  And as people are wonting to do... without any thought they look for a dashboard to tell them how well the "team is being run."  They want to know if the "team is being driven at their top performance", and they need some numbers to prove it.  Generally this is a warning indication that many conversations were wasted and no learning occurred,  in hindsight the wrong person was doing too much of the talking and the other didn't draw from the pool of shared knowledge but instead just admired the pool from the shore, never bothering to enter.  The team's manager wanted me to build a dashboard tool using the company's tool of record (RTC) that would give him all the numbers that prove his team is performing well.

I've made a strategic decision over the years to not become the tooling expert - especially with the bountiful assortment of tools the software project management industry offers.  Needless to say I didn't want to become an expert in RTC (a tool rumored to be on it's way out for this organization that was in their 3rd Agile adoptions curve).  I asked what this dashboard would have on it, what it would display, etc.?  The answer fit on a sticky note, because that's what I had with me... something like velocity, the backlog, and what the team is currently working on was the manager's response.

Here's my Nth mistake.... I hoped the request would dissipate as many thing in a transition tend to do, so I wasn't motivated to create a dashboard for the manager that would reproduce the team's well maintained Scrum task board.  I offered to work with him in reading the board, he attended many of the team's Scrum sessions at the board, rarely engaged but appeared attentive.

[this story will continue ...  as I've lost my round-toit --  wonder if it's with my marbles?]

See Also:

The Rise of Emergent Organizations  by Beth Comstock

The ScrumMaster - How to develop a team - by Marcel van Hove