Friday, June 24, 2011

Be or Be Not; there is no Do in Agile

Why do we practice this thing we call Agile?  Is it for the results it provides? 

I've been working with companies and people that use the "A" word in many different ways.  Sometime the word is used as if it were a method of working.
"We are doing Agile on this project, but the team has 34% story carry over each iteration."
Sometimes it is used as a bludgeon to beat someone not behaving as one would like them to behave.
Sales:  "I'd like you to work on this severity one bug, it just came in and the customer while not really blocked is considering a purchase of our SuperWidget and if you just sneak this in today they will be really happy."  
Team Member:  "Sorry, talk to the PO we have sprint commitments." 
Sales:  "Well, that's not very Agile!"  
While at other times it is a promised land, a utopia of project management where we all live in harmony.  Many times it is used as a technique to achieve some other purpose, a differentiator that will achieve some other objective.  Objectives such as speed to market, doubling revenue in five years, raising quality while lowering cost, there are many other business objectives for "installing the agile".

I am not surprise when department managers say their groups are doing Agile.  I typically bit my tongue and run through this test in my head.

  • Show me your teams interacting with each other, the customers, and product owner more than they are working with the tools, process, etc.  
  • Individuals and interactions over processes and tools
  • Great you must have working software, show me your last iteration demo on the staging server, now.  
  • Working software over comprehensive documentation
  • Which one of these people is the customer?  
  • Customer collaboration over contract negotiation
  • What feed back did the customer give in the last month or two that cause you to deliver higher value than initially planned?  
  • Responding to change over following a plan

Is there just one process way to do these things?  No.  There are thousands of ways to do these things.

Those things are the definition of Agile.  Agile is not a method, it is a way of being.  It is a synergy of many things we do, and many things we do not do.  It is in the decision we make and it is mostly in the underlying reasons - why - we make those decisions.

One could do Scrum or XP, those are processes (or frameworks or techniques) - but one cannot do Agile.  However, one could be Agile.  Agility is a path, either you are on it, or off it - there is no Agile destination.

Yoda teaching young Skywalker "Do or do not, there is no try."

But why should one attempt to be Agile?  Answering this question is getting to the core purpose.  It is not about all the outcomes that might result in a group or organization being Agile.  If being Agile is the goal, then we are surely going to disappoint someone.  Perhaps ourselves, perhaps our customers. Customers don't want us to responded to their change request - they want products that met their discovered needs (true needs) with the ability to sustain the continual deliver of meeting their needs in the future.

Simon Sinek TED Talk: How great leaders inspire action

I think we must be Agile for our selves.  Then align our values of being Agile within the context of the purpose of the organization we choose to work with.  If this alignment is too difficult, the friction too high, options exist.  Explore those options.

Wednesday, June 22, 2011

Scrum cartoons and fictional stories - a list.

If you enjoy the classic pig and chicken joke that Ken likes to tell, then you will enjoy the Implementing Scrum Cartoons.

There must be 100 of them, so if you want to illustrate a Scrum dysfunction, there is probably a cartoon for you.

If your cartoon taste are a bit retro - try SCRUM NOIR: A Silo to Hell! My review at Amazon:

In a dark and wet city that never sleeps Ace is confronted with the constant techniques that appear to work in delivering software; "work", that is if appearing busy and always having a competing department to blame for missing milestones on the project plan that no one ever thought was possible is your managers definition of WORK.

So how does one change the mindset of leaders and workers? How does one show that collaboration and measuring visible working software (and tested functionality) is a better way of managing projects?

Why does the format of a graphic novel work so well for this common type of moral play? Well one answer is that we have all seen these personalities and behaviors on the project teams we've work with. Another is the media (comic strip) allows us to empathize and place our selves into the story line - to connect with the story and the actors. [ Answer: an aside: see Understanding Comics: The Invisible Art, by Scott McCloud ]

This comic novel will make you cry with delight that you are not the only software developer that is pained by the crazy systems of dysfunction we have all allowed to become the industry we love to hate. It also may point the way out - for the brave and courageous.

