On Brevity and Simplicity and Lean

There is much talk, discussion and debate over Lean - everything.  What does Lean look like?  What is "just enough" and "just in time" of anything?

I'm writing this the evening of 19 November.  It marks the 150th Anniversary of the Consecration of the National Cemetery at Gettysburgh, Pennsylvania.  The battle at the same town was fought in July of 1863.  At the time of the dedication an consecration ceremony, the dead who died in that three day blood letting were being transferred from the shallow, battlefield graves, dug where they fell, to the new cemetery near the existing cemetery along what became known as "Cemetery Ridge".  That was the site of the climax of the battle - Pickett's Charge.

Along with the dead Federal soldiers being disinterred and reburied, there were thousands of horses and other animals that died on the field that still needed to be dealt with.  Many of the Confederate dead were buried in mass graves.  Many are still there.

The ceremony included bands playing, a chorus singing and an address.  The Gettysburg Address was 13,607 words and took roughly two hours to deliver.  It was a stirring work of oratory that was considered a masterpiece by all who heard it.  The speaker was Edward Everett, a pastor, educator, diplomat and at one time a member of the US House of Representatives and the US Senate.   He was a master of his craft. 

At the end of this stirring epic, the President gave "a few appropriate remarks."  He spoke for around two minutes, speaking 270 words. 

Four score and seven years ago our fathers brought forth on this continent a new nation, conceived in liberty, and dedicated to the proposition that all men are created equal.

Now we are engaged in a great civil war, testing whether that nation, or any nation so conceived and so dedicated, can long endure. We are met on a great battlefield of that war. We have come to dedicate a portion of that field, as a final resting place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this.

But, in a larger sense, we can not dedicate, we can not consecrate, we can not hallow this ground. The brave men, living and dead, who struggled here, have consecrated it, far above our poor power to add or detract. The world will little note, nor long remember what we say here, but it can never forget what they did here. It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced. It is rather for us to be here dedicated to the great task remaining before us—that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion—that we here highly resolve that these dead shall not have died in vain—that this nation, under God, shall have a new birth of freedom—and that government of the people, by the people, for the people, shall not perish from the earth.

In this, the political process kicked in.  Newspapers that leaned toward Republican sentiments sang the praises of Mr. Lincoln.  Those that leaned toward Democratic sentiments slammed Mr. Lincoln and his sentiments.

Simplicity wins.  Precision overwhelms artifice. 

Agile Testing Days 2013: Tester Roundtable Workshop

At Agile Testing Days in Potsdam, I ran a workshop Tuesday afternoon demonstrating an approach to solving problems.  These may range across a variety of types of problems, but all of them are problems that are bothering people now.  I had run similar exercises before at conferences (most recently at CAST this past August), user groups (like at GR Testers earlier in August) and as an exercise for test organizations in companies.

Considering problems.

The real purpose at conferences is not so much to find solutions as it is to demonstrate the process so the participants can take the exercise back to their day-jobs and try it there.

The format is simple. Each participant describes problems or pain points they are dealing with; they are written down; participants vote on the problem they are most interested in discussing; when there is a single item selected, that is the one discussed.

And we're off...

We begin by describing the selected problem in greater depth, including what is the impact, what possible contributing factors may be involved and other aspects around it.

The list of problems. 

Voting!

The list of pain points and concerns were fairly extensive.  That there were people contributing more than one certainly helped with this.  After a brief summary of the problems, we began voting.  The consensus of the voting landed on the Potential 2^nd/3^rd Order Ignorance.  The explanation of this was that instead of "knowing there are things we don’t know," people don’t know there might be things that are not known.

