Thursday, October 4, 2012

S.O.L.I.D. software class design principles


Perhaps you have heard of the S.O.L.I.D. software design principles of Object Oriented Design, but lack the motivation to practice the principles in every day coding.  If this is your problem, then here is the solution.  Six motivational posters to visualize and remember the principles.  Print them out and display then in your team room.  Watch the quality meter go up.

   










SOLID Motivational Posters, by Derick Bailey, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

See Also:
     Agile is an Integral Equation.

     The Four Elements of Simple Design     Putting an Age-Old Question to Rest   JB Rains

7 stages of Naming by Arlo Belshee



Tuesday, September 18, 2012

I want it all, but don't change my connectors

People just don't like change.  Case in point, all the hubbub over the new iPhone 5 lightening adapter plug.  So many people are upset that the connector is changing from the 9 year old iPod 30 pin adaptor to the new lightning adaptor.  Yet at the same time the iPhone 5 pre-orders have record sells (2 million in first 24 hrs).

Why did Apple force this change on it's loyal customer base?  Dont they know we humans don't adapt well to changes.  Oh yes, we want the new shinny iPhone but we want it to stay the same AND get better.

Maybe this picture will give you a clue as to why Apple changed the connector. It shows a typical iPhone and it's 30 pin connector, with a Raspberry Pi.  The Raspberry Pi is a full fledged computer on a board.  Take a look at the board and the most obvious thing is all the connectors.  The interface connections are the largest things.  They occupy the most space.

Raspberry Pi & iPhone compared
The reason for the change?  So that Apple could pack more techy goodness into the same volume, and have a platform for future techno stuff.  They miniaturized almost every internal component of the iPhone (the complete redesign).  Hey - that is innovation.  And I have to believe there will be room for new components (like the Near Field Communication radio) when that eco-system is ready for consumer devices.

Saturday, September 8, 2012

Best T-shirt at Agile 2012

What was your favorite T-shirt seen at the Agile 2012 conference?

One awesome t-shirt was seen on Adam Yuret @AdamYuret.

Ninja + Rockstar != Teamwork.
Ninja + Rockstar != Teamwork tshirt
In his article the Myth of the Rockstar Programmer, Scott Hanselman lays out these definitions:
  • Junior Engineer - Creates complex solutions to simple problems.
  • Engineer - Creates simple solutions to simple problems.
  • Senior Engineer - Creates simple solutions to complex problems.
  • Rockstar Engineer - Makes complex problems disappear.
Speaking of t-shirts; his graphic would go very well on a t-shirt wouldn't it?  Well, I created one very similar a few months ago.   Obviously there is an I in TEAM! t-shirt - buy one now on Zazzle.
Buy it on Zazzle - NOW!

This is the best t-shirt give away I received, the Tasty Cupcakes Got Game? t-shirt.





Tuesday, September 4, 2012

Exercise:: Pair Chess Game


Some years ago I designed this exercise for a Pair Programming simulation using the media of the game of chess.  The idea was to have a pair on each side of the board, they would work together to finish a famous game against their opponents (a pair also).

I never used the exercise because the developers I was working with didn't know the game of chess, and didn't seem interested in the simulation.   If you use this please let me know how it works out.




Garry Kasparov (White) vs X3D Fritz Computer (Black)
Man-Machine World Chess Championship 2003
Game 1 (after 31 ... Bxa2)
White to move





Instructor material for Chess Game Pairing Exercise

Required Materials

Chess board and pieces (one per 4 students)
Timers (optional)
Diagram of an in-progress chess game(s) (attached)

Introduce the Exercise

Pair programming is generally thought of as an XP (extreme programming) practice.  In true Agile form we are borrowing a practice that has value to use in our process.  Pair programming is when two (or sometimes more) developers work on a task simultaneously at the same computer.

This exercise is designed to give you the feel of pair programming. You will pair up with another person and become a chess playing savant team!  Each team will be pitted against another team to solve a world class chess problem.  Setup the chess board in the exact position described on the problem sheet.  Then playing as a pair (perhaps with limitations – see variations below).

