Monday, October 26, 2015

HBR:: Why Organizations Don't Learn

A nice article on HBR - "Why Organizations Don't Learn", by Francesca Gino and Bradley Staats; take a look.

They list these reasons:
  • Fear of failure
  • Fixed mindset
  • Over reliance on past performance
  • Attribution bias
The authors then give some strategies for overcoming these reasons for the lack of learning.  Many of these will be familiar to the agile community.

Who else has studied organization failure?  Well I've heard that many academics have studied the failure modes of organizations.  One was John Kotter's 8 Steps model developed by studying the failure modes of organizations trying to institute large scale changes.  Other's have studied how successful large mergers have been after the fact (some would suggest it's on the order of 20% successful).  Some have studied how successful large software development project have been (Chaos Report - it is not a good report).

So what does your leader do to encourage learning at the organizational level?  Is failure even allowed in your department?  If so then it will be discussed and talked about in formal settings and acknowledged by leaders, rather than only around the dark stairways and in hushed tones.

Leader's drive FEAR out of the room!

How To Ask Good Questions: David Stork at TEDxStanleyPark

Dr. David G. Stork is Distinguished Research Scientist and Research Director at Rambus Labs
Sometimes posing a good question is more important than answering a good question. Some unsolved questions—in science, philosophy, mathematics, humanities—are properly judged to be "better" than others, so we should consider how those questions arose and explore how best to guide ourselves to posing such world-class questions. This presentation explores why the act of posing good questions has been, for the most part, neglected by scholars and the general public alike and what we should do about it. There is a range of types of questions, each with optimal strategies for posing and now is the time for a call to arms for educators, researchers, technologists, and business leaders to explore the hows and whys of asking good questions.

See Also:
Pitfalls of Agile Transformations by Mary Poppendieck
Knut Haanaes - Two reasons companies fail - TED Talk AND how to avoid them:  Exploration and Exploitation

4 Questions Smart Leaders Always Ask Employees to Improve Their Performance
They're also great for fostering open dialog and developing meaningful work relationships.

End of nations: Is there an alternative to countries?  Nation states cause some of our biggest problems, from civil war to climate inaction. Science suggests there are better ways to run a planet.

Tuesday, August 18, 2015

Cultivating Collaboration via intense partnerships to solve problems.

Presented at  AgileGames2016 conference in Boston, April 28, 29th.

But not Agile2016 - so you can only see it in the  Microsoft NERD center MIT.

I presented this workshop at Agile Camp - Dallas, Oct 19th.

DFW Scrum Meeting Aug. 18th 2015
It’s said that two heads are better than one, in reference to problem solving. We will use Tangram puzzles to simulate this experience, and via structured debriefs of these exercises, discover the powerful behaviors of awesome collaboration, and the negative warning signs of poor collaboration. We will jump right into simulation exercises, come prepared to have FUN and learn by doing. 
 No lecture - if you want a lecture… go here:

Here are some of the resources and exercise if you wish to reproduce this workshop or want to dig further into the science behind collaboration.
Presentation Cultivation Collaboration (PDF)  *UDATED 5/8/16*  Spoiler Alert - don't look at the solutions!

Friday, July 31, 2015

Retromat:: A well planned Retro

Retrospective at GameStop based upon Corinna Baldaug's Retromat.

Retro process phases: Set the Stage, Gather Data, Generate Insight, Decide what to Do, Close the Retro


Set the Stage: give time to “arrive” and get into the right mood and focus upon the goal
Gather Data: reflect upon what happened, create a shared pool of information
Generate Insight: why did things happen this way? What patterns can we observe?
Decide What to Do: Pick what to work on, plan concrete steps of action
Close the Retro: reflect upon the retrospective, how could it improve? What shall we follow-up upon?

Activities for this Retro:

Quick Questions 
In ONE word – what do you need from the retro?
In ONE word – what is on your mind?
In ONE word – what is you current mindset in regards to your project: are you a:
Explorer – eager to dive in and research what worked
Shopper – Positive, happy if 1 good thing come out
Vacationer – Reluctant, but retros beat regular work
Prisoner – Only attend because they make you

The Four Ls
Regarding the last iteration, individually for each of these 4 questions (one item per sticky) write:
What I Loved
What I Learned
What I Lacked
What I Longed for

Perfection Game
Everyone rates the last iteration on scale of 1 (poor) to 10 (perfect).
Next – make suggestion to raise your rating toward a 10, rate that suggestion using remaining 10 – x points