Describe the problem. In explaining the situation, the participant whose problem it was walked  through a series of steps, including Deliberate Discovery of problems and the Accidental Discovery of the same problems.  (He had been in Dan North's tutorial the day before and this helped him frame the problem nicely.)  The difference seems to be the level of ignorance of stakeholders and the problems to be discovered. 

Discussing the Selected Problem

 The question at the root is, how can the people who will be impacted by problems not found in testing be made to recognize there may be a problem in the software that is, as yet, undetected?  The real issue is how can we help stakeholders understand the risks of not recognizing there may be problems lurking?

Describing the problem is extremely challenging and can be a problem for many people.  Without being able to do this, we will have an even greater challenge to sort out the problems in making software better.  

In describing the problem, several things became clear.  There are a number of references available for consideration that may give people food for thought for addressing this and similar issues. 

Consider, Nicholas Taleb’s Black Swan (this was mentioned in Matt Heusser’s keynote Wednesday afternoon.)  Looking at this from a slightly different angle, particularly on thinking and thought processes, 6 Thinking Hats gives help in considering how people think.  This can help form what we do and how we approach problems. 

Consider, in addition, Michael Bolton’s work around Frames and Test Framing.  Start here or simply engage the wonders of Google and try this broader search here.  Additionally, work on Focus/Defocusing approaches may have value in looking to answer the question “What else is going on?”

Define Possible Solutions.  Several ideas came up in the meeting.  

First Option:  Professional Experience/Authority 

The first possible solution drew a significant portion of the time available.   “In my professional opinion there are things we don’t know that we don’t know.”  

This may or may not have mixed results.  The context of the organization, the situation specific to the cause of concerns, may make this extremely difficult.  The real issue here appears to be “How do we get the attention of the stakeholders?”  This will be problematic.  In some companies, and aggressive approach may work.  In others, such an approach may not and could have significant consequences. 

Another option:  Change Expectations.

By demonstrating there are defects in production and defects/bugs found in each sprint, it may be possible to build a case.  Noting that the lack of finding problems does not mean the problems are there is only the beginning.    The question to consider becomes “Based on what we know, as established fact, what else might be going on?”

This brings us to the final stage of the exercise – This gives us the chance to identify, and more importantly put these ideas on paper.  Somehow, putting things on paper (or some other recorded form) in such instances helps us visualize the components we need to consider, if not address. 

Identify the Constraints (or Roadblocks) / Assumptions / Stakeholders / Tasks.  

Where the same item appears in more than one area, you have identified a key point to address.  HOW you address it will need to vary on the specifics.  For this exercise, we found this:

Constraints/Roadblocks                      Assumptions

===================                        =============

Product Owner                                   People want a better product

“Team is ‘OK with it.”

Tasks                                                  Stakeholders

===================                         =============

Retrospectives                                    Product Owner

-          Invite PO (and her boss)             Legal Team

-          Invite Legal                               Head of Channels

-          Invite anyone else who may

       contribute

-          Get the Tech staff to stays 

       after Demo

Final Suggestion for ideas on considering options with problems like this, Jerry Weinberg’s “Are Your Lights On?”

AND - we were out of time.  

Agile Testing Days 2013, Looking Back

Agile Testing Days wrapped up one week ago today.  As I am sitting here in my living room, typing away on my trusty laptop.  How can I summarize what happened over the course of the week?

There were many conversations - many very good conversations.  Chris George, Markus Gaertner, Lisa Crispin, Huib Schoots, Gitte Ottosen, Matt Heusser, Eddy Bruin, Seb Rose, Carlos Ble,  Ajay Balamurugadas, J. B. Rainsberger, Lars Sjödahl, Janet Gregory, George Thomas, Sara Rainsberger, Mary Gorman, Matt Heusser - and the list goes on.

There were a couple of themes that were driven home to me - One: the need for open, clear communication;  Two: Trust.

Without one, the other won't happen.  There needs to be a level of trust between the participants in a project, or, anything - for communication, real communication to happen.  Without that, nothing else seems to work or matter.

The images I have in my mind of Potsdam are of an eclectic city, a variety of building styles.  Friendly people with an interest in others.  The feeling I have is a city with an active, vibrant community. 

There are other things from the conference itself.

The Lean Coffee sessions were excellent ways to start each day.  The energy and interest of the participants helped me get engaged and get ready for the day.  The Lean Beer on Monday was a fun way to wrap the formal sessions and blend into the more relaxed evening entertainment.

Part of me was a little disappointed in the energy - as one might expect, some of the people at Lean Beer were generally more interested in the beer than in the conversation and exchange of ideas.  Still, I thought it was a fun, relaxing exercise.  

Games night - what a fun event.  After the sponsor's reception, "Agile Games" with pizza, beer, learning, ideas and getting to meet people.  I'm not sure how many take-aways people ended the evening with, but most people seemed to find it relaxing as well. 

Thursday, the "Lean Cocktail" event - frankly, I was a little concerned.  What I really enjoyed about it was the chance for people who did not quite want the week to end to get together for another "meet and greet" type event.  This was a good exercise run by Matt Heusser in getting people to share their personal take-aways - the "thing I want to try at the office on Monday."  We also went around sharing about testing books and resources and ideas.

The cool thing - at many conferences, those whose flights head out the day after the conference end often wander about looking rather lost.  This gave a fair number a chance to hang with others, make plans for the evening, dinner and decompress together. 

That was pretty cool.  I liked the idea.  Oh, and the outing we had for dinner grew from 9 to 23.  Which lead to way more conversation over dinner then drinks after - until we headed out to our respective destinations the next morning.

Thank you Diaz-Hilterscheid for organizing an extremely good learning event.

Almost Live! Agile Testing Days 2013 - Day 0 - Tutorials!

Matt Heusser and I presented a full day tutorial on Exploratory Testing for the Monday tutorials at Agile Testing Days.  We had a reasonable number of people - with 8 signed up and a total of 10 in the room.  This was one of the smaller groups we've done this type of workshop with - however, given the number of tutorials at the conference this year, it was a respectable number of participants. 

One of those participants, a very highly regarded tester named Ajay Balamurugadas, made a mind map of his notes and posted them as a blog post here.

This is a fair representation of the days events.  We started with people arranging the room (re-arranging?) for the room to be suitable for the needs of the group.  While we were waiting for people to arrive, we pulled out dice and gradually drew people in with a problem solving, rule determination game.  This is always an interesting process as participants vary in their willingness to engage - some are shy and a little afraid to speak up or ask questions.  Others are a little nervous, possibly concerned about being wrong.  Some think that taking 20 or 30 minutes is too long and a sign of failure.  When I tell them honestly that it took nearly an hour the first time I played it, They don't seem to believe me.

Two lessons from that: people are allowed to make mistakes, if they learn from them; persistence wins.

The next step was to split the participants into two groups.  One group was instructed to define an approach to testing for a given application, a game actually.  Then when the approach was described, they were to script the tests.  The OTHER group was given some instruction around the ideas of quick attacks and other ideas on framing and defining test approaches.  Then both groups were brought together to test the app.  After a given period of time, we looked the results for that exercise - then swapped roles.

In the end both groups went through defining test approaches, then scripting them.  Also, both groups were given some ideas on how to apply various other approaches to testing problems.

One thing Matt and I try and do is to make sure participants get what they hope to by, well, asking what it is they are interested in learning.  We then list these, have participants vote on them, then start down the line.  Agile workshop instruction.

The draw back, for us, is we need to be able to present information on a whole PILE of topics.  We spent much of the balance of the day working through various ideas and how they can be applied.  In the end, we had one more exercise.

We gave one more task - another application - and asked "How would you test this?"  The rule was simple - testing this app would be done, How?  And we turned them loose on it.  No other rules.

What excited me, personally, was how the participants latched onto and tried the ideas we had presented during the day.  That was fantastic.

Following this, we repaired to the Fritze Pub, one of the bars in the conference center/hotel, where we launched into the inaugural Agile Testing Days Lean Beer!  Yeah!  Like Lean Coffee, but in the evening, with BEER!

LeanBeer!

As we wrapped this participants headed out for a couple of outings.  One was a pub tour of Potsdam - This actually sounded fantastic.  Potsdam is an amazing town, a variety of architectures, each reflecting a period in Potsdam's history.  Like I said - pretty cool.

However, I repaired off to a dinner hosted by Diaz and Hilterscheid (the organizers of the conference) for the speakers at the conference.  It was amazing - extremely good food, lovely wine and fantastic conversations.

We wrapped up and headed to the conference center and more networking and more, umm beer.