The Exercise – Part One: Setup the board 

Instruct the students to retrieve a chess set and the sheet describing the chess problem.

Their task is to setup the chess board as diagrammed.  

Exercise – Part Two:  Let the games begin!

The instructor can give limitations or not, constraints, rules, etc.
Then they are to begin – White moves first! 

Variations
  • Only allow the pair that is in play to talk, the pair not moving must stay silent.
  • No talking and strict turn taking for first 5 moves, then instructor announces that communication and cooperation may take place for the rest of the moves.
  • One minute time limit per move.
  • Pair beginners with experts – have the group self rate from 1 – 10.
Debrief the Exercise

The only reason to do an exercise is to get to the debrief stage.  This is where students will apply the simulation to the “real world” and learning will happen. Please give at least 20 minutes for the debriefing phase.

Facilitator will start the debriefing – ask open-ended questions such as:
  • What happened during the exercise?
  • What did you notice about the act of pairing in a traditionally solo activity?
  • Which activity was harder, more fun, required more concentration, stimulated creativity, produced more interesting results?
  • What do you like/dislike about pairing?
  • How did you decide to what moves to make – did you talk? Did you test out move?
  • Did you find that one partner lead and the other followed, did the lead change?
  • How does this simulation compare to the task of programming?
  • What lessons can you learn?
The debrief should take 10 – 30 minutes (if the students don’t have anything to discuss, then it was not very instructive).

Major points of the exercise:  

Pairing can be more fun, more creative.  Problem solving is creative and one person’s idea can spark better ideas in another person.  To effectively pair one must take turns, and communicate their ideas and intentions, they must actively involve the partner.




Bobby Fischer (white) vs Greenblatt Computer (black)
1977 Computer Match
White to move














See Also:

Globe Chess Board


Friday, August 31, 2012

Exercise:: Mapping Engineering Practices to Agile Principles

What are the necessary and sufficient engineering practices that an agile team needs to support the Agile Manifesto's 12 principles?

There is no one right answer - yet there are some very common patterns one sees when this exercise is repeated for multiple teams within an organization transitioning to agile software development.  From this analysis one could derive the set of core practices for your agile organization.





Exercise :: Mapping Engineering Principles to Agile Practices (PDF) by David Koontz

Facilitation Guide
Set up Print all material, one Agile principle per page (enlarge if you wish).
Hang the Agile Manifesto on the wall.
Hang the 12 Principles on the wall.
Hang the suggested list of Practices on the wall.

Have multiple colors of sticky notes & lots of pens/markers.

Introduce the Manifesto and the 12 principles
Discuss the Agile Manifesto - tell the history - describe what a process is and is not. Is “Agile” is a process?  Describe a philosophy - could it be that?

Distinguish between a Principle and a Practice
Switch to the Engineering Practices - describe a few of them - invite participants to read the list, to circle the ones which they currently do very well. 
Invite them to add to the list - debate which practices are redundant (ex: code review & pair programming).

If the group currently has real disciplined practices - use them to map to the principles - however if not don’t waste your time - just to the desired future state.

Dot-vote - each person pick three (2-5 is a nice range for this) engineering practices they wish to use in the future - the best practices to make us an Agile team.

Using those top voted practices (limit to 5 -8 practices to map), have people pair up and map one practice at a time to the 12 principles.  Decide if the engineering practice “supports” the principle - if so put the sticky on the paper - if weakly supporting - put the sticky below - if not at all then no sticky. Same pair do each principle. Use different colored stickies for different practices to create a nice Info-graphic when all done.
Be the example - select two participants and demo the first few principles for something like TDD.

Debrief
Which principle is weakly supported by practices?
What practice would fill this gap?
Which practice supports the most of the Agile philosophy?
Does it work alone - if we just do that one practice - are we Agile?
What is the “neccessary and sufficient” set of practices for Agile?
Which practices should we embrase as a core set?