[Disclaimer - I worked with most of those actors in Scrum Noir, in a steamy city that knows how to keep it's secretes.]

The next series in the Scrum Noir - Mad Dog Mary.

When Ace's new client walks into his office and says, “Her back’s against the wall,” and that she wants to, “hit them back,” Ace gets excited because there is nothing like commitment to change from someone who's fighting for her life. That, and she's really upset and he's afraid to say no. He takes the job and meets the product owner, Mary. When he learns why she's nicknamed 'Mad Dog' he considers that maybe working in last episode's siloed organization wasn't so bad.

Or try Enabling Agility's Comics.

I'm sure there are other's out there - let me know - tweet me a link @davidakoontz I'd like to add them to the list.

Here's a cartoon about the 10:00 AM Scrum on the Enterprise.

Atlassian (maker's of Jira, etc.) have a few short videos of the world's worst Agile Coach Chet Rong.

Are you doing it the Rong™ way?

"Meet Chet Rong™, the world's worst agile coach. He's got a lot to say, but his ideas are highly suspect. If your team is doing things the Rong™ Way, you'd better scrum in the other direction. Fast."

The Rong™ Way to do Agile: Team Structure (0:54)  "If the team gets to be too large, just get rid of QA!"

See Also:

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

Monday, June 20, 2011

I should have patented the design

MacWorld just ran an article with this new iPad telephoto lens adapter.

The Super Gear Telescope 6x Zoom For Apple iPad 2. 

I knew I should have patented my earlier design.

I’ve been taking all my pictures with this new lens and camera combination for the iPhone.  The image quality is great from edge to edge and the telephoto zoom allows image reach from Illahee, WA to Ketchikan, AK.

iDuct Systems EF mounting hardware

The Canon 100 - 400 F IS zoom lens is mounted to the iPhone with iDuct Systems custom hardware ($8.97 at Ace Hardware).
Canon 100-400mm f/4.5-5.6L IS
L-series super telephoto zoom lens equipped with an Image Stabilizer. The fluorite and Super UD-glass elements largely eliminate secondary spectrum. The floating system also ensures high picture quality at all focal lengths. The Image Stabilizer has two modes and it is compatible with Extenders 1.4x II and 2x II.

Update:  You could pay $250 for an expensive solution.

The iPhone 4 SLR Mount at the Photojojo Store!

Sunday, June 19, 2011

What Agile tools are you using? 13 tools to use.

There are all levels of software development tools.  From project management tools to source control tools, and all manner of in-between tools.  Many new teams starting out want a quick list of the tools they should use.  This is a cheat.  They want a quick fix to their existing problems.  Here's a clue - it is hard work that fixes your problems.  No tool is going to solve your underlying problem.

Chances are that your problem is not technical at all.  Changes are that your problem is a human caused problem.  You are not working together, not collaborating.  Adding a tool will just mask the root cause.  But most management will purchase such a tool if it has some good smoke and mirrow hand wavy justification.

My first recommendation is to use your brain.  Then use your hands.  Make your problems visible.  Draw them on a white board, or a flip chart or an A3 sheet of paper (11x17 for you Americans).  Yes use your spreadsheet to track trends and make graphs, but when the canned graphic routine doesn't draw trend lines, print it and use a pencil.

Because you click to see a list of tools here's a small list of tools you may find useful.  Please help me add to the list - use the comment field below.

Innovation Games - the book and the online site has 12+ games to create delighted customers via games that get work done.  Instant Play Games

Many teams use Dot Voting as a means of reaching consensus.  Try the online site to pre-arrange a vote and run a round of consensus making via a distribute online tool.

The artistic person will wish to summarize a feature and one way to do that is to make a word cloud of the requirements document.  Try Wordle an online word cloud tool.  Or try Tagxedo - allows uploading shape files.

"You never develop code without version control, why do you develop your database without it?" The tag line for LiquidBase a database version control tool.

Need a distributed team to work with story cards and a cork board for visualizing the relative effort of each story - try

A similar tool used to create a story map is CardMapping site, see the usage of mapping stories article.

Basecamp is a project management system desing for online collaboration.  It is integrated with 37Signals other online suite of tools.

Many Agile team's use timeboxes - for this one needs a timer: is one option as well as

When distributed team's wish to know if the team members in the USA are awake - try What Time is it There?

A classic white board diagramming and collaboration tool:  Cacoo.

Want to see if your documentation is truly readable (understandable) - try this site: Tests Document Readability.

See Also:
List of Collaboration Tools
8 reasons to buy an iPad for your Team room

Agile Games 2016 - Best Conference ... yet ...

Update May 2016 - and it's still the best learning conference I've every been to - ever!

Agile Games 2016

I presented - a game using Tangrams to Cultivate Collaboration.

And the first ever - Mob Programming conference.

-- Way Back Machine -- Original post....

A great Agile Games 2011 conference! Watch the video and count the number of times that you see interaction and collaboration versus the number of times you see traditional telling method of knowledge transfer.  If you happen to see a gorilla then you may be watching the wrong video.

Agile Games 2011

Agile Games Conference 2011 Promo from Lollie Videography on Vimeo.

This was in Cambridge, MA April, 14 - 16, 2011.

Be sure to save April 19th - 21st, 2012 for next year's Agile Games conference.

Saturday, June 18, 2011

Great idea - great execution - but don't patent - think public domain.

Here is a great heart warming story.  A group of Girl Scouts invent a prosthetic hand.  The device cost about $10 to make.  And somewhere in the process they are encouraged to patent the invention.  Why not donate the invention to the public domain?

Should the Girl Scout leaders have encouraged the group to look beyond the typical process of patent.  Think about the values of the Girl Scouts.

The Girl Scout Law

I will do my best to be:
honest and fair,
friendly and helpful,
considerate and caring,
courageous and strong, and
responsible for what I say and do,
and to
respect myself and others,
respect authority,
use resources wisely,
make the world a better place, and
be a sister to every Girl Scout.

Imagine if "The Man Who Saved the Children", Virologist, JONAS SALK had patented his invention.  The polio vaccine.

We have the best tools - why do we not use them?

See Also:  13 Agile Tools to Use.

I was observing a Scrum daily stand-up for a new team the other day - here is one observation I had.  At the end of the stand-up the Scrum Master asked the team who was going to update the burndown chart today.  One team member stepped forward and started adding up task estimates (in his head) and then drew the bar on the chart (paper on the wall) representing the daily estimated work remaining on this sprint.  We talked briefly about the shape of the graph (classic downhill ski jump shape) and last sprints graph (similar shape) and what that implied.  There was no big discussion about if the data was truly represented in the information - because they all understood the derivation of the chart information, they had created the information (the chart).

This is a great break through for this team - because of the status quo in the organization.  It is not until you know 'The rest of the story' that the new behaviors become so awesome in my view.

... the rest of the story
The organization is heavily reliant on using a big name tool for tracking the agile teams and creating charts.  Yes, this well known tool is on many list of agile tool sets (another list of agile tools).  Yet, it is not well liked by the people.  There are questions as to weather it is just plan wrong in the information it is creating (burndown charts). Or if the tool is being used inappropriately (problem exist between keyboard and chair - PEBKAC).  These charts are not trusted by the teams and thought leaders at the organization.  The agile coaches have even created an excel spreadsheet and manually extract data from the agile management tool to plug into the spreadsheet thereby creating better charts and graphs.

"The Sprint Burndown Chart is a valuable tool for team self-management. Excessive management attention to team self-management artifacts will lead to finger-pointing and “looking good for the boss,” impeding the candid interaction among team members necessary for hyper-productivity."
-- Michael James, An Agile Approach to Measurements

Since the teams and leaders do not trust the tool, and have created another layer of tool abstraction, the teams do not really feel responsible for the information being presented.  It is just some numbers (a lot of numbers) in a spreadsheet that someone created, that is telling us something, but what do we do about it?  "I don't know what to do, I'm sure they will tell us."

In my opinion, the problem's root cause is that the team has been dis-empowered by removing them from the responsibility of managing them selves.  It is their responsibility to decide if they are going to get to Done on the sprint.  It is not the responsibility of some tool to report to someone else this information.  And then result in that someone else directing the team in how to correct the inadequate burndown rate.

This team has accepted their responsibility.  They own the task of tracking.  They have modified the tracking tool they are using to give them better information (note graph paper above, and plan paper last sprint) over time (inspect & adapt - learning).  Now that they have a deep understanding of the information, they may be able to draw conclusions that lead to changes in behaviors that improve the shape of their graphs, and allow them to project if the sprint will get to done early and with confidence.

If there is no confidence in the information - wouldn't that mean the use of the tool to produce the information is WASTE.  Oh - that Lean thinking will get me in so much trouble - or - perhaps the status quo will change.

See Also:
A Burndown chart that radiates progress

Why Paper is the Real Killer App - BBC

Thursday, June 16, 2011

Agile: organization, movement, or philosophy?

I referred to Agile today as a philosophy in a conversation with other Agile coaches.  I got a little push back.  So it made me think - is that the right word for the thing that has resulted from the Agile Manifesto

No.  I may want it to be a philosophy, and it may be my personal philosophy.  But it is not a philosophy that is recognized by the general population.  Nor even a philosophy as recognized by the IT industry nor software developers.

It is a movement.  Or is it a method of working?  I'm not sure - what's the difference? I believe that Scrum is a method of working, while I believe that Agile is greater than just being Scrum-y, or turning all the dials to 11 (XP).

However, if Agile were to marry Lean, then I think the union would have a great shot at becoming a philosophy.

So in my philosophy I try to marry the two movements and I think it makes for a philosophy.  One that has the capability to evolve via Double Loop Learning.  A philosophy should be capable of challenging it's own truth and modifying the goal to know the truth.  So in the manifesto the goal is to develop working software, along with all the necessary stuff like teams, and server farms required to deliver the software.  But is that the truth?  Is that the value stream result?  No. 

The ultimate goal of working software is to delight customers.  It is delighted customers that purchase the software.  Software has no real value until a customer chooses to purchase it or the device the software is embedded within.  Like the DVD player that really needs a better UX (no delighted customer here - no recommendation for that DVD player to my twitter friends).  A case in point is the eco-system that Apple has created with the iOS devices and the App Store.  Billions of dollars have not changed hands because of lists of acceptance criteria that have been met for thousands of feature sets.  Oh-no, it is because delighted customers have raved at the local watering hole that this app is awesome.

So if your company is looking to Agile to increase speed to market, or to double revenue in 5 years, or to increase quality while decreasing cost - then you are missing the movement.  And you will not make your transformation to Agile stick.

To make that Agile Transformation stick into the DNA of your organization you will have to promote the movement to a philosophy within your organization.  Then and only then will the movement (transformation) become capable of surviving the inevitable change of leadership and staff that will snuff out a movement.

My quest is to find the techniques that transform a movement into a philosophy.  But I need help.

Organization vs. movement vs. philosophy

An organization uses structure and resources and power to make things happen. Organizations hire people, issue policies, buy things, erect buildings, earn market share and get things done. Your company is probably an organization.
A movement has an emotional heart. A movement might use an organization, but it can replace systems and people if they disappear. Movements are more likely to cause widespread change, and they require leaders, not managers. The internet, it turns out, is a movement, and every time someone tries to own it, they fail.
A philosophy can survive things that might wipe out a movement and that would decimate an organization. A philosophy can skip a generation or two. It is often interpreted, and is more likely to break into autonomous groups, to morph and split and then reunite. Industrialism was a philosophy.
The trouble kicks in when you think you have one and you actually have the other.


Humans resist changes - empirical evidence shows

Key frequency infographic
The ability of humans to make a change is very limited.  Even when we know the change is going to be for the best.  Even when we know the current method of working is based on a flawed understanding of our needs.  We resist changes.
A case in point.  The common keyboard.  It is laid out in a some what random pattern of letters.  Yes it looks like your grandfather's keyboard, so you instantly recognize it.  But ask a 7 year old to describe the keyboard and you will see that there is no obvious logic to it's design.  You of course know that the design was purposeful.  It was a configuration that put the most used letters/keys away from the  powerful fingers, this was to slow down the best typist.  During the days of the early type writers the keys would jam.
I recently watch a young lady switch the Wii keyboard from QWERTY to a 9-digit telephone keypad, because it was easier.  At least the letters are in a predictable pattern (ABC1, DEF2, etc.).

Innovation in the typewriter took quite a while.  IBM introduced the Selectric ball in 1961.  This among many other innovations removed the need to slow down the typist to reduce key-jamming, however few people changed to the better designed Dvorak keyboard layout (patented in 1936).

Perhaps it is the patent that prevents its adoption.  I keep asking - why does Apple not give the Dvorak keyboard option to the iOS devices.  With their innovation in keyboards (touch screen) the layout is all software, no hardware cost to switching the keyboard layout.

Yet we still teach and use the inferior QWERTY keyboard.  We resist changing to a new system even when it would make our lives easier, more efficient.  I think the keyboard will die a slow - very slow death.  As computer become auditory and visual input devices.  But the new touch screens - a tactical input device will still be around for quite some time.

The rate of change that a complex system can sustain is one of the factors in its ability to survive.  We now live in an epoch where change is exponential.  Humans better learn to keep up.

Wednesday, June 15, 2011

Epochs in the big picture

If you haven't thought about the universe today - now would be a good time.  It may be the only time you really have.  However we tend to measure things, we humans tend to only think in terms of our personal scale.  We measure our lives in birthdays (an unassuming point where a crowded planet completes an almost circular orbit about a yellow star).  But what are the true delineating points in the history of the universe?

One would most certainly have to be the Big Bang!  I mean - come-on, the point at which nothingness turns into somethingness - that's the start of something.  But measuring from that point 13.7 billion years ago, what's the next important event?

  • 13.7 billion years ago:  Big Bang!
  • Just 380,000 years later the atoms of Hyrdogen & Helium start to form.
  • Just 200 million years later stars begin to form.

These are just the first 3 Thresholds of Increasing Complexity (David Christian, Big History Project).  They have happened at the very beginning of time.  Rather quickly on a time line linear scale.  Then for quite a long time 9 - 10 billion years nothing quite so miraculous happened on the complexity increasing threshold event time line.  Until the formation of planets (4.7 billion years ago).  Not long after planets we get Life on Earth (3.8 Billion years ago).  Things are starting to get more interesting.

Interesting things happen at the ends of time.
If we zoom up to the right end of the time line we start to see that complexity increases rather quickly at this end of the scale.  Much like it did at the other end of the time line.  It is the middle that is rather uneventful.

The last 3 thresholds have happened in just the last 100,000 years. Thresholds 6 collective learning, then 7 agriculture, then 8 the modern revolution have just happened.  To compare humans scale to the Epoch scale use the term Stone Age.   We tend to think the Stone Age was a long time ago (2.5 million years).  The Stone Age is the first of the minor epochs used in archaeology, which divides human history into three periods.  It is just a small fraction of time.

The Anthropocene has just started.  A good point in time for that era is when humans started using stored sun energy (oil) to change the environment.  The trend is ever increasing complexity.  While the 2nd law of thermodynamics tells us that the system (universe) should tend toward chaos (higher entropy). What is threshold 9? It should happen any moment now.  Could it be the Ray Kurzweil Singularity event?  The merging of human consciousness with silicon machines.

Friday, June 10, 2011

A Burndown chart that radiates progress

Here is a visual example of a team learning the value of a Scrum Sprint Burndown chart.  To give some context to the images below - the team did a 3 day workshop on Scrum between sprint 1 & sprint 2.  In this workshop we laid down some working agreements, one of which was they would use a physical Scrum task board with several major items.  One item was the burndown chart derived from task hours estimated remaining each day.  This team knew they were under committed for the sprint but wished to get started sprinting (a good choice rather than spend more time in sprint planning with so much uncertainty).  They felt they could get to working on about 5 high priority stories and plan to replan (pull into the sprint more stories) later in the week.  They assumed that learning about the uncertainty was better than crystal ball gazing.

The team started with 64 units (estimated task hours) of work.  On the fourth day they decided to bring in more stories with estimated 24 units of work.  Then on the fifth day they agreed to pull in an additional 34 units of work.  This is their original burndown for the sprint.

 What does this burndown tell us?  It tells us that the team is not going to finish the sprint.  It is only when one stops to read the fine print (the annotations) that one may gleam that there is more to the picture than is being visualized.  Asking the team what they could do to make this chart "tell the whole truth", they decided to redraw the burndown.

Now this 2nd generation chart is telling a more complete story.  It shows that on day four the team recognized it was finishing the committed work very early (as assumed - and then proven by tracking).  So they pulled in some work on that day from the prioritized backlog.  They were dealing with stories that had dependencies (not quite at the INVEST model standard - yet).  But by doing work on the dependent stories the understanding of the team was growing.  They pulled in 24 units of work (drawn below the zero datum on day 4).  The very next day the team was in a similar position and pulled in an additional 34 units of work (units were derived from task estimates - not story points).  The additional 34 units are drawn below the 24 datum line (at -58).

Will we get to DONE?

On day 8 the very quick progress slowed.  This was not evident in the low fidelity charts and some team members were debating about the proper location of the top of day 8s bar on the graph.  The solution to this "impediment" is to use graph paper.  This allows for a more precise view and projection.  Projecting the trend is the purpose of the burndown chart.  We want to answer the question:  Will we get to DONE?

At sprint 2 - I am much less concerned with the team getting all the work pulled in to the sprint Done, and much more concerned that they learn to use the tools and techniques that allow them to become self-managing.  Next sprint they will have a better idea of the amount of work they can accomplish in a sprint (velocity).  And if they have taken time to groom their backlog this sprint, next sprint's planning meeting will go much more smoothly.  They may be able to fully plan the sprint and not need to pull in stories ad-hoc.

It is all part of learning to use the Scrum tools and techniques.  Learning is exciting!

See Also:  We have the best tools - why do we not use them?

Tuesday, June 7, 2011

One on One Coaching tool for iPhone

How much do you coach someone via simple one-on-one conversation?  Is that conversation an active listening conversation?  Is there an App for that?

Why yes, there is the Talk-o-Meter.

Imagine if we had one of these Apps for pair-programming.  It would be a Type-o-Meter.  Hooked into the pair programming work station to measure the key strokes of each of the two keyboards.  Hey, that sounds like a great idea.

Saturday, June 4, 2011

I'm a Single Track guy

Do you believe you are more productive because you think you can multitask?  Studies show you are wrong.  Why do we believe we can; why do we think we are super-special and have powers above the average?  Answer: (pay attention) cognitive bias - attentional bias.

Media multitaskers pay mental price, Stanford study shows

"People who are regularly bombarded with several streams of electronic information do not pay attention, control their memory or switch from one job to another as well as those who prefer to complete one task at a time, a group of Stanford researchers has found."

I think I will lower my personal kanban work-in-process limit to ONE.  There really is only one (Highlander - then there was the sequel).

Just last week, coaching a new team with their Scrum task board we had a conversation on the number of tasks a person could be working on at one time.  The reason given for the four tasks in process on the big visible scrum task board was that getting up from their desk to select the next task sticky was a nuisance.  The tasks were estimated at 1 - 3 hours each, and two tasks were still in process the next day.  Changing peoples perceptions of efficiency is a slow process of exposing incorrect mental models that are reinforced by cognitive bias.

Hello, wake up people, do not try to be a computer.  That day will come, as we approach the Singularity, when humans transcend biology.
In Ray Kurzweil's book The Singularity Is Near, he examines the next step in this inexorable evolutionary process: the union of human and machine, in which the knowledge and skills embedded in our brains will be combined with the vastly greater capacity, speed, and knowledge-sharing ability of our own creations.

That merging is the essence of the Singularity, an era in which our intelligence will become increasingly nonbiological and trillions of times more powerful than it is today—the dawning of a new civilization that will enable us to transcend our biological limitations and amplify our creativity. In this new world, there will be no clear distinction between human and machine, real reality and virtual reality. We will be able to assume different bodies and take on a range of personae at will. In practical terms, human aging and illness will be reversed; pollution will be stopped; world hunger and poverty will be solved. Nanotechnology will make it possible to create virtually any physical product using inexpensive information processes and will ultimately turn even death into a soluble problem.

Stanford study: Stanford Study on Multi-Tasking