Friday, December 20, 2013

Magic Feedback Technique

A technique for increasing performance by using a simple (perhaps magical) recipe when giving feedback.

Read the study, understand the method of investigation; ask yourself if this is similar to your work environment - just enough such that the technique might be generalized across the two different situations.
Breaking the Cycle of Mistrust: Wise Interventions to Provide Critical Feedback Across the Racial Divide  by David S. Yeager, et. al.

If you just want to cheat, read the "cliff-notes" version (it's what I did) - but I promise myself to go back after writing this post and read the study.

Try This One Phrase to Make Feedback 40% More Effective  by Jeff Haden - INC.

Jeff is quoting Daniel Coyle, author of The Talent Code which references the study.  Now I'm referring to Jeff -> Daniel -> Yeager et al.  And you are at the front of the line of referral - maybe you should jump the line - read the original work.

But you just want the MAGIC:

I'm giving you these comments because I have very high expectations and I know that you can reach them.

Breaking it down:  create an IN Group mentality, set high expectation to belong within this group, extend trust that they have what it takes to belong and meet the high standards.

Try that in the upcoming round of performance reviews.

See Also:
Employee feedback: How to make it less painful - How Lee Burbage, the Motley Fool HR leader changed their employee feedback program.

HBR:  Why Your Brain Hates Performance Reviews by Gretchen Gavett

Performance Appraisals what have we learned in 50 years?


20 Years Ago, Steve Jobs Demonstrated the Perfect Way to Respond to an Insult, Inc. by Justin Bariso
In 1997, Steve Jobs was answering developers' questions when one audience member took a shot at him. What happens next is remarkable.



Thursday, December 19, 2013

Transparency of Price in Health Care

Does it exist?

Health care in the USA is under great pressure to change these days.  So regardless of which pole of the political sphere you personally are drawn toward, the landscape underneath your view point will be changing.  One could ask why.  It is an interesting line of inquiry.  Will the fact that health care is just too costly, increasing at exponential rates, and leaving an ever enlarging number of americans out of the "care" system suffice for the moment?

So this domain of the american system is being pushed off a proverbial cliff into a turbulent troubled sea of change.  I wonder - do we have any system models that would describe what might help in these situations?

Here's a case in point, a CEO announce a spur of the moment policy change, a move toward transparency.  Why?  Perhaps he was frustrated with the ill-rational behavior of "the system".  And decide that a move toward transparency was a rational behavior.

Florida Hospital Takes a Step Toward Price Transparency
Miami's Mount Sinai Medical Center has pledged to publicly disclose its price contracts with insurers
By Kate Pickert June 03, 2013 TIME.com

Speaking in May on a local public radio affiliate, WLRN, Steve Sonenreich, CEO of the Mount Sinai Medical Center in Miami Beach, FLA, said, “We’d be willing to put our prices to all the insurance companies out in public and we would welcome that kind of transparency of everyone in the marketplace.”

More articles on the money issue:  Follow the money with Time's Steven Brill.
Steven Brill - The Daily Show
Watching Jon Stewart's interview you may realize that the health care industry is not like any industry you are familiar with -- let's say one that you work in, where reasonable people do things with reasonable cause and effect correlation.  So how do we model this rather chaotic (Alice in Wonderland) world such that we can make reasonable decision about how to tame the beast?  If you are from another domain (say regular world) you may be tempted to apply regular world logic to a small subset of the problems and be surprised by the systems behavior.  A case in point, almost every other industry has some level of price transparency.  Customers have choices before they purchase a good or service and may choose to shop around based upon price.  So what happens when some nut job suggest that health care do the same?  Well you can bet the chaotic system does not react like your normal world system.

If only there was a general model of this meta system of systems - some which behave sanely, and some which are just too difficult to understand.  A model that could give us some guidance as to how to behave when we knew which land we happen to be in at any one moment.

Do you know of such a model?  Let me see, here's a few:

Reagan's Trickel-down economics (Supply-side)
Keynesian economics
Various economic models compared to scientific models
Wonderland model

I don't think these models will work for our problem.  Why?  Because they do not model insane systems very well.  They all seem to assume the rational mind exist within the system.  And I think we can agree -- there is no rational control within the health care system.

Perhaps if we go a bit more abstract... maybe a weather system model will work.  Those model really weird system that produce erratic behaviors like hurricanes and tornados and even sharknados.

Or maybe we are barking up the wrong tree... perhaps we should simplify our models...  try to make sense of the meta information, apply some common sense to the problems instead of getting inside the tornados of data and assuming that every thing moves in a counter-clockwise direction (talk about getting wrapped around the axel).

Try this simple model... based on the classic two dimensional four quadrant model... but with a dimensional twist out of the page... kinda like MC Escher would do...  So it is a bit like a model that fits wonderland.  Cynefin framework by David Snowden.




Back to the health care price transparency issue now.  Which Cynefin domain is health care pricing?  Hum... oh I fear answering because I could get it wrong...  well there's only 4 domain, I've got a 25% chance just by guessing.  WRONG!  There are 5 domains and the fact that I don't know which domain I'm in tells us the answer, we are in the disordered domain (the 5th one - the one we are most likely to be in most of the time).  Damn, I think Mr. Snowden may be on to something here.

So if health care pricing is in a discorded domain, what's the model tell us we should do?  I think (and I may be wrong - and wouldn't that be FUN) it doesn't matter - we act, then sense.  So was Steve Sonenreich, CEO of the Mount Sinai wrong to just act?  To suggest that price transparency may be a good thing for the system.  Then to sense what the system does with this new input.  Certainly the people in his organization had a bit of panic in their throats and had to change lots of things to make his decision a reality.  We might not see the cause and effect for some years to come.  So be very careful when we sense.  We might not sense the ripple effect.