Engineering Practices
Continuous Integration with Automated Builds
Smoke Testing / Build Verification Tests
Domain Driven Design / Emergent Design / Evolutionary Design Behavior Driven Development
Test Driven Development
Pair Programming
Code Reviews
Automated Software Metrics
Source Version Control
Issue / Bug Tracking
Configuration management
Unit Testing
Integration Testing via Mock/Fake/Stub sub-systems
Exploratory Testing
System Metaphor
Story Testing / Acceptance Tests / Automated Regression Test
Scrum (Process Framework)
Extreme Programming (XP) Framework
Stand-up Meeting
Velocity Based Planning
Team estimation in relative units (Story Points)
Iteration Demo & Customer Feedback
Information Radiators (Big Visible Charts)
Cross-Functional Team
Team based work flow / Teamwork / Persistent Team
Co-located Team / Common Workspace
Design Improvement via Refactoring
Small Releases / Frequent Delivery
Collective Code Ownership
Coding Conventions & Standards
Simple Design (Once & Only Once, YAGNI, etc)
User Stories


See Also:

The 12 Principles Ice Breaker by Gerard Chiva on Oikosofy
What are the Principles - a case study of using this exercise

Sunday, August 19, 2012

Stress in Speakers at Agile2012

I chatted with a lot of presenters at Agile2012 last week.  So many of them were releived to have been done with their presentations.  I think the conference creates a bit of stress in the speakers.

I didn't have any stress as a volunteer.  I helped out with the conference sessions, collected feedback forms, tried to help the speakers right at that most stressful moment, before the first joke and before the audience gets into the topic.

I think all the speakers that I saw did a wonderful job.  I volunteered at the experience report and case study stage. These are the non-professional speakers. The nervous energy in the room rises very predictably in these session.

So I suggest the speakers take a vacation after this conference - you earned it.

Master Your Stress
Created by: www.MastersDegreeOnline.org

Thursday, August 9, 2012

Agile in a CAN

Wow - look at the number of people that are sponsoring this awesome idea,  Agile in a Can.  Proving once again that crowdsourcing is the 21st century answer to robber-barrons of the 19th century.  Yes - "the 21st century is when it all changes" - Capt. Jack Harkness.

You should hurry over to Agile In A Can website to get in on this once in a life time deal.


Limited supplies of the active ingredients will make this product more and more valuable into the future. 

Friday, July 27, 2012

Traditional Test Engineering is DEAD

Here's an outline of Jason Arbon's arguments for Agile methods leaving traditional test engineering in the dust.

In the Better Software (May/June 2012) article "Traditional Test Engineering, Your Days are Numbered; Turing Software Quality on Its Head."

"In this shift to agile, late cycle or manual testing efforts are often dropped or, worse, the program management and development teams embrace agile and continuous practices, but the old world regression test cycle is left hanging around like an archaic ritual that adds a few days or weeks to an engineering process that wants to be continuous."

Test Plans - quick cycles out pace the ability of managers to create the traditional test plan. Modern software development teams do more concurrent testing than was ever done in traditional processes.

Regression Testing - ninety some precent pass all the time, is this a good use of time and energy. Create a risk view of the application under test. Use automated tools and focus time and energy on these risky areas.

Textual Bug Filing and Triage - this manual process is bugger than the software being reported upon. Try logging the number of defects with the defects already recorded in your logging system. Move to automated systems that report bugs with attached screen shots of the systems and the steps to reproduce the incident.

Bug and Work Item Backlogs - the best advice for managers is "Don't". If you have to refer to a list of bugs then you don't know your software. People that know and use your software know what bugs need to be fixed. That information is in there minds daily, ask them. There is no need of a list of bugs that will take 3 years to get to the end of it. Trust me - you will not forget the really important bugs.

Test Case Databases - these are a sign of non-agile work methods.  Databases are very heavyweight, compared to a lightweight list of areas to test that the team is currently work upon, and a suite of always green, passing tests.

Release Management - we are in an era of continuous releases, the question is not if or when the release goes out the door - but only if a feature is turned on or off in that particular release.  If your features can not be expressed in this binary state, your application is really old-school.

Team Structure - many smaller companies reap the benefits of crowdsourced testing teams that and virtualized testing teams.