Circle of Influence & Concern
On a chart of concentric circles… inner to outter circle;
Team controls – direct action
Team influences – persuasive action
System – response action

Sort insight from Perfection Game into circle of influence & concern;
Write possible actions – annotate the item with actions
Dot vote on which action to attempt

The team created this info graphic of their Four Ls exercise using the Circle of Influence & Concern. Stepping back they realized - they are the master's of their domain.

We Control our own Destiny

Feedback Door – Smilies
Happy, OK, Sad
Mark your satisfaction with the retro session on the chart.

Wednesday, July 29, 2015

On my ToDo book shelf

A wish list of books I'd like to read...

Large-Scale Scrum - more with LeSS  by Craig Larman & Bas Vodde
It describes how we did scrum 10 years ago without the need to think about scaling on a VoIP project at SpeakEasy.  Four teams of around 40 developers (programmers, testers, UI, UX, BA, system engineers, etc.), one backlog, one awesome Product Owner (with a team of help), one deliver of working tested software, on time and on budget.

My current goto resource for how to do Scrum at any scale.

Team Genius: The New Science of High-Performing Organizations
by Rich Karlgaard, Michael S. Malone

"Throughout, Rich Karlgaard and Michael S. Malone share insights and real-life examples gleaned from their careers as journalists, analysts, investors, and globetrotting entrepreneurs, meeting successful teams and team leaders to reveal some "new truths":

The right team size is usually one fewer person than what managers think they need.
The greatest question facing good teams is not how to succeed, but how to die.
Good "chemistry" often makes for the least effective teams.
Cognitive diversity yields the highest performance gains—but only if you understand what it is.
How to find the "bliss point" in team intimacy—and become three times more productive.
How to identify destructive team members before they do harm.
Why small teams are 40 percent more likely to create a successful breakthrough than a solo genius is.
Why groups of 7 (± 2), 150, and 1,500 are magic sizes for teams.

Eye-opening, grounded, and essential, Team Genius is the next big idea to revolutionize business."

Passionate Performance  by Lee J. Colan

This quick read cuts through the clutter to offer practical strategies to engage the minds and heart of your employeees. Learn why this is such a powerful advantage for your organization. Read it and conquer your competition!

Team of Teams: New Rules of Engagement for a Complex World   by General Stanley McChrystal

A NEW APPROACH FOR A NEW WORLD McChrystal and his colleagues discarded a century of conventional wisdom and remade the Task Force, in the midst of a grueling war, into something new: a network that combined extremely transparent communication with decentralized decision-making authority. The walls between silos were torn down. Leaders looked at the best practices of the smallest units and found ways to ex­tend them to thousands of people on three continents, using technology to establish a oneness that would have been impossible even a decade earlier. The Task Force became a “team of teams”—faster, flatter, more flex­ible—and beat back Al Qaeda.

How could we measure Team Happiness?

Do you believe that what you measure you will get?  If so you want to start to measure team happiness.  So what techniques do we have to measure something so ephemeral?

The health care industry has studied measuring pain and have very good data on their ability to measure and administer pain drugs upon a subjective self report.  Maybe we could do the same in knowledge worker teams and work groups.

Team Happiness Net Promoter Score sheet
Here's a riff upon the classic Net Promoter Score for measuring team happiness.

 "How likely is it that you would recommend our team to a trusted friend that is looking for a job?"

To calculate the NPS - the continuum is divided into 3 groups; the detractors (1 - 6), the passive (7 & 8), the promoters (9 & 10).  The passive are ignored - they do not promote your objective.  The NET promoter score is the percentage of people promoting your objective minus the percentage of people detracting from your objective.

     NPS = Promoter % - Detractor %  (valid range +100% to -100%)

How does this objective of promoting your team as a recommendation for a friend seeking a job a proxy for team happiness?  I've not met many good people that would shaft a friend by recommending an unhappy team - have you?

Note:  with small populations (like a scrum team) there is high variability based upon a few people's scoring,  another companion metric would be the percentage of people participating in the survey.  Did the whole team play - or do you have a core group that is the in-group?

See Also:

Visualizing Agility: Agile Metrics that Matter by Jay Packlick

Monday, July 27, 2015

Transparency - Two Way Visibility

What does the value of Transparency really mean?
Nextgov: How do you define transparency?
Fung: My definition is quite a bit different from the conventional wisdom about transparency. A transparency system is designed to allow people to improve the quality of decisions they make in some way, shape or form, and it enables them to improve their decisions to reduce the risks they face or to protect their interests. Some of those decisions are about political accountability but some are in private life, like what food to buy or what doctor to go to.
-- Archon Fung, professor at Harvard University's John F. Kennedy School of Government who studies government transparency.