How does Snowden suggest we sense?

I'll leave that you to you to answer.

Wednesday, December 18, 2013

Lean-Kanban Brickell Key Award

Best quote:
"Significant Impostor Syndrome"
2013 Brickell Key Award nominations video.



Published on Oct 24, 2013
Nominee recognition video for the Brickell Key awards, presented at LeanKanban North America 2013 in Chicago IL, USA. Video by Derek Wade.  Music: Thomas Newman - "American Beauty"

Spollier Alert!!!

The winners were Yuval Yeret and Troy Magennis.

See Also:
http://leankanban.com/brickell-key/  the award page.

Wednesday, December 11, 2013

The Hidden Benefits of Keeping Teams Intact

December's issue of Harvard Business Review creates a compelling case for the concept of persistent teams. And hey, if they do it in the operating room, then there must be good science behind it. But heck, we don't need no stinking science, we just know it works, right?

http://hbr.org/2013/12/the-hidden-benefits-of-keeping-teams-intact/ar/1

Harvard Business Review - Dec 2013


ICEpocalypse Impediment

Our company just discovered an interesting impediment this past week.  The Dallas ICEpocalypse of 2013 resulted in many companies shutting their offices, ours did this also, both Friday and Monday (Dec. 6th & 9th) - someone even opened an outdoor ice skating rink in Dallas.  Yet many team members worked from home, and to do this many had to use the Virtual Private Network (VPN) to access secure systems.  Guess what impediment a few thousand employees all working from home the same day causes?  The VPN is a licensed infrastructure with a license limit.  Yep! only a fraction of the people working from home could access the limited licenses of the software VPN.

So I wonder if there is a system, known to mankind, that is designed to deal with this sort of constraint and surge in usage....  isn't that new fangled cloud computing environment designed to handle this very sort of on demand scalability?

So I understand the need of the company IT department to purchase a limited number of licenses.  I understand the VPN vendor to limit the users of the system.  I understand the workers wanting to stay within the safety of their warm homes and use those new high tech remote computing platforms and networking that we are so famous for creating.

I understand that we as a company have spent millions of dollars on fail safe redundant data centers to server our customers.  We have fault tolerant fail over systems, disaster recovery systems.  But we don't have them fool proof.  And one weather system proves it.  While I'm sure the customer systems continued to hum during the ICEpocalypse of 2013.  The support and development groups got taken out by a VPN license agreement.

I'm not an expert on contractual license agreements - but when I was tasked with writing a license monitoring framework for our network infrastructure product many years ago - I chose to buy one from a company that's core competency was licensing.  We integrated it (FlexLM) with our software.  It had the capability to change license restrictions with the editing of a file and restarting a license manager service.  We could have easily given a client a thousand licenses for a week if asked, we could have charged them for this service or done it for free.  All because the license manager company had already solved these problems before.