----
see also:
The 21st century definition of TEST

Saturday, July 14, 2012

Active Listening: The 5 Second Rule

Learning to listen is a difficult skill to teach. On the surface it appears to be a passive activity. It is the reflection portion of the listening activity that might need enhancement. Here is a group exercise that will strengthen your team's ability to listen. The 5 Second Rule. After a person speaks, everyone must count to 5 (5 seconds) before anyone speaks. If you wish to speak next, you must physically count on your raised hand via fingers 1, 2, 3, 4, 5. Practice this a few time, counting slowly (maybe extend it to 10 seconds if there are lots of fast counters). If two or more people raise their hands to speak next, then they (not the group) decide the speaking order. This pause in the immediate point, counter-point might allow the conversation to become multi-perspective, rather than percussive-discussion, like a ping-pong match. Most teams will expand their views and learn to be inclusive during dialogues with this technique. When multiple people want to speak to a point, a visual indicator of this, the raised hand, reminds the group that a discussion point has multiple perspectives. Expanding the number of speakers in the dialogue will reduce the myopic effect of a two person debate of the topic. Some Exceptions to the 5 Second Rule. If there is a facilitator in the meeting or group discussion, they should have an exception to the rule when they are using their facilitation skills to make process notes, points of order, make know violations of working agreements, etc. Direct questions from one individual to a named individual may be excepted from the rule. However, be careful, people will game this rule to turn the dialogue into a few person debate. See the facilitator exception.

Thursday, July 5, 2012

Missing Affordances

What are the affordances that are missing from the virtual task board?  There are quite a few.

The perceptual psychologist J. J. Gibson coined the term in the late 1970s to mean the relationships that an actor (person) can have with objects in the world.  Then Donald Norman popularized the term in his book "The Design of Everyday Things."

You may think these affordances don't matter much.  But after you have them (via using a physical task board) you will find they are sorely missing.

I can:
  • Hold a task and show it to you. Now you know exactly what I'm talking about. Many virtual task board have no way of denoting a selected task. 
  • Pick a different task and hold it. Now I know you are talking about that one, but I'm still referring to the one I hold. 
  • Move a task. The motion is the affordance. Not the before and after location of a task - don't confuse position with motion. 
  • Pass a sticky note to you, now you have it and this denotes responsibility to perform the task perhaps. You may choose to stick it on your monitor as a reminder to perform the task later that day. 
  • Wad up a task and toss it on the floor. You may infer that I don't think we need this task any more. 
  • Retrieve a task from the floor and straighten it out and place it back on the board. Does your virtual tool have an undo feature? 
  • Slice the task into and hand you part of the task. Now you have a portion to own and I have a portion to own. 
  • Stack multiple task upon each other, this grouping may imply order or just a collection of like task. 
  • Annotate the task with yet another sticky note - this one could be a red sticky with an exclamation mark (meaning impeded). 
  • Revise the task with a simple swipe of the ink pen, to mark out a word. 
  • Augment the task with a new inserted word to provide more meaning with just a simple writing tool. 
  • Draw a diagram on the task - that's worth 1000 words! 
As an exercise try this with your team.  Make a list of all the tacit protocols that have developed to indicate affordances that are missing with your virtual task board.  For example:  selecting the task and highlighting it in some way to make people understand which task you are "holding."

Want an example of affordances on a dashboard or infographic?

Affordances and Signifiers: applying design theory to your dashboards


Saturday, June 23, 2012

I Would Ask 500 Whys

'I would ask 500 Whys'

When I stand up yeah I know I'm gonna be
I'm gonna be the man who stands up next to you
When I unit test yeah I know I'm gonna be
I'm gonna be the man who tests along with you


The Proclaimers - I Would Walk 500 Miles

If I get drunk yes I know I'm gonna be
I'm gonna be the man who gets drunk next to you
And if I haver yeah I know I'm gonna be
I'm gonna be the man who's havering to you

But I would ask 500 whys
And I would ask 500 more
Just to be the man who asked 1000 whys
To help your process improve.