Does your company practice fair pay?  Here's what one worker brought to Google and made a difference in transparency at the search giant.
Tell Your Co-Workers How Much You Make!  There's no law against it and it increases the chances you'll be paid fairly.

Does the Agile Manifesto imply some form of organizational transparency? I believe so, yes.  Here's what Jeff Sutherland has to say about the topic, look for the Individual and Interaction section.  Agile Principles and Values by Jeff Sutherland on MSDN.

Scrum's 5 core values list the concept of Openness.  Is this not very similar to Transparency?

There are lots of synonyms - visibility, openness, observable, apparent, etc.

Does this value of transparency imply that the information flows in both directions, up and down an organizational hierarchy, from line-workers to managers & directors, as well as from CEO to directors and wage earners also?

See Also:

Friday, July 24, 2015

Scrum Immersion workshop at GameStop - Case Study

Here's a overview of a Scrum Immersion workshop done at GameStop this month. A case study example.

Normally these workshops start with the leadership (the stakeholders or shareholders) which have a vision for a product (or project). This time we skipped this activity.

The purpose of the Workshop is to ensure alignment between the leadership team and the Agile Coaches with regards to the upcoming scrum workshop for the team(s). Set expectations for a transition from current (ad-hoc) practices to Scrum. Explain and educate on the role of the Product Owner.

Expected Outcomes:
  • Create a transition plan/schedule
  • Set realistic expectations for transition and next release
  • Overview of Scrum & leadership in an Agile environment
  • Identify a Scrum Product Owner – review role expectations
  • Alignment on Project/Program purpose or vision
  • Release goal (within context of Project/Program & Scrum transition)

Once we have alignment on the Product Owner role and the Project Vision we typically do a second workshop for the PO to elaborate the Product Vision into a Backlog. This time we skipped this activity.

The purpose of the Workshop is to educate the Product Owner (one person) and prepare a product backlog for the scrum immersion workshop. Also include the various consultants, SME, BA, developers, etc. in the backlog grooming process. 
Expected Outcomes:
  • Set realistic expectations for transition and next release
  • Overview of Scrum & Product Owner role (and how the team supports this role)
  • Set PO role responsibilities and expectations
  • Alignment of Release goal (within context of Project/Program & Scrum transition)
  • Product Backlog ordered (prioritized) for the first 2 sprints
  • Agreement to Scrum cadence for planning meetings and grooming backlog and sprint review meetings

Once we have a PO engaged and we have a Product Backlog it is time to launch the team with a workshop - this activity typically requires from 2 to 5 days. This is the activity we did at GameStop this week.
The primary purpose of the workshop is to teach just enough of the Scrum process framework and the Agile mindset to get the team functioning as a Scrum team and working on the product backlog immediately after the workshop ends (begin Sprint One). 
Expected Outcomes:
  • Set realistic expectations for transition and next release
  • Basic mechanics of Scrum process framework
  • Understanding of additional engineering practices required to be an effective Scrum team A groomed / refined product backlog for 1- 3 iterations
  • A backlog that is estimated for 1 – 3 iterations
  • A Release plan, and expectations of its fidelity – plans to re-plan
  • Ability to start the very next day with Sprint Planning

Images from the workshop

The team brainstormed and the prioritized the objectives and activities of the workshop.

Purpose and Objectives of the Workshop
The team then prioritized the Meta backlog (a list of both work items and learning items and activities) for the workshop.

Meta Backlog of workshop teams - ordered by participants

Possible PBI for Next Meta Sprint

Possible PBI for Later Sprints

Possible PBI for Some Day

Possible PBI for Another Month or Never

A few examples of work products (outcomes) from the workshop.

Affinity grouping of Persona for the user role in stories