So I wonder why that capability doesn't manifest itself today in core infrastructure, as part of disaster mitigation plans.


References:

FlexNet http://en.wikipedia.org/wiki/FlexNet_Publisher
OpenLM  http://www.openlm.com

Saturday, December 7, 2013

Intro to Refactoring with LEGOs

Practicing Into to Refactoring with LEGOs.

Refactoring is when a developer changes the structure of the code without changing the behavior.  To do this with little or no risk a craftsman will have a set of well maintained tests that prove the code still behaves exactly as before.

A simple way to visualize refactoring is to think of 12 eggs.  Most people will imagine a carton of eggs.  But it is possible to think of 2 cartons of 6 eggs; or even 6 packages of two hardboiled eggs.  Refactoring get's its name from the factorization of numbers.  Twelve has multiple factors (6 x 2), (3 x 4), (2 x 6), (1 x 12).  No matter which factorization the resulting collection is twelve eggs.  In TDD we have test to make sure we don't break the eggs.

Note:  Many IDE's claim to do refactoring, and many times they work just as expected; however not all IDE refactorings are reliable.  I suggest you test your IDE's refactoring before you trust it.

To introduce beginner developers to the basics of refactoring - start with a well understood class with many blocks of code.  First refactoring to practice is Extract Method.


But first make a program of blocks in this order:  white, red, blue, blue (again), red, yellow, green, red, yellow at the bottom.


Extract Method:  using the extract method refactoring - pull out the red block of code; replacing it with a call (the 4x2 red plate) to the extracted block.



Repeat the Extract Method operation on each red section of the program.



Now, a step of refactoring (or TDD) is to remove duplication.  All three of those red blocks of code are theoretically the very same, so we really only need one.  Set two aside and place the one remaining at the bottom of the program stack.


Good job!

Now let's use Extract Method operation on the two blue blocks of code.




And remove the duplication.  Remembering the one blue block remaining is place on the bottom of the program stack.


Practice, practice, practice.... the art of a craftsman.

Let's practice again with the yellow block;  perform the Extract Method operation on yellow blocks of code.




Well done.

Now the program looks a bit wonky... unbalanced by the large green block - let's extract it also.



There, good practice... and continue with the white block....



There all the in-lined class code has been extracted to methods and method calls.  That is well factored.  But let's do a bit of house keeping.  Clean up and reorder the methods and calls into a similar order.


When separated the blocks of code and the calling plates look like this:


Before and after refactoring images.














Required LEGOs

(1) Green 4x2 Plate;  (1) Green 4x2 Block
(1) White 4x2 Plate;  (1) White 4x2 Block
(2) Yellow 4x2 Plate;  (2) Yellow 4x2 Block
(2) Blue 4x2 Plate;  (2) Blue 4x2 Block
(3) Red 4x2 Plate;  (3) Red 4x2 Block



Reference:

Adapted from Bryan Beecham's (@BillyGarnet TDD with LEGOs presentations and PDF.


Friday, December 6, 2013

Best Scrum Stand-up Activity

The Spartan team at VHA has been doing t'ai-chi before their daily stand-up now for several months. Just a few minutes every day.  Lead by someone different every day.

Spartan's daily stand-up starts with t'ai-chi

I was floored the first time I attended.  It's introduction may have been the tipping point between team formation and performing.

See Also:

It's Not Just Standing Up Patterns for Daily Standup Meetings - Jason Yip
Neil Killick's advice on Stand-ups: Stand Up and Shut Up
the 24 forms of Tai Chi (youTube video)


Tuesday, December 3, 2013

It's not Technical Debt - it's Unclean Code

I hear lots of colleagues using the term 'technical debt' and the scenario that plays in my brain's cineplex is from The Princess Bride when Inigo Montoya remarks to Vizzini; "You keep using that word.  I don't think it means what you think it means."

Inconceivable!




So what does "Technical Debt" mean?  And what do my colleague's typically mean if it is not truly technical debt.

The first is easy; the definition of Technical Debt:

