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.



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)

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

Friday, February 24, 2017

Don't hate the Joke - learn to tell it Well

Countless times I've heard people say they hate the Scrum joke about the pig and chicken.  Some people just can't tell a joke.

Jeff Sutherland points the fickle finger of fate at Ken Schwaber for starting this fable:


I've hated having to tell teams this joke... the lore of the Scrum pig and chicken is so pervasive that before long someone is going to call someone else a chicken (or a pig)... and then you have to tell the joke to help that person retain face... it can be quite uncomfortable for me.

I think my disdain for this joke has to do with two of American's least favorite farm animals being featured.  We call people chickens to say they have little courage.  We call people a pig to insult their appearance (clothing choices, weight, manners).  Had the joke featured a cat and dog... it would be so different - wouldn't it?


Now Jake it appears has taken this joke metaphor to a new level...  good job Jake!

See Also:
Some fun videos about Agile & ScrumScrum cartoons and fictional stories - a list
Scrum Pig and Chicken - part 1 by Jake Calabrese
Organizational Commitment: Pig and Chicken – Part 2 by Jake Calabrese
Does Your Culture Require Your Demise - Pig & Chicken part 3 by Jake Calabrese


Big Data for Little Problems

Big Data for Little Problems

-OR- What happens when the customer has better data about the service than the provider and has better networking, better press coverage, better clout, better market reach and reputations?


(Feb 23) My good looking wife just spent 2 hours trying to straighten out Frontier's billing machine... it's not easy.  The amazing thing I observed for my recliner while sipping an adult beverage was her influencing techniques.  Now another amazingly disconsernation (not a word) is that Frontier has some awesome support people.  But oh-my-god do they have a tough job.  It's the system that has failed.  And they have to figure out how to make some legacy piece-of-crap work.
But it's not going to lead to happy satisfied customers (testify).

Her father, Jim, moved into the home with us in December, he loves Western movies, and is an encyclopedia of knowledge better than IMDB.  So we called up Frontier (our FiOS provider for 6 years) and added cable and a voice line for Jim.  We cut the cable some years ago.

That's when the troubles began, December 28th.  A techie came out to the house and worked 6 hours, all the while on a phone line to his partner back at the home office (I now understand why it required this constant contact to install the new system).  When he left we had higher speed internet (from their 50Mbpm to 150Mbpm service), cable channels - Stars Encore Western premium channel, and a voice line (old school) phone tied to a wall socket.  Most every thing seemed good.

But the ability to login to their Frontier web site and get a TV guide didn't function, as well as some other issues of seeing our account info online.  We were told to wait a few days as the data took a while to move through their systems (in Frontier's universe data does NOT move at the speed of light).

I noticed that if one tries to take their Frontier problem to Twitter, @AskFrontier is an effective defensive machine that kicks in to appease the person.  They cannot do anything except type into a twitter post, and escalate your issue to a thing referred to as "an Account Manager".  I tried that technique and received a call one week later - yes over 6 days to address an issue raised on a social media platform know for instant messaging.


Once burned - twice shy... I didn't fall for this in February.

We found out last night that while we have been paying $193 for a basic plan and the Stars Western channel - that Frontier would be happy to offer us ALL their premium channels for $198.  Something that the competition Spectrum is quoting online visible with detail for about $150ish (yes I'm writing this from memory of my influencing wife's exasperation attempting to get the support person to recognize her point of view at being fleeced by Frontier).  Frontier's business model includes an interestingly complex system of quoting the cost for a service.  They encourage one to call in to talk to their pleasant but hamstrung  sells reps.  Who can only read from a screen that may change any day now on the pricing that appears to be very time dependent (you never know if tomorrow they will have a sell and better price for what you will be receiving everyday for years to come).  Now the prices and "packages" you agree to buy will not be the names and labels on your bill.  Those will be completely different and if you can find a subset of items on your bill that sum up to the $198 you thought you had agreed to - well you should work for the IRS.

After that 2+ hour conversation with a great Frontier support specialist, my very intelligent wife influence her way to some deep refunds, and what we hope will be all the movie channels that Jim could watch in a week.  Yet after 2 solid months of working with Frontier's business model - we are done.  We plan to see what the next bill shows (it's a mystery)... and when the dust settles switch to Spectrum.

The phone logs for ONE month - let the Record show:

Frontier Customer Support Line is 800-921-8101

779 minutes of my life... give or take a migraine

Jan 25, 2017
     6:45pm Outgoing Call 2 hours 25 minutes
     1:53pm Incoming Call 1 minute
     1:28pm Outgoing Call  18 minutes
     1:16pm Outgoing Call.   9 minutes
Jan 24, 2017
     10:39am Missed Call
       7:11am Outgoing Call  54 minutes
Jan 23, 2017
     4:59 pm Outgoing Call 2 hours 10 minutes

Jan 22, 2017
     11:00am. Outgoing Call. 2 hours 22 minutes
     10:34am  Outgoing Call  22 minutes

Jan 22, 2017
     10:08am Missed Call
     10:06am Missed Call
     10:00am Missed Call
      9:59am Missed Call

Jan 21, 2017 Saturday
    8:19pm Outgoing Call. 37 minutes

Jan 16, 2017
    7:00 pm Outgoing Call. 1 hour 17 minutes
    6:38pm Outgoing Call. 58 seconds
    3:59pm Outgoing Call. 40 minutes

Dec 28, 2016
     7:41am Outgoing Call  31 minutes

Dec 27, 2016
     4:09pm  Incoming Call. 43 seconds

Dec 24, 2016
     11:18am. Outgoing Call. 14 minutes

Oh - why oh why - did Steve Jobs died before he fixed the living room TV problem?  There is no GOD.  Can an 85 year old man learn to use this complex thing call a cable box remote from his recliner and almost infinite time?
 
My experiences say NO, Freaking WAY!  Hell, I can't figure this complexifictor out and I've got 30 years in the computer industry making these complexifictors for companies that say the want customer satisfaction.