Project Success Sliders activity
Team Roster (# of teams person is on)

A few team members working hard
Three stories written during elaboration activity

A few stories after Affinity Estimation

Release Planning:  Using the concept of deriving duration based upon the estimated effort.  We made some assumptions of the business desired outcome;  that was to finish the complete product backlog by a fixed date.
The 1st iteration of a Release Plan
 That didn't feel good to the team, so we tried a different approach.  To fix the scope and cost, but to have a variable timeframe.
The 2nd iteration of a Release Plan
 That didn't feel good to the PO, so we tried again.  This time we fixed the cost and time, but varied the features, and broke the product backlog into milestones of releasable, valuable software.
The 3rd iteration of a Release Plan
This initial release plan feels better to both the team and the PO, so we start here.  Ready for sprint planning tomorrow.

Friday, July 10, 2015

Exercise: Pair Programming Simulation using Tangrams

Yesterday (July, 2015) we did a lunch-n-learn at GameStop HQ on pair programming.  I think it was a great success, largely because we serve food, and I've been told that everything goes better when people are sharing a meal together (and even better with adult beverages).

Are you interested in Pair Programming?  I'll confess, the term is a bit misleading.  I was asked by multiple people if the topic was just for programmers.  No - no it's not just a programming technique. It is also for any kind of knowledge work.  Such as testing, or analysis, or writing stories, or ... yes coding, scripting, excel spreadsheets, etc.

The Agenda: Pair Programming Simulation

Start with a warm up exercise (totally non-related to the topic).  This allows all the late arrivals to find a seat and not miss out on the real start of the session.  I've found this technique (soft start) to be a required technique for companies that have not adopted basic meeting protocols, such as finishing prior to the start of the next meeting.  IF one does not finish on time, how can one start on time?

We used Thiagi's warm up of Buying Happiness

Flipped this lesson.  Although the experiment resulted in a - How Fascinating (failure).  No one actually participated in the homework to read the lesson before the experience session.  We continued without doing any actual lecture.

PDF - Pair Programming - Lessons

Query the audience - to share the common level of people with respect to the domain knowledge.  Ask a few questions - raise your hand if you have heard of pair programming, if you've done pair programming, if you only program in a pairs (every day)?  Look around - these are the experts.  Raise your hand if you are a beginner?  When you read the homework on pairing, you remember that pairing beginners with beginners is an anti-pattern.  So what shall we do about that?

Restructure the seating arrangements, have people select appropriate pair for their skill level.  Don't allow the beginners to sit together and the experts to create a click.

Part ONE.  Pair Drawing.

Let's do the simplest thing that could possibly work... everyone has learned to draw/sketch.  Let's use this innate skill to explore pairing basics.

PDF - Pair Face Drawing

Most people are afraid to draw.  At some point in our traditional schooling we are made ashamed of our ability to draw.  With a bit of expert practice many can over come this self imposed limitation.  Here's a TED Talk to start you on the path to recovery.

Why people believe they can’t draw - and how to prove they can | Graham Shaw | TEDxHull

Part TWO.  Lunch.

Typically what draws everyone to your meeting... food.  Don't do Lunch-n-Learn with out this.

Part Three.  Pair Puzzle Solving.

Let's extend our learning into a harder problem domain... solving a puzzle - Tangrams.

PDF - Pair Puzzle - Tangram Solving

PDF - Cultivating Collaboration - Simulation via Tangrams - or a starter guide to Pair Programming

This exercise can touch upon the aspects of Test-First (TDD) practices.  Typically a topic for another Lunch-n-Learn.


A great facilitator does the exercise / simulation just to get to the debrief.  Reflection is the only activity where double loop learning may occur.  Using metaphor and analogy to relate drawing faces or solving Tangrams to developing software is the job of the debrief.

In a large group with many subgroups this can be done by projecting the debrief question on the screen and having the subgroups (tables) debrief themselves.  Extra points given for summaries of learning points or action items discovered.

We did a debrief after each example problem.  Then ran out of time to debrief the whole workshop - but did get Level One feedback on the workshop.  It was a 8 or 9 (out of 10) with a few improvement to make for next time.


See Also:

A Week of Pair Programming by Matt Chalice

Two Years of Pair Programming by Matt Cholick

Friday, June 26, 2015

To be a Profession or to Unionize in the Software Industry?

Which form of industry growth would you prefer - why?

Which path leads toward the culture you desire in a software development organization?

This is a wonderful article on the topic - read it and discuss with your colleagues.

Programmers don’t need a union. We need a profession.  BY 

"Unions work best for commodity labor, and I use that term non-pejoratively. Commodity work is easily measurable and people can often be individually evaluated for performance. For example, a fishing boat operator is measured according to the quantity of fish she procures. A lot of very important work is commodity labor, so I don’t intend to disparage anyone by using that term. Commodity work can be unionized because there aren’t large and often intangible discrepancies in quality of output, and collective bargaining is often the best way to ensure that the workers are fairly compensated for the value they produce. Software is not commodity work, however. It’s difficult to measure quality, and the field is so specialized that engineers are not remotely interchangeable. When the work is difficult to measure and large disparities of quality exist, you have a situation in which a certain less-egalitarian (in the sense of allowing top performers to receive high compensation, because it’s essential to encourage people to improve themselves) and more self-regulatory structure is required: a profession."
"A profession is an attempt to impose global structure over a category of specialized, cognitively intensive work where the quality of output has substantial ramifications, but is difficult (if not, in the short term, impossible) to measure, giving ethics and competence primary importance. A profession is needed when it’s clear that not everyone can perform the work well, especially without specialized training. Here are some traits that signify the existence of a profession."
1) Ethical obligations that supersede managerial authority.
2) Weak power relationships.
3) Continuing improvement and self-direction as requirements.
4) Allowance for self-direction.
5) Except in egregious cases, an agreement between employee and firm to serve each others’ interests, even after employment ends.