He who coins the term gets to define the term (that's Ward Cunningham).



Ward Cunningham on Technical Debt Metaphor 

OK, so to be truly technical debt one must negotiate the debt with the business.  The business should achieve some objective sooner and incur an obligation to repay the technical team the time and effort required to put the system back into a proper state of clean well factored code.

But, wait... what could my colleagues mean when they misuse the term technical debt?  I think they mean many things, but since there is no good word for what they mean they appropriate the popular term.  I've referred to the concept as:

  • bugs just waiting to be discovered
  • short cuts that will come to haunt us later
  • things we will fix one day
  • engineering done by the new guy
  • design choices that time permitted 

There appears to be a problem here; there is no good word or phrase for this concept.  So let's create one!  How about unclean code.  Inverting the concept from Robert Martin's Clean Code: A Handbook of Agile Software Craftsmanship.

Let's define the term 'unclean code'.  Software code that might work, has known deficiencies, needs to be thoroughly tested, and probably would make a master craftsman's nose turn up at the smell.

Let's see if the term can replace the misappropriated 'technical debt' in a sentence.  "We have some technical debt unclean code this sprint that will need to be added to the backlog, but the features are all done."


See Also:

A Product Manager's Take on Technical Debt by Kevin Binnie
A Technical Debit - Collateralized Debt Obligation you should not invest in - David Koontz
No Test - Inconceivable - Agile Complexification Inverter
Managing Software Debt - book by Chris Sterling
Doc Norton Sez You're Using "Technical Debt" Wrong - Agile Amped at Agile2016
Ward Cunningham's Debt Metaphor Isn't a Metaphor by Rob Myers
WSJ: What Buzzwords Would You Ban in 2014?
Crisp's Blog: The Solution to Technical Debt by H. Kniberg - he calls it "Crappy Code"
Misunderstanding Technical Debt by Niklas Bj√∂rnerstedt

The SQALE method is particularly devoted to the management of the Technical Debt (or Design Debt) of software developments. It allows:

  • To define clearly what creates the technical debt
  • To estimate correctly this debt
  • To analyse this debt upon technical and business perspective
  • To offer different prioritisation strategies allowing establishing optimised payback plan.
Martin Flower's Technical Debt quadrant model

The Technical Debt Trap - Doc Norton at NDC Conference 2016

Monday, December 2, 2013

Project Success Sliders

What do you do when the Product Solutions Director comes to you and suggest that she would like a product delivered within a 5% error on the delivery date?

One suggestion is to run through a thought experiment with her.  For example:  Let's assume this is a project that will take about 6 months.  Let's base the schedule on a 180 day time line.  So you desire us to hit that 180 day target from six months away to within 5%.  OK that's 0.05 * 180 = 9 days.  Now is that a plus or minus 5% or a 5% range?  Or in absolute terms for this example do I have to be within 171 - 189 days (+/-5%) or within 176 - 185 days (5%).  So to continue this example, consider a team doing 2 week sprints.  This would equate to 12 - 13 sprints with one sprint error.

by Mountain Goat Software
But perhaps more important is what this one prime aspect of project success says about the other aspects of the project.  So lets try to balance the project success aspects with the schedule being the one most important aspect.  Given that the aspects must balance (rules of the game), then one can choose only one other high important aspect and most leaders chose quality.  This will give a picture something like this.  Meaning that the four aspects of the typical iron triangle (schedule, cost, scope & the unchanging quality) with an emphasis on schedule will lead to cost and scope changes (increased cost and decreased scope).  And what happens when the leadership doesn't increase the cost and decrease the scope?  Well, that quality on the inside of the iron triangle that no one wishes to degrade is .... well, degraded -- while everyone says that it is not.  And that folks, is how one creates design-dead legacy applications in six months.


References:

Mike Cohn created the web based interactive project success sliders shown above; described in the book Radical Project Management by Rob Thomsett.

Saturday, November 23, 2013

13+2 Sprint Cadence

Sprint length - a fun debate. What is the best practice - a funny question. There is no best practice for sprint length.  But what factors should go into the decision?


  • The team's ability to become predictable within the sprint duration.
  • The Product Owner's ability to plan and to commit to the unknown of not changing the plan for the sprint's duration.
  • The frequency of needed feedback on the direction the team is making toward the release goal.
  • The ability of the team to create their sustainable pace.


Many team's I've worked with have trouble defining their sustainable pace.  I've argued that this pace that allows the team to deliver both working software that is potentially shippable each sprint and to have high quality deliverables along with team learning is quite a bit below the teams typical sprint velocity.

When teams are under extreme pressure to deliver they typically forget one of the 7 habits of effective people - to sharpen the saw.  So why not build this habit into the structure of your team's cadence?  Instead of a two week sprint (10 work days) try the 13+2 model.  Thirteen work days followed by 2 days of slack (read the book: Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency).

This slack will give the team time to reflect upon the many things they wish they had time to do, but didn't; and now perhaps they will do them.  Silly little task like cleaning up the automated build scripts, pruning out the dead wood out of the smoke tests, refactoring the last story to a design pattern that now appear obvious after the fact.

This three week sprint length will add in 13% slack to your sprint in a tempo that is easily predictable for the team members.  You might find that the team members start using this 2 day slack time for things like doctor visits and Fed-Ex days.

See Also:
Slack and the Manager's Role in Scrum by Andrew Fuqua
21 Tips on Choosing a Sprint Length by Mishkin Berteig

Hat tip to my friend Caleb Jenkins for the idea - I told him he better patent the idea, or I would steal it.


The Holiday Stratagem

What do the Thanksgiving and Christmas holidays do to your teams tempo and cadence?

For most US teams this holiday period from mid November to after the first of January is hectic and disruptive in various ways.  This calls for a Holiday Stratagem.  A trick to allow the team to have some semblance of continuity and flow during these times.
The Sontaran Stratagem - Doctor Who

To discuss this stratagem let's first define some terms:

Tempo - the rate of workdays to calendar days
Cadence - the beat of the sprint events to fall upon the same calendar day of the week
Sprint duration -  in work days (in this example I'll use 10 work days)
Sprint length - the length of calendar days between two sprints (14 days for the example 2 week sprint)

What do you value more?  The ability to deliver more work in the short term -or- the ability to predict long term the capability of the team to deliver that work?  Or perhaps something else, like teaching a new team the trade-offs in making decisions and helping them to learn from reflecting upon these decisions.

This is one area that I find lots of variability in agile coaches answers when the team just wants an answer to the question - what do we do?  I love this variability.  I enjoy the ensuing debate over the better answer and delving into the reasons why for a specific case.  And this is definitely one domain that is not simple - nor is there a best practice.  So reader beware - there will be no one best practice, no correct way - here is the land of trade-offs.  And it is an interesting land well balanced between the trade-offs such that the replications of the decision are virtually uninteresting.  I think that makes a great play space for the team to practice decision making.

Let's use an example and then discuss the options.  Team Alpha-Dog is on a 2 week sprint schedule with the beginning on Monday (Sprint Planning) and the end of sprint activities (Demo & Retro) on the Friday of the following week.  Along comes the 2013 holiday season with the company's holiday plan for Thanksgiving days off on Nov. 28th & 29th.  In the sprint planning on Monday, Nov 25th the team has a decision.  Do they keep the sprint duration constant (at 10 working days) and there by break cadence - or - do they break tempo and keep the sprint length consistent at 14 days?


Option A - Illustrated
Option A:  Sprint duration constant at 10 working days.  Sprint begins Nov 25th and runs to Demo on Tuesday, Dec 10th.  The cadence of the team and stakeholders will change.

Option B:  Sprint cadence constant at 14 calendar days.  Sprint begins Nov 25th and runs to Demo on Friday, Dec 6th.  The duration changes to 8 working days - impacting planning and subsequent velocity calculations.

Option C: Sprint duration and cadence are broken.  Sprint begins Nov 25th and runs to Demo on Friday, Dec 13th.  A sprint duration of 13 work days to try to reestablish the Monday/Friday cadence - just on an alternate rhythm.

I'm sure someone will offer another option, I'm just going to stop with these three and quickly rule out option C as the worst of all.  It's always nice to have an option everyone can agree upon - even if it is the worst - at least we all agree.

One may want to do a bit of mid-term planning before making the decision.  What will happen with the Christmas and New Year's holiday if we continue with the decision principles we use now; does this leave us in a cadence we wish for the coming year?



If the team desires to switch it's cadence or duration - there is no better time than now.  Have you met the 13+2 Sprint Cadence?



If the team chooses option A then planning is easy, the average velocity calculation is consistent (no need for an asterisks in the log book); however the team ends up changing the sprint cadence and this may wreck havoc on stakeholder's schedules.  The impact to this decision typically ripples outside the team more than inside the team.  It's a good test of the servant leadership paradigm at your company.  Do the leaders server the team or does the team serve the leaders?

If the team chooses option B then planning is a touch harder involving fractional math (I've found this surprisingly difficult for some,  capacity this unique sprint is 8/10 times the typical sprints velocity).  This sprint's velocity may be thrown out of the set for future statistical calculations.  Stakeholder's may be happy because they don't have to rearrange their busy calendars.  But the externality impact to the team may be hidden, it is the compression of the sprint that will throw them off, they will be off tempo.

Projecting these decision into the mid-range future and through to the middle of January may help you make a decision on principles.  But don't expect these principles to hold true when it comes to the following year's calendars.  These are not true principles but just situational guide lines.  It is a good time to practice team consensus making tools like the fist of five.

Have a happy holiday!




Friday, November 22, 2013

Starting a Tech Lending Library

Just bought the Craig Larman agile library collection on Amazon for our lending library at work.


I first feel in love with Agile by reading Larman's Agile & Iterative Development: A Manager's Guide.  The organizational context that sets the stage for comparing and contrasting various agile (and non-agile) methods of software development is a powerful framework.  I find few managers choosing a method understand these concepts enough to make an informed choice.  Only a few hours with this book would raise their awareness to a much improved state.

Here how I started a mini-movement... one email...

I find an empty book shelf to be an aberration.  So I’m filling it up with techie books and some not so techie books.  Feel free to BORROW a book for a few weeks then bring it back for someone else to borrow.  Bring in those dusty books you found interesting and join me in creating a Tech Dev Lending Library.   Connector Breakout Lounge 5001.
There is no check out system, no late fees, no sexy librarian to scold you for not returning a book, just your guilty conscience.
So have a coffee, pick up a book, learn something new, share your knowledge with your colleagues.
David


The beginning of a Techie Lending Library
[ see also:  http://littlefreelibrary.org ]


Little Free Library Story from Beargrass Media on Vimeo.

Tuesday, November 19, 2013

Elements of an Effective Scrum Task Board

Leadership desires - Info Radiators 
What are the individual elements that make a Scrum task board effective for the team and the leadership of the team?  There are a few basic elements that are quite obvious when you have seen a few good Scrum boards... but there are some other elements that appear to elude even the most servant of leaders of Scrum teams.

Team desires - Info Radiators








In general I'm referring to a physical Scrum board.  Although software applications will replicated may of the elements of a good Scrum board there will be affordances that are not easily replicated.  And software applications offer features not easily implemented in the physical domain also.





Scrum Info Radiator Checklist (PDF)

Basic Elements


Board Framework - columns and rows laid out in bold colors (blue tape works well)
    Attributes:  space for the total number of stickies that will need to belong in each cell of the matrix;  lines that are not easy eroded, but are also easy to replace;  see Orientation.

Columns (or Rows) - labeled
    Stories
    To Do
    Work In Process - (many teams limit WIP - label this or make the column very small)
    Done

Rows (or Columns)
    a column title label row (at the top)
    one row for each story in the sprint backlog
    one row for each unique action item from the retrospective
    (optional) rows for company initiatives that team members will be working upon

Stories - the classic user story is typically written on an index card or large sticky note.
     Attributes:  title, description, acceptance criteria, effort size, delivery order (backlog priority), business value, dependencies, negotiated in/out of scope agreements, etc.  See Also:  One sentence does not make a User Story.

Tasks - a sticky note or index card for each task the team identifies or discovers in the sprint.
     Attributes:  each task should be specific (not something like "test it"), each task should be less that a day's worth of effort (when this is not true - the first action of the task should be to break the task up into a plan of action); each task should be estimated in relative units (different & more fine grained than story points) - for example "aspirin"- this is proportional to the amount of wall clock time between it's current state and done (not equal, but proportional to real time).  See Also: What belongs on the TASK board?

Sprint Burndown Chart - task units remaining plotted per day; with sketches of the trend lines; annotated with events that impacted the sprint (ex: reduced scope on day 4;  pulled in small story on day 8; holiday on Monday, flu hit the team, etc.).  See Also: A burndown chart that radiates information.

Impediments List - the one guarantee that Scrum will deliver - and if you are not capturing these on a daily biases and the triaging these, recording the resolutions, reflecting periodically on the classification of root causes -- well then you are not doing Scrum.  See Also: 7 aspects of a great Impediment Sticky.

Advanced Elements


Trend of Sprint success - Predictability graph - graph each sprints planned story points and the accepted (by PO) story points;  the simplest form of this is a binary trend of success (sprint delivered on time, in budget, with planned scope) or not.  See Also:  Metrics for a Scrum Team.

Working Agreements - team working agreements are always a great way to quickly negotiate the forming, storming, norming phases of team development;  these are living documents and should be posted in the team room, so that they can be mutated as understanding grows.

Definition of Ready & Done - a team with a shared understanding of their meaning of done will be much more likely to deliver potentially shippable working and tested software each sprint; a understanding of stories ready for sprint planning will lead to a robust definition of done; one is a precursor catalyst agent for the other.  See Also:  Exercise: Definition of Done.

Calendar - a very old planning tool; heck even the Maya used one.  A great place to note holidays, and events that will impact the team (like the beginning of the next sprint, the time of the next demo, the projected release ship date, etc.)

Backlog - a wish list becomes a Scrum backlog when it attains three things:  effort size estimates by the team that will do the work, a stack ranked deliver order made by the PO, visibility to the whole team (and by visibility I mean via an information radiator - not a spreadsheet on someones hard drive information cooler).

Trophy Model
Navteq data processing visualized
 components added to the model each sprint.
Release Plan - a backlog become a release plan when the team projects which stories will be slotted into which forecasted sprints within the release.  Think of this as a tool - not a report.  You will know it is a tool if it is updated frequently and if planning happens using this visualization - if not, sadly you have a report (reports are notorious for having stale information).

Day of Sprint - count down clock, I prefer to focus on the done so I like the days to count down to D-day (Demo).

Project Goals / Objectives / Elevator pitch - this is typically the release level objectives or release acceptance criteria - how will we judge each story as moving us closer or further from these objectives for this release - how do we know when the release has accumulated enough value to ship it?  See Product Positioning Statement in Beyond Software Architecture by L Hohmann.

Trophy Wall - big game hunters like trophies.  They can take many forms, like the data flow model done at Navteq.  It does wonders for the team moral.

Annotations


Avatars - photos of each team member (including the PO & SM); these should be small but instantly recognized as that person - even by an outsider or stakeholder (don't use Bill-the-Cat)

Impeded - bright colorful attention getting contrasting sticky - noting the reason the story/task is impeded. See '7 Aspects of a GREAT Impediment Sticky'.

Theme Dots - colored sticky dots to indicate themes (well know to the team - with a reference key and labels)

Dependency - sticky annotation to label the item as dependent upon another task/story.


Orientation - Horizontal or Vertical 


I find that everyone starts a task board with a horizontal flow, task moving from left to right.  This is easiest to conceptualize when beginning to adopt the practice.  However it will soon create an impediment.  I've found it amazing that few teams are capable of realizing this impediment and solving it.  The problem with the horizontal board flow is that the available space for stories is then limited by the human hight ergonomics.  We don't like to stand on step stools or bend over - therefore we have about 50 inches of useful space located about 2 feet above the floor.  This impediment will lead many teams to start creating smaller row heights for each story.
A Scrum task board in need of 90 deg. rotation.
Step back and visualize the problem.  We humans have a small range of vertical space that is within our ergonomic comfort zone - yet a large range in the horizontal direction (use your feet).  The answer is to rotate the task board by 90 degrees.  Make the flow of tasks from top to bottom; stories in columns.

Physical vs Software Application


Let's discuss the pros & cons of this aspect of the tools.  Ah... don't get me started.  There is no comparison, physical, tactical, haptic boards have far superior affordances than the expensive software doppelg√§nger.  When I'm teaching a team new to Scrum there is no replacement for a physical board.  The information that flows when one knows how to watch and read the negative space of interaction during the stand-up meeting is phenomenal compared to the stand-up using a projector and application.  And this level of observation is what the beginning scrum master needs to learn to pick up upon, it is orders of magnitude harder for me to teach using a virtual Scrum board.

However for a team that has mastered the basics of the process, and understands the reasons for most all of the behaviors they are practicing, moving to a virtual Scrum board will add a few affordances that are not available in the physical realm.  These affordances are portability, time dislocation, multi-site collaboration, etc.  All very advanced stages of team dynamics - WARNING - do not start with these attributes at the top of your team dynamics desires.

Google Ventures' Jake Knapp wrote about their war room - here are just a few of his reasons that resonate with this post:
Spatial Memory > Short-term Memory 
To solve a complex design problem, you need to track lots of moving parts. As humans, our short-term memory is not all that good--but our spatial memory is awesome. Plaster a room with notes and you take advantage of that spatial memory. You begin to know where information is, which extends your ability to remember things.
Physical Ideas are Easier to Manipulate 
We all know it’s better to re-order a prioritized list of sticky notes or re-draw a diagram than to make the same decisions verbally. That’s why there are whiteboards in meeting rooms and why people love agile trackers with sticky notes. War rooms take those tools to the next level.
See a video tour of Google Ventures' War Room:  Your Design Team Needs A War Room. Here's How To Set One UP  Want to foster creativity? Skip the foosball table and opt for a war room instead.

Want an example of affordances on a dashboard or infographic?

Affordances and Signifiers: applying design theory to your dashboards



References:
Missing Affordances by David Koontz
Master's thesis paper: "Analysis of a paper- and software-based Scrum task board" by Jan Segers
Agile For All blog - Building a Useful Task Board by Richard Lawerence
Visual Management Blog by Xavier Quesada Allue Elements of Taskboard Design
Task Boards: Telling a Compelling Agile Story by Tom Perry



Saturday, November 16, 2013

Velocity Calculus

Velocity Calculus  -- by David A. Koontz
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.  That in its self is an interesting phenomenon, worthy of a blog post.  But this is not it.

Calculus is the mathematical study of change.



This video is a photo journal simulation describing how to calculate a Scrum sprint velocity.  It explains the calculus for one of the most difficult decision a team faces.  What to do with that first unfinished story.


Relative Points explained

Are your teams having difficulty understanding the relative nature of story points?  Try an analogy ... maybe one that is already well know... yet so often used that they have forgotten just how easy it is to use relative measures.  I'll bet they use it every day, multiple times per day.  That kind of practice makes usage very easy.  That is how easy story points will become for a team that practices.

Here's your analogy - in less than 10 seconds.  But you might need to repeat it about 14 times...



YouTube channel:  Minute Physics


Monday, November 4, 2013

Trending toward Collaboration


Is this a trend in the industry?  Perhaps some of the first movers in the work-from-anywhere movement have had a chance to see the return on this policy.  Perhaps they have some indicators that collaboration is a skill best practiced in person.  Practiced with full body awareness, in sense-around with many of our more that 20 senses - rather than just a select few.  Are you aware of how many entities must practice the same behavior, concurrently for there to be a true movement?  Do you want to be on the front end of the last movement in your industry or the bleeding edge of this movement?

Yahoo sees the ROI from canceling the work from home policy.
"There is definitely merit to the idea, however, that bringing its agile programming teams together in the same place at the same time can have a small but crucial impact on performance. In his book People Analytics, MIT visiting scientist Ben Waber discusses the role of dependencies for programmers, that teams must coordinate closely to ensure their code meshes well. Citing others’ research as well as his own, Waber argues remote programmers are 8% less likely than co-located groups to communicate about dependencies, which translates to 32% longer code completion times--or death when you’re already as lumbering as Yahoo."

Read the article: Yahoo Says That Killing Working From Home is Turning Out Perfectly by Greg Lindsay Oct. 2013.

Who said: "collaboration tames giants in the land of Lilliput" - oh that was me.

IBM's Move To Eliminate Remote Work Was Right, Even If It Wasn't Popular - Inc. by Yoram Solomon Founder, Large Scale Creativity @yoram

"The answer is not black or white. It really depends on a few factors, and there is a hybrid approach, too."

"A marketing executive says IMB's move to limit telecommuting is the right path."