When I'm working yes I know I'm gonna be
I'm gonna be the man who's working hard for you
And when the praise comes in for the work I'll do
I'll pass almost every accolade on to you

When I program yeah I know I'm gonna be
I'm gonna be the man who pair programs with you
And if I falter well I know I'm gonna be
I'm gonna be the man who's learning with you

But I would ask 500 whys
And I would ask 500 more
Just to be the man who asked 1000 whys
To help your process improve.

When I'm lonely yes I know I'm gonna be
I'm gonna be the man whose lonely without you
When I'm dreaming yes I know I'm gonna dream
Dream about the coding we could do.

But I would ask 500 whys
And I would ask 500 more
Just to be the man who asked 1000 whys
To help your process improve.

Original Lyrics source: http://www.lyricsondemand.com/onehitwonders/imgonnabe500mileslyrics.html


Wednesday, June 20, 2012

Agile Software Development Timeline

A Timeline by definition is an iterative document - it is incrementally built minute by minute with no known completion point. However the historical entries on the time line might be elaborate also. This is a rough draft... please comment with new (better - more important, more accurate) events. Or point me to better resources - other historical time lines etc.  Thanks!

Watch Earth's history on a 100yd football field timeline.




1202 Fibonacci introduces Arabic numerals (0-9 and place value) to the West via book “Liber Abaci” (Book of Abacus or Calculation).  The Zero is born!

1950s Demining teaches in Japan

1960s NASA’s Project mercury uses test-first development and micro-increments

1971 The Psychology of Computer Publishing by Gerald Weinberg - largely ignored

1976 EVO Methodology by Tom Gilb

1980s Japanese car companies expand into Europe & Americas

1986 New New Product Development by Takeuchi & Nonaka

1986 No Silver Bullet by Fred Brooks - advantages of Incremental & Iterative Development

1987 Peopleware by deMarco & Lister

1988 Iterative delivery described by Tom Gilb in Principles of Software Engineering Management

Software Patterns

Pair Programming - organizational patterns described by James Coplien

1990 The Machine that Changed the World by Womack & Jones

1990s Object-oriented Programming

1990s Schwaber uses early Scrum at Advanced Development Methods
1990s Sutherland uses early Scrum at Easel Corporation
1990s Internet
1990s Dot-Com Boom

1994 Book:  Agile Competitors and Virtual Organization: Strategies for Enriching the Customer

1995 DSDM consortium publishes version 1.

1995 Scrum Methodology paper by Sutherland & Schwaber

1996 Lean Thinking  by Womack & Jones

1996 Journey of the Software Professional: The Sociology of Software Development
By Hohmann

1996 Beck creates XP at Chrysler Comprehensive Compensation System (C3)

1997 Feature-Driven Development (FDD) by Jeff De Luca

1998 Extreme Programming by Kent Beck on c2.com wiki

1998 Crystal family of methodologies by Alistair Cockburn

1999 Java Modeling in Color with UML by Peter Coad  - Ch 6 describes FDD.

1999, Extreme Programming Explained by Beck

1990s Crystal Clear by Alistair Cockburn

1999 The Pragmatic Programmer: From Journeyman to Master by Hunt & Thomas

2000 Adaptive Software Development: A Collaborative Approach to Managing Complex Systems by Highsmith



2001 Agile Manifesto Signed - Feb in Snowbird Utah http://agilemanifesto.org/history.html

2001 Agile-Testing Yahoo! Group started

2001 Agile Software Development with Scrum by Schwaber & Beedle

2003 Lean Software Development by Poppendieck

2004  Watir released

2004 Agile Project management with Scrum by Schwaber

2005 Fit for Developing Software  by Mugridge & Cunningham

2006 BDD article by Dan North in Better Software Magazine

2006 RSpec released

2006 Selenium released

2007 Kanban introduced

2007 Scaled Agile Framework by Dean Leffingwell

2008 Cucumber released

2008 Robot Framework open sourced

2008 Slim update to Fitnesse

2009 The RSpec Book by Chelimsky & Astels

2009 Software Craftsmanship Conference