Friday, April 17, 2015

Topics for Lunch-N-Learn

Brainstorming a list of topics for a Scrum/Agile lunch-N-learn session.

  • Pair Programming - simulation using Tangrams & Face Drawing
  • Practices for Daily Standup - review and discuss: It's Not Just Standing Up: Patterns for Daily Standup Meetings
  • Slicing Stories – resources to slice vertical stories of value
  • Story Writing techniques:  w/ Q&A based upon participants real stories
  • Estimation techniques:  Affinity Estimation; T-shirt sizing -> converting to numbers; Planning Poker (the rule book)
  • Team building tools:  Infinite Loops; Helium Stick; Warp Speed;  Pair Drawing, etc.
  • Definition of Done/Ready exercise
  • Release Planning   How to derive duration with a complicated backlog
  • Agile Library Initiation  Bring books, make the rules, get funding, 1,2,3, GO!
  • Management 3.0 Book Club - join a group reading the best Agile book written.
  • Making Visual Information Radiators - define Radiator/Cooler;  elements of a Scrum board
  • Aspects of an effective Product Backlog
  • Agile Portfolio Planning - tools and techniques; estimation, cost of delay, prioritization, deciding what NOT to do
  • The principle of TDD via LEGO building;  anyone can learn the power of test first development
  • Does you development rest on a SOLID foundation - an overview of the SOLID principles
  • Collaboration Games to understand the customer;   12 Innovation Games;  Other resources
  • User Story Maps technique to achieve higher level understanding of the backlog
  • Launching a Team;  what’s required, best practices, examples and techniques
  • Team Practices:  a collection of quick tools to increase team work and collaboration
  • Learn Backlog Prioritization techniques:  Cost of Delay,  Perceived ROI,  Delivery Order, Gut Feeling, Loudest Yeller
  • Agile Planning - paradigm changes in planning, the planning flame, release planning, road maps, etc.
see also:

Monday, February 23, 2015

Why Visual Management Techniques are so Powerful

How does the brain process visual clues to the environment and synthesize meaning about an ever changing landscape?  Tom Wujec explains the creation of mental models and why AutoDesk invest in visual management techniques to plan their strategic roadmaps.

Also in one of Tom Wujec's talks on How to Make Toast, he explains another important point of visual management - system's thinking and group work.

Don't worry... the mind will do all the work.  It will fill in the missing details, and abstract the patterns into the concept.  Here's an exercise, Squiggle Birds by David Gray, to experience this.

See Also:
Your Brain on ScrumMichael de la Maza on InfoQ

Visual Management Blog

Visual Thinking - Wikipedia

David Gray on Visual Thinking

Ultimate Wallboard Challenge 2010  time-lapse of Vodafone Web Team's board

iPad Interactive Whiteboard Remote

Multitasking: This is your brain on Media
Multitasking: This is your brain on Media - Infographic by Column Five Media.

Wednesday, February 11, 2015

The Simplest Systems Thinking Exercise - How to Make Toast.

For many years one example of process thinking, resource gathering, requirements, implementation and acceptance criteria has been the exercise - make PB&J sandwiches.  I've done this with groups to discuss the simple task that we typically overlook as "experts" in sandwich making, that perhaps a 5 year old will find difficulty glossing over the - get bread - instruction.

Here's a TED Talk by Tom Wujec who has analyzed a similar exercise and draws some powerful conclusions from many iterations.  Watch it and then rethink the simple acts in your life.

So tell me again why group collaboration is important when you are solving wicked problems?

See Also:

Visual Thinking