2011 PMI introduces Agile Certified Practitioner

2014 Schism in community of Scrum over techniques of scaling to enterprise

2016 Manifesto for Agile Company Development by Matt the Agile Coach



See Also:
The timeline in the Evolution of Scrum - 3Back



Timeline of Long Distance Communication


A Perspective on Time by  Visual.ly
51 Most Popular Tech Gadgets through the Years - Popular Mechanics







4 Billion years of Technology
infographic



Sources:

Elisabeth Hendrickson, Quality Tree Software, Inc.
Agile, Testing, and Quality: Looking Back, Moving Forward.  Oct 28, 2009
History of Agile S/W Development
Timeline of Computer Science  150 major events (via MIT) from 300BC to now


Friday, June 8, 2012

Tyranny of the Clock Face

Why do people schedule meetings and work-session into an arbitrary constraint of one hour blocks? Are we not capable of looking at the purpose and expected outcomes of the gathering and then estimating the appropriate duration needed to achieve the outcome? Do we not account for the cost and waste of having to reset context each time we meet and get to a partially finished state.

It is the tyranny of the clock face, broken into one hour increments. The clock is just a human abstraction of time, an arbitrary measuring instrument. It is not a prescription for scheduling. I think we are misunderstanding the purpose of the clock. One doesn't drive a car by the speedometer.

This obsession of one hour increments of work is ridiculous. I wonder where we learn it. Oh - yeah, school, where we learn many bad habits.

See Also:
HBR article Yes, You Can Make Meetings More Productive


The Hummingbird Effect: How Galileo Invented Timekeeping and Forever Changed Modern Life
by Maria Popova.  How the invisible hand of the clock powered the Industrial Revolution and sparked the Information Age.

Tuesday, June 5, 2012

How do you find a Word?

I'm wondering if there are better techniques or resources for finding new interesting useful words than the techniques I'm currently using. My current technique is to just happen upon a good word - either in print/web/conversation. I have to admit, however, that few happen in conversation, fewer still in print such as news (typically a 5th or 6th grade reading level) - most new words are sourced via books and web articles. How do you look up a word that means, what you want it to mean - yet you don't know the meaning of? The inversion of the Humpty Dumpty quip in Through the Looking Glass.
"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean — neither more nor less."
"The question is," said Alice, "whether you can make words mean so many different things."
"The question is," said Humpty Dumpty, "which is to be master — that's all."


The web has a few unDictionaries (reverse dictionary) - haven't found a useful non-trivial one.

How do you find just the right word - a $1.50 word (with inflation - maybe a $1375 word)?

Example:
I'm looking for word - phrase for the concept: Using discreet physical objects to represent thoughts and concepts (modeling) that have many "affordances" (Don Norman's "The Design of Everyday Things" concept) as a way to build a shared distributed cognitive mental model. A model that can be manipulated in real time, instantly perceived by a group of people, and the affordances of the model, be predicted or inferred within the context of the model.

Could you help me make up such a word? It would be very helpful in my line of work. Maybe it should have a "kinesis" syllable in it. I suppose I could borrow from Bucky (http://en.wikipedia.org/wiki/Synergetics_(Fuller) ); Synergetic-modeling - or something like that.

Sunday, June 3, 2012

Internet usage reduces brain function

Here is an info-graphic that while interesting makes me a bit sad.

How the Internet is Ruining Your Brain

I do believe than we have entered into a very volatile micro-evolutionary portion of human history.  I do find that I off-load to various electronic media pieces of information and knowledge that might have years past be committed to memory.  I'm not sure this is a bad thing, yet we may surprise ourselves at the brink of our extinction.   We are in the exponential age - or as some call it the anthropocene.

So there are some controls one could place on the rot of your mind.  Try SelfControl an application that blocks the internet for a period of time - perhaps long enough for you to be productive.  I also tried RescueTime for a while, but found it not very helpful.  It did not motivate me to change my behavior.

I do find that many of us are delusional about our abilities to multitask.  My superpower is a slightly above normal ability to stay in a rut.  Single-Track-Man does not multitask.

So I'm working on getting my white matter back up to snuff - I'm trying to find an off-line interest in life.  Working on boats is a wonderful past time and a hole in the water where time and money just flows endlessly.


Created by: ForensicPsychology.net

Saturday, May 26, 2012

Are you imagining proper form?

Just imagine proper form and you can increase strength in your pinky finger 35%.

Imagine Increased Muscle Strength!-Experiment

In a fascinating experiment, researchers at the Cleveland Clinic Foundation discovered that a muscle can be strengthened just by thinking about exercising it.
For 12 weeks (five minutes a day, five days per week) a team of 30 healthy young adults imagined either using the muscle of their little finger or of their elbow flexor. Dr. Vinoth Ranganathan and his team asked the participants to think as strongly as they could about moving the muscle being tested, to make the imaginary movement as real as they could.

Compared to a control group – that did no imaginary exercises and showed no strength gains – the little-finger group increased their pinky muscle strength by 35%. The other group increased elbow strength by 13.4%.

What's more, brain scans taken after the study showed greater and more focused activity in the prefrontal cortex than before. The researchers said strength gains were due to improvements in the brain's ability to signal muscle. ( Society for Neuroscience, Annual Meeting, November 11, 2001 )


This might explain why form over function is so important in weight lifting.  Form is about getting the correct muscles to fire at the best time in the function of moving the weight from A to B via a path that is most likely not a straight line. Making sure your are firing the right muscles is the job of the brain - the mind controls the brain and it is the mind that imagines, predicts, and sees the future desired state.

Does this relate to other types of activities?  Could we receive a 35% increase in effectiveness just by disciplined practice of proper form in a thought experiment, rather than an actual experience.   I think we could see benefit in this way.  

Friday, May 25, 2012

The 21st century definition of TEST

What is the difference between a test and an experiment?


I propose that in the 21st century and the realm of software development that these definitions must morph to our needs.  There is little difference in the general definition. Yet many people in quality control or quality assurance departments appear to dislike the word experiment.   Defining actions a person takes to perform a 'test-case' as an experiment appears to rankle feathers.   I find this interesting.

Test - (verb) take measures to check the quality, performance, or reliability of (something), esp. before putting it into widespread use or practice.

Experiment - (verb) perform a scientific procedure, esp. in a laboratory, to determine something.
I would like to define that within the modern software world that the word test have a more specific meaning.  I propose:
Test - (verb) a highly repeatable measure to check the quality, performance or reliability of (something), esp. before (something) is created and then put into use or practice.
This definition would distinguish testing from experimenting within the domain of software engineering.  First, it separates testing from experimenting by the aspect of 'highly repeatable' measures.  In todays world of software development if we are not using the power of computers to make our measurements repeatable (which computers happen to be extremely good at) then we are not using the exponential leverage of our own industry.

Second, it suggest that a distinguishing feature of a test is that it can and should be conceived before the thing being tested is created. Well this is just good scientific practice in the first place.  One creates an experiment with a belief they know what will happen and the open mind to experiment and measure the actual results (true or false).  Therefore one must have a hypothesis first.  It may be proven false - at which point the scientist has learned something very valuable.  This aspect of experiment is understood in scientific circles; but in the software industry it needs to be explicitly stated.

These additional aspects of the definition of test when used within the software industry would imply that we could distinguish between a person running the software under development and seeing if the system had the expected behavior via an experiment (probe - sense - respond; Cynefin (video) Complex topology) versus a test in which the person executed a highly repeatable measure to check if the previously predicted behavior actually happened (sense - categorize - respond; Cynefin Simple topology).

Expanding our understanding of the terms we use within a technical field is part and parcel of our industry.  This is the Ubiquous Language activity of the Domain-Driven Design practice.


Thursday, May 17, 2012

7 Aspects of a GREAT Impediment Sticky

A typical impediment sticky
annotating the blocked task.
Just making an impediment list is not good enough.  Yes, it is a start.  But only the start.  Raising impediments at the daily stand-up meeting shows that a team is mature enough to recognize that all problems are better solved in the light of day.  Problems are easier to solve when more than one person is working on the issue.  One of the first steps to getting multiple people working on an impediment is to make it known to the team.

Yet this is the start, not the end of the process.  Yes many newbie teams believe that the Scrum Master's job is to resolve these impediments.  That is a wonderful misconception and will work for a while as the newbie team learns the power of an agile mindset.  But only the maturing teams learn that it is their job to remove these impediments.

So what are 7 aspects on a great impediment card living on the top of your impediment list?
  1. Title - this should be a short pithy phrase; not a dissertation title.
  2. Description - a few sentences that anyone reading the card will get context to the problem, and be interested enough to ask questions.
  3. Who - a name of the person effected by the impediment (should be the person raising it - but OK, if not include both - it is an indication that growth is needed).
  4. Date - the timestamp for the start of the resolution tracking.  If Impediments are resolved in a day then this field may be wasteful - in fact most of this info is waste.  Yet, I'm betting if you are read this far, you have the typical problem of impediments are stale and rarely resolved.  That's why you need the date!
  5. Shepherd - the person who will see this impediment through to resolution
  6. Current status - not a one word status - but a description of the progress, possible workarounds.  This is a log of the resolution process.
  7. Resolution date - a time stampe for the end.  The status above should indicate the resolution.

This is a list of aspects of a great impediment.  If your impediments are not being resolved and you have more that a handful (one for each finger) then you should treat them as more permeant citizens of your task board.   Make the life of the impediment visible.  I'm not going to discuss the resolution process, we'll save that for another day.  But with just this basic data you could start to track the cost of not resolving your impediments.  

Estimate in story points or task hours the amount of effort that would be reduced if the impediment were resolved per day.  Then apply that cost to the impediments life span.  Do this for a few dozen impediments and you may have a wonderful info-graphic to take to your leadership.

Most of the leader's that I've worked with say they understand the impediment resolution process, and why it is important.  Many also say no one ever tells them about the problems.  They say they are willing to help.  Few have trained themselves to go ask, or to question the teams.  Great scrum takes discipline, even at the leadership level.


See Also:
Top Ten Organizational Impediments - by Vodde and LarmanFive Tips of Impediment Resolution - by Stefan Roock



Friday, April 20, 2012

Video of The Marshmallow Challenge at Agile Games 2012

Agile Games 2012 conference in Cambridge.

"The Marshmallow Challenge is a remarkably fun and instructive design exercise that encourages teams to experience simple but profound lessons in collaboration, innovation and creativity."


David presenting the challenge at Agile Games conference.


Watch Tom Wujec's TED.com talk about his many experiences with this exercise.

 Agile Games 2013!



See Also:  Results Oriented Web conference Marshmallow Challenge workshop

Don't mistake the Marshmallow Challenge with the Marshmallow Test by Walter Mischel.  One is a design challenge - the other is an experiment designed to see if personality traits such as self-control are malleable.

Sunday, April 15, 2012

Product Owner Scrum Immersion Workshop

Pictures from a recent Product Owner Scrum Immersion workshop.
Agenda for Scrum Immersion workshop

Here are some Panoramas of the simulated sprints (also see photosynths).






what do you want to get out of a Scrum adoption by the team?

Scrum Immersion simulation roadmap
What we learned at the Global Sales Conference


Clients - Wish list (that's not a backlog)

Management "launches" a new team

Project plan - simulation of 2 product releases

What is Agile Release Planning
Release Planning - a simulation
Product Backlog (has Size & ranked for business value delivery)


Sprint Planning (the What & the How)


Sprint 1 - Bootstrap team's capacity to forecast unknown velocity


A schematic of a 5 min. Simulated Sprint

15 sec. for a simulated Stand-up meeting

The prime directive - DO IT!

5 min. for Simulation Sprint review meetings

2 sprints then Release 1 - demo with Customer feedback


the Rock Stars sprint scorecard

Release 2 - demo to customer - builds upon R1 and feedback

the Mavericks scorecard

Once you start then you can really gather data - but
you have to start first - just do it!

Two teams sprinting on the product backlog.