LIVE: Agile Testing Days 2013 - Day 1

After a Brilliant Day of full day tutorials yesterday (sorry - busy presenting, will blog on that later) This morning, the first FULL day of the conference begins with a lively breakfast conversation with Matt Heuser, Mohinder Khosla, Lisa Crispin followed by Lean Coffee.

And We're Off!

We've divided into two groups - which given the numbers involved is a very good idea!

First topic for the group I'm sitting in is is "Teaching Soft Skills to Nerds."  Challenging - Lisa suggests avoiding the "touchy feelly" stuff - possibly with relation to "interpersonal" instead of other terms?

Great question - "Why do we hire nerds without soft skills in the first place?"  Consensus - we're looking for technical skills and sacrifice something.  Since we tend to sacrifice one thing for another, this is the result.  (OK, I missed a bunch of the conversation - not firing on all cylinders yet? need more coffee!)

Next topic: Why have test managers in an Agile environment?  If testers are "all in" and part of the team, why DO we need test managers?

There are skills they may have, not addressable in a "whole team" environment - when the "team" consists of 7 people, this looks and acts completely differently than when the "team" is70 people.  Some organizations use the term "manager" to mean "orchestrator" - where they are helping to coach people and build their skills in an environment where these personal development considerations are maybe not fully represented.  Same issues apply to test and development.  A good manager can make sure that skills are resident in the larger organization, even if they are not on EVERY team, if someone has a mix of certain skills, they may be able to engage on /their/ team - and sometimes be a support person for other teams when they need their help.

Next topic: A Continuation of this?  (Actually the group "moved on" but the topic is similar to the previous and I could not actually hear what it was...)  Note - it is REALLY WARM in here!  Whoa!

Managers can help bridge cross-departmental challenges - e.g., environments and sandboxes and make sure people have what they need.  (Huge point!)  Once comment - an interesting one - at some organizations, because teams have different needs, people can be migrated from one location to another.  As they are needed in one project, people can be moved as effort/workload allows and is needed.  THis is a really interesting idea.

One aspect that was raised - small companies have such a different dynamic than large companies, that things like office space, cubicle size, workspace location (windows, etc.,) the question is how to balance the politics.

OK - frankly - there is too much happening to record reasonably well.  They folks have interesting ideas - by the time I get 1 thing types, they've thrown another one out and I miss it.  this isn't doing justice - BUT - I think it gives an idea, no?

Like this - the point is not being important or the title on business card or whatever because you are a manager - the point is how can you serve the team BECAUSE you are a manager?   One important aspect is to nurture more novice testers - both technical skills and softer, communication/people skills.  A manager needs to nurture their staff to make things happen well. It is up to the manager to help people grow by getting juniors aware of ideas and skills to learn/look into, and it is up to the jr testers to actually do the work to learn.

** OK - I blew it by not charging my laptop overnight and my half-charged batter from yesterday's workshop is now flat-lining.  MUST FIND POWER!

**

First Keynote of the conference - Andrea Tomasini - Agile Testing IS Testing.  Right.  Interesting.  I tend to agree with the title - That may not be a welcome attitude - BUT - There are certain things that many experienced testers would agree with,  among them is that blind adherence to locked process models will not result in good testing.  You'll get a fair amount of /checking/ (see Bolton's checking vs testing work) but fine little testing.

He makes an interesting point right out the gate - What matters more is the QUESTION - sometimes the answer matters, but the question is what generates thought.  Excellent point!!!  (Waves to @jbrains / J.B.Rainsberger).

Interesting demonstration - How many cars pass a line projected across a video of traffic on a highway.  Figuring things out is the easy part, unless it s hard.  For example - How many cars cross a certain point in 10 seconds.  Go.... Ummm, both directions.  Cars not vans or trucks.

Sound familiar?

Clients want problems solved - not a proxy for solving the problem.  We need to consider if the assumption made is validated by an increment of the activity or not.  How can we learn /together/ what is needed if we don't communicate around that.  Building trust is required to that communication happening. 

Testing is not about validating  that people did their job.  It is about examining what was done and considering that against the customers desires.  looking into the product is looking into assumptions around the application.  (OK - I'm editing this heavily as I'm writing.  The testers are not part of the team? Sounds far more lock-step / SDLC/waterfall than Agile - so I'm ignoring those references.

We are looking for fast feedback, but sometimes the results can take longer to receive, etc., The description given is around "luck" - as in try something once and it seems to work - and you stop.  Yet without proper investigation, the result is misleading.

We must build a culture of trust which requires a reduction in social risk for the product team.  People not trained in how "whole team" process models function will have great reluctance in diving in whole hog when it is the opposite of what their experiences have been.

The challenge is to examine costs and business risks - the relationship between them.  If we can validate ideas in an incremental way, short feedback loops - blah - blah - OK - So far there is not much in the way of "new ideas" here.

The promised "controversy" has not yet appeared.  Wait - hold on - Best Practices were cited - in that sometimes they don't work.

Creating a vision with Stakeholders - ok - promise there - Discussing collaboration with customers - often starts with /testing/ - mostly of ideas.  For example - if we have an idea - it may be a great idea - but if no one wants to buy the product that results from that idea - it is just an idea.  If we act on that and sink loads of money, time and effort into something - we could easily be wasting time and building a bunch of stuff that will gather dust.

OK - I can live with that.

The idea of "user stories" gives context and content.  They can be a declaration of intent and interest.  This is something a customer wants.  This needs to be considered and defined - this takes work to define what it is that people want / need.

Sorry.  I'm not representing this well.  Much stuff being asserted.  Commitments can not be compelled to achieve success.

Classic Scrum stuff being described.  OK, but not quite what I expected in this talk.(OK - that was an editorial comment - still...)

Moved on to Lean - and how Lean got very distorted in the version often presented in the US.  Little to disagree with here - in a manufacturing model.  When people don't understand the reasons for things, the result will be lower quality.  However - that is fairly normal.  Over burdening is bad.  Normalized flow is good.  Unnecessary variation is bad.  Wasteful activity is bad.

Stuff that looks like work, but does not contribute to the overall effort may be a good idea.  However, from project to project - sprint to sprint - the context changes.  The change in context may be give results that one does not expect in the process model (whatever that may be.)

I recognize that some of these ideas are potentially new to some people here.  Having said that, it seems a very compressed set of ideas being glanced over instead of a limited number of ideas dealt with in depth.  Many conference speakers attempt to put out EVERYTHING THEY KNOW in one presentation.  I've done it - and learned from the feedback.

There may be ideas of value - but they are lost in the noise.

==

Track Session - Sami Söderblom - Flying Under the Radar - How Conventional Testing Was Secretly Turned into Sapient Testing."  Right - fresh coffee - and in a track session with a promising abstract.  G R Stepehenson described how corporate (or anyy) culture develops over time.  Essentially, something happens that is BAD. People see what happens - and association doing whatever happened just before the BAD thing and link the two.  To avoid BAD things, don't do that one thing.

Simple.

Unless they have no relationship to each other OR - there is no true association between them.  Cites Thinking Fast and Slow - Real effort requires thinking. 

Classic example (well, to me) of a requirement that is "testable" or not.  The question is "what does this mean? In what context is this a requirement?  Does this requirement make sense for that context?"

Invokes Mindmaps as tools to evaluate software - and thinking in general.  And to track progress in testing - testing sessions, session charters and session reports.  OK - I like that.  (Question - how many people in here are familiar with session based testing?)

I'm really liking Sami's presentation style after the the keynote - relaxed - laid back - staying on task and describing what he did - nice - comfortable style.  Some folks may be missing context though (like the guy next to me.)

Citing Hendrickson's Explore It! "Explore with to discover ".  The objective is the INFORMATION - not a coloured button. This is crucial - I hope it is understood by people in the room.  The fact that I agree with him may be impacting my perception.

OK - interesting slides on info-graphics.  He flashes up a weibull distribution diagram - a common display/model for project management.  He then flashed up a coloured bar chart - asked if it meant anything... people said "SURE!" except he made graphs based on the characters of the Simpsons.  Really? Do they mean anything?

Without understanding what the intent is, without understanding what is meant - simply taking information at face value is a problem, and dangerous.

And then Prezi blows up the machine running the presentation when he tries to open a linked video.  Oops.  Bummer.

He recovers with an important point: To be successful, remove the obstacles to success,  Simple, no?  What if you do not see those obstacles as obstacles?  Are they "important and needed tools" that are standard to your context or environment?  So what? What if they do not add value RIGHT THEN - get rid of them.  They may have value another time, but if they do not this time - drop it. 

If they are obstacles to your THINKING - they are not needed and are harmful!!!!!!!!!!!

===

Talk 2 - Tony Bruce on Be a Real Team Member -

Starts out with some interesting questions - like... What makes a real team member?  Asks for people's ideas on that - and gets reasonable answers - open, shares information, contributes openly, etc.,

According to Belbin's study - team work is a model where people assume a role in the team that supports the team (in some way.)  The roles may be action, people or thought oriented roles. These are reasonable - BUT - there may be things missing.  (He promises to revisit this in a bit.)

AND the SECOND Prezi take down of the day!  Well done, Tony!

Are PMs "shapers" or what?  If a Shaper is one who drives forward the ideas that will enable success - who (or what) is the kind of person that is?  Steve Jobs, perhaps?

While walking through various types of roles (rather - personalities?)  Tony makes an important observation in an off-hand manner.  "People can be good in these roles/functions sometimes - in different contexts these can help or hinder."  You need to know which one is which - and when.

BING!  Off hand comment on models - IMPORTANT FOR EVERYONE! "Take what you can use and leave the rest." Some things will be of value sometimes - other times they will not.  Learn to recognize what is going on.

Communication/respect techniques discussed.  The question of how people interact - including the balance for individual worth is crucial.   discussed the problems people encounter - or inflict - based on biases, behaviors, etc.,

Interesting ideas - a bit fast to record fairly.

OK - This room is stinking hot.  Sweat is streaming down - wow.

===

Lunch time -

===

OK - Food eaten! Costume (for the party this evening) Fitted!  Slide deck finished/updated!

NOW!  Mary Gorman presenting on Interdependency for Agile Testing.

I met Mary two days ago and had a lovely conversation with her over dinner - remarkably bright.  She starts with a horror story from a previous project where a vendor (the one that was needed for people to get their work done) went dark - as far as developers, etc., were concerned.  They simply stopped communicating with them - bad news...

OK - So - with some definitions and differentiation around dependence and interdependence.

When you work together - supporting each other, is that dependent or interdependent?  Is your work related?  So, Mary is describing comprehensive interdependence - where activities are dependent on each other - and on each of the individuals doing the actions/activities (yeah, there is a difference...)

Discusses Thomson's work describing interdependence as "the degree members interact with, and rely on each other, to accomplish their work" - this is fairly important.  However - most people fail to appreciate this OR resist the opportunity - (pete note: maybe a control thing???)

Interdependence is linked inexorably to trust.  The two of them must be tied together for any measure of (commonly identified) success.

Types of trust ...

Contractual  - Clear expectations/meet commitments.
DO you meet the commitments and expectations of the people you are interdependent with?
What about the other way around?
Really?


Communication - Trust of disclosure... WHo knows what & when? Is feedback present? Are you and the "other" open to it? Is it direct and constructive?


Competence  - Trust of Capability - people don't trust each other person/team's competence / ability.  What about Respect?

Right -

So communication is dependent on Trust - to make that WORK though we must "shed light without generating heat."  (Cool graphic of structured conversation)

We explore ideas - which leads to value & evaluation - which in turn yields to confirmation.  The trick is these must be done openly - bi-directionally - so each thing is understood. (pete comment)

In testing, we need to discover & deliver cyclically.  each round gives us another path to consider.  We have internal interdependencies between the "user" or tester) and actions which impact users which... ok - you get it.

--

Running out to set up my workshop....

---

Wednesday Morning -
Right - following up on this.  My session was a 2 hour workshop, a roundtable on problem solving.  As with similar exercises, we went through a list of problems people are dealing with/encountering at work, described them, then presented ideas to consider to address the one that was voted (dot vote by the participants).  The "solutions" portion was the most complex part of the the discussion.

There was a swirling of ideas and suggestions that shifted over an hour of discussion.

By the time the "grid" was introduced, there seemed to be some solid ideas on what could be done to address the problem described.  (Look for more on this in a later blog post - I'll add a link when I get it finished.)

It took a fair amount of time to tear down the room, and by the time I had gathered up my materials, I had missed a fair amount of the closing keynote for the day.

===

Ajay Balamrugadas' notes form the same day: http://t.co/UhgZujVwcr

Conferring at Agile Testing Days or Sharing Ideas to Find Solutions

Later this month at Agile Testing Days in Potsdam, Germany.  I'll be collaborating with Matt Heusser on a full-day tutorial on Exploratory Testing practices and how they can be applied to speed information from testing to stakeholders.  Frankly, I'm looking forward to that.  This is going to be really good. 

Matt gave a good explanation of what we're doing, and why, in the video linked above.  In short, we'll be talking on how you can give fast and informative feedback to the people who care (and matter) on projects.  Yeah, I know we're talking about this at Agile Testing Days.  The thing is, these approaches can work, and have worked at shops Matt and I have worked in, no matter what the development methodology in use is. 

The next day I'll be conducting a two hour workshop we're calling a "Tester Round Table".  The idea is testers meet and talk about problems they are facing or dealing with right now. 

This is something similar to a SWOT analysis (what ever cool cred I have just took a significant hot by referencing that) where people talk about what the problems they have, what possible things they can do about them, what steps they might need to take to fix these issues and who, or what roles) they need to get on board and gain support from to make this work. 

Simple, no? 

We ran a similar exercise as an evening/extra activity at CAST.  One thing I learned, or re-learned, is that some things will not be able to be fixed from the grass-roots level.  If you are the only one who sees a problem, maybe that is, in itself, the problem?  Are you not understanding the context of the organization or the mission?  Excellent point for introspection.

Other folks participating at CAST came away with suggestions to try at their company.  These generally work by introducing them in a small way.  Going in with trumpets and slogans and big "motivational pitches" and "kick-off celebrations" and "bright! shiney! NEW!" ways of doing things tend to get rejected as "cool process du-jour.

The goal at CAST, and at ATD, is to present the model so people can take it back to their company and try it with their team or a subset of the team. 

Why do I think there is value in this? 

Simple.  I've seen it work.

I'm not much into the philosophical considerations around varied and sundry aspects of software and software testing.  I'm concerned with getting problems addressed and corrected, and getting good software out the door so people can do their jobs better. 

This works.

Another example of this was presented recently. 

At my local tester meetup, GRTesters (Grand Rapids Testers) we ran this same exercise for the August meeting.  The results were interesting.  Three folks from a single company showed up and presented an interesting problem.  After voting, that problem was selected as the one to work on.  We discussed aspects around it, including the roadblocks and how to deal with them.  It was a really good conversation.  (Checkout the notes here.)

The September meeting, the same guys from the same company came back and excitedly reported they took the ideas from the meeting, presented them to their management who were convinced enough to try it.  The notes from the September meetup read:

We start with a follow-up from last month.  The group that was having the issues we talked through last month - have actually ACTED on the discussion and are seeing improvements.  Coolness!

They were seeing positive change in less than a month! 

Can it work?  Absolutely.  Maybe not that quickly for you, but it does work when people are open to communication and understanding. 

If you are going to Agile Testing Days, please check these two things out.  They are going to be pretty cool.  If yo are considering going to Agile Testing Days, just do it.  Sign up and go.  Tell the Boss you NEED to go.  Get the boss to go!

This is going to be good.

I Am A Software Tester

What I Do

I test software.

I learn how the software behaves and report on it.

I do not break software.

I exercise software and look to address the questions of stakeholders around how the software works.

I consider formal "Requirements Documents" to be information points for my investigation, nothing more.

When the software is being developed or modified, I look to the reason why it is being developed or modified, not merely how.

I look for the need the software is intended to fill and the wish the software is intended to address.

I look for the value people wish and hope the software to bring.

When the value and business purpose, as stated by the stakeholders and sponsors of the effort, is not being achieved I stand up and say so.

When the "Documented Requirements" are not in alignment with the value and business purpose, as stated by the stakeholders and sponsors of the effort, I stand up and say so.

I say these things openly, in public, not in a closed room.

I look to see how I can contribute to the effort beyond exercising software.

I look to see how I can support the BAs in representing the wishes and desires of the stakeholders and sponsors of the effort,the customers on whose behalf we are working.

I evaluate and exercise stated requirements and search out those that are presumed.

I look to see how I can support the designers and developers in clarifying what is meant when documents are unclear.

I evaluate and exercise designs.

I try hard to smooth the effort and move work without sudden jerks, fits and starts.

I try to build consensus in the team over the behavior of the software and how it relates to the stated intention and purpose.

I try to speak for the customer when no one else does so.

I do not assure anything.

I challenge assurances.

I challenge assumptions.

I challenge presumptions.

I challenge the status quo.

I challenge my role on the project.

If I can not add value on a project in any way, I say so and withdraw when that is the best thing from the project, the group and the larger organization.

I help raise people up.

I help colleagues see what is possible, not merely what is now.

I help them be better at their craft when they express a desire to be better.

I strive to become better at my own craft and work to learn more.

I am not a master; I am an apprentice constantly learning my trade.

If people look to me for assistance, I will give it if it is in my power to assist them.

If people do not want assistance, I do not impose my assistance on them.

I try to make things better.

I try to make software better.

I try to make communication better.

I try to make myself better.

I think.

I am a software tester.

Observations from Test Leadership Camp, part 2: Defining Leadership

Test Leadership Camp was held the Thursday after CAST in Madison, Wisconsin.  These are my own thoughts based on notes, recollections and tweets made during the day.  I'll be writing up thoughts and recollections from this in several posts.  This is the second.  The first is here: http://bit.ly/1aXfJrY .

A less energetic, and perhaps more thoughtful, conversation at Test Leadership Camp which I participated in was one focused on defining leadership and test leadership in particular.  It may seem odd to have a session on "what is leadership" at a function ON leadership, however, with an eye to "define what we are about" this session was intended to frame future discussion and help the participants wrestling with how to express fundamental ideas. 

In no particular order, things I know were mentioned:  Gerry Weinberg's "Becoming a Technical Leader"  ; Matt Heusser's observation that "If you think you are a leader, every once in a while look over your shoulder.  If no one is following you are just some guy going for a walk;"  behavioral characteristics of what we'd expect in a leader; being a "leader" does not mean one is always a thought leader.

Lesson 1?  Too many people conflate "leader" and "manager."  For purposes of our discussion, the focus was on Leaders - not Managers.   

After much discussion, we landed on a fairly simple definition for a leader.  A Leader is one who influences others, who them want to follow (the leader.)  This seems almost obvious.  Except remember that some times, folks may not want to think about themselves as leaders.  They may simply see themselves as, themselves.  This is part of the conflation of Leader and Manager.  This is worth deeper thought.  (and not part of the discussion, which is the point of this post.)

One path we DID go down, was the idea of an unintentional leader.  They are doing their thing and - SHAZAM!  People are talking about them as if they are leaders.  The thing is, they are going somewhere and others seem to think that may be a good place to go as well - so they follow.  Whether they wish to be leaders or not, they are one.

This brought us to the idea of Authority and Leaders / Leadership.  In some instances, the authority is positional - it comes with their job.  For other folks, the authority comes not from their position, but from their experience.  When you have seen stuff, experienced stuff, and been around the block a couple of times you can, possibly, anticipate options and formulate possible paths based on those things - those experiences.  This gives them a different perspective from people working from theory and case studies.  In some contexts, this tends to lend a certain weight to their ideas and opinions. 

Two really straight-forward ideas.  The first was Leaders need to know themselves and be honest with themselves.  Leaders, in all forms, need to be aware of their own weaknesses and be honest about them.  In doing so, they must also learn from their mistakes.  Related to that, they must be open to learning from others.  

The second was one I've blatantly lifted from my lady-wife, Connie.  She comments on people being trustworthy "when their words and actions match."  Part of that also implies an honesty with each other (tied to the above point, of course.)  Having said that, the trust factor of the leader will go up when the people around that leader recognize that honesty. 

One important point was a simple warning - test (or any technical) leaders may not be "thought" leaders.  One thing interesting is that people may be sharing other people's ideas with their company or team, like, ideas they picked up from a conference, and make it clear they are not their ideas.  Still, for the company, they are "thought leaders."  Reporting other people's ideas may be a form of thought leadership in some form.  (Having said that, from my own experience, its a little uncomfortable for people to slap labels on you when the ideas are not yours and are still "cool things to look into more.")

Lesson 2?  The signs and traits of Leaders apply to more than Test Leaders.  These tend to apply to many forms of technical leaders.

Observations from Test Leadership Camp, part 1: Best Practices

Test Leadership Camp was held the Thursday after CAST in Madison, Wisconsin.  These are my own thoughts based on notes, recollections and tweets made during the day.  I'll be writing up thoughts and recollections from this in several posts.  This is the first.

Overall, I found the discussions and the ideas exchanged engaging and informative.  The drawback was it was impossible to be in all of them at once.  The first discussion I was in (with a floating group of participants involved) was around concepts of "Context Driven Testing." Right out the gate in the conversation was "There are good practices in context, but there are no best practices."  The short-hand version most folks use turns into "No Best Practices."

No "Best Practices"

What does this mean?  James Bach, Cem Kaner, Brett Pettichord and others have written on the topic at length.  Let us consider where the ideas behind CDT came from.  Generally, and this is my perception, they were a reaction to a mix of bad practices, untenable approaches to testing with much overhead and little to no value and, as more than one person describes it "Snake Oil."

A cornerstone of the "Snake Oil" approach is to rely on "best practices."  In testing, these tend to be something that worked well, by some measure, in some project at some point, somewhere in the past - either the company's or the individual's.

A heated part of the conversation was around what was meant by rejecting "best practices" in testing.  We settled on a phrase from Paul Holland - rejecting "best practices" means we "do not blindly follow process" models.  Simply because something, a practice, a technique, whatever, worked on a project once before, attempting to apply the same on another should be considered carefully before adopting or repeating the practice, even if it is for the same company, the same team and on the same software product. 

This actually is more than reasonable.  In my own experience, talking with test managers - the line managers supervising testers - they "get it" fairly quickly, if they are open to discussion.  If they are so tied up with other aspects of "Administeria" they are likely to reject any idea that does not originate from upper management.  This tends to be found in companies with several layers of management.

For smaller organizations, I find this tends to be less of a problem.  It may still be present, but there are fewer layers of pointy-haired bosses to deal with.

The challenge, as I see it and from experience, is getting the point of Context Driven Testing beyond the line manager and into upper levels of management.  The first stumbling block is the idea of "no best practices".

Here's what I mean.

Best Practices and Management

The idea of "no Best Practices" for managers with backgrounds other than technology is that it seems counter-intuitive.  They come from backgrounds where "Accepted Practices" are considered normal.  Anyone ever work under a big boss, a manager of managers, who was an accountant?  The idea of "Generally Accepted Accounting Practices" is ... pretty normal.  The concept of "Best Practices" seems a continuation of that.

Other times, people like to sound smart.  They want to be among the "cool kids" so will adopt their terms, buzzwords, and sometimes, bad habits.  If they use the "best practice" thing, and we walk in and tell them they are wrong, and all the stuff they've been talking about doesn't is smoke and mirrors - how well does that work?  Consider the Jesuits who went to Japan in the late 1500's.  How well did THAT work?

Even if they KNOW it is smoke and mirrors, they are unlikely to admit it to their own employees, particularly when they work several removes away from them.  They may admit it grudgingly to consultants, but there is little certainty that ONE person coming in contradicting the many others will make a dent.

One observation that came to me some time ago.  If you can't have a conversation with your boss's boss on something you are passionate about, or even on something you like and maybe they like as well, how are you going to get them to consider alternatives to what they have been told is a real thing?

Note - if you are working for a small company, like fewer than 50 people, and you can't discuss the differences between types of coffee with a CxO/President type, and you are both getting coffee from the pot in the break room, do you really want to work there?  (Don't ask how I learned that heuristic.)

Consider this - The CEO - the nemesis of many tech folks, is a human being.  They are remarkably similar to you in many ways.  They have their strengths and weaknesses and foibles and fears and... yeah,  Same thing with the CIO or any other CxO type person - or VPs or Directors of Whatever.  If you can't have a conversation on something you have in common, like coffee or tea or beer or music or something how do you intend to talk with them about this idea of "best practices"? 

The question is, can we reasonably and logically make a case, without causing offense, that refutes the notion of a simple solution that is "tried and true" without considering other options?  The challenge is to present the path that explains the fallacy of embracing practices simply because they worked, by some measure, in some other context, when other practices and techniques may prove of greater worth.

On Management or The Hole In My Bucket Problem

A second blog post written originally in long hand while camping at the Wheatland Music Festival.  The first one is here.

September 7, 2013

The idea behind "empowered" workers, staff, whatever, is a fantastic one.  It sends us off dealing with problems left and right.  We slay giants, send dragons to their doom and overcome all sorts of obstacles.  This model works amazingly well, until we run into a situation where it doesn't work and we need the support of a boss-type to knock a hole in the wall or find us a bigger ladder or help dig the tunnel under it so we can get on with what we are supposed to be doing.

Managers are good at that sort of thing, usually.  I had one manager several years ago who laughed at me once saying "Walen, can't you, just once, bring me an easy problem?"  My response was, "I don't need help with the easy problems.  I can deal with those.  When the problem is another manager, I need someone with at least as much stuff on his collar as he does to deal with it." (He was a retired Army officer, such references carried a certain weight with him.)

Usually, he'd deal with it.  Sometimes, he'd propose a solution I had not considered.  I'm not certain, but I suspect I contributed to him deciding to retire.  (If you're reading this - "Hi Gay!  How's things?  That M47 still looks pretty impressive.")

Then I've had other managers who were closer to the pointy-haired boss type from Dilbert.  The ones who apparently have no idea what their staff does, nor any appreciation for the complexities of the problems they are describing and need help with.  The result sometimes is "help" that is no help at all.

An Example.

Maybe you've heard the joke about a fellow walking through a field and observes (astutely) a hot air balloon roughly 100 feet above the field.  A fellow in the balloon's basket calls down to him "Can you tell me where I am?"

Being a very accurate observer, the fellow walking through the field calls back "Yes. You are in a balloon approximately 100 feet above the ground, 25 feet ahead and slightly to my left.  You are over a fallow field with tree's roughly 300 yards ahead of you, relative to me and 50 yards to the right, relative to me." 

The fellow in the basket calls down, annoyed "You must work in IT!  You have given me very detailed information, none of which helps me at all! Thanks for wasting my time!"

The fellow on the ground calls back "You must be a manager, probably in upper management.  You got yourself into this situation and now its my fault!"

And What Prompted This

These things came to my mind listening to some folks playing music in or campsite last night (Friday).  One fellow was a guy I used to play in a traditional/folk band with.  We used to play a mix of Irish and Scottish songs and traditional tunes.  He was playing guitar and singing with his sister, doing a bit their parents did when they were kids.

Maybe you've heard the some "There's a Hole In My Bucket?"  Where a fellow says to "Liza" "There's a hole in my bucket."  She very helpfully says "Well, fix it."  He does not know how (hence the problem.)  Which in turn Liza says "With some Straw, dear Henry" (the names sometimes change, but you get the idea.)

Well, poor Henry needs more guidance, "But the straw is too long."  "Then Cut it!"  Well, Henry does not know what to do about cutting so Liza suggests a knife.  The knife is not sharp enough to cut the straw, so sharpen it on a stone.  Except the sharpening stone needs to be wet to effectively sharpen the stone.  So get some water to wet it with and then sharpen the knife to cut the straw to mend the hole in the bucket.

Which leads Henry to respond "With what shall I fetch it (the water)?"  Liza serenely (more likely very frustrated by now) says "the bucket!"  

Which brings us back to "There's a Hole in the bucket, dear Liza, dear Liza.  There's a hole in the bucket, dear Liza, a hole."

As a children's song, its rather funny.  Henry is obviously clueless.  So Liza needs to explain everything to him. Except maybe he's tried these ideas and is still stuck. 

How many times have managers and leads and seniors leapt to a conclusion on how to fix a problem without considering the problem from the perspective of Henry.  The "obvious" solution may be not so obvious after all, when you look at all the pieces.

And So, 

Dear Liza, don't write off the problem before you understand Henry's frustration and his perception of the problem.

Managers and leads - Please take the time to hear what your people are really saying when the words sometimes fail them.  They will appreciate you more and you won't look and sound like Dilbert's pointy-haired boss.

On Leading, Managing and Sense of Purpose

This post was originally written longhand (as in by hand, in a bound journal, pen on paper) while sitting at a campsite at a traditional music festival.  Sometimes I go places where electricity is not needed and internet access seems inappropriate.  It helps to defocus sometimes over an extended period of time.

September 6, 2013

Sitting under a canopy at a campsite at the Wheatland Music Festival may seem an odd place to consider Leadership and Management. There are similarities between the two, which is partly why the terms are conflated so often.  The similarities and differences are being demonstrated all around me this afternoon.

One group, behind me, is discussing "setting limits on how much" soft drink, beer, whatever (not sure what exactly, other than the excited voices on the topic) can be had; how much per person per day to be sure each person gets their "fair share."  The primary concern seems to be on running out today, Friday, and not having enough to last through the weekend.

Another group, across the fire lane from us arrived at about the same time as the group behind us.  They set up their camp, set up tables and set out coolers and got out their instruments and began playing music.  Very good music.  They have been doing so for well over an hour.  About the length of time the first group has been discussing "limits" and "fair share."

The second group is more about what the Festival represents than the first.  They collectively and individually know what they are about and why they are there.  Granted, there could be a difference in age, maturity or something. 

Of the two groups, one appears to be mostly in their mid-20's, roughly 24-27 or so (I can't see them very well without being obvious.)  The other group. the one playing music, is predominantly in their early 30s.  (I took the direct approach and asked how long they had been playing and if they played together as a band and got their musical life story.) Age does not seem to be a major factor - a few years perhaps.

Maturity may be part of it.  Still, when the music stops, they tell much the same types of jokes and demonstrate the same style of humor as the other group has, off and on.  Frankly, when they are not playing music they remind me and my wife of, in her words, "puppies playing."  A bit of romping, a little rough housing, all in good fun careful to not hurt anyone.

Still, when one of them starts a tune, the others launch into it with fervor.  Their  this weekend seems to be to play music, meet people and have a good time.

The other group?  I'm not sure what their purpose is.  They seem to not know what their purpose is either.  They have, after well over an hour, agreed on a lot of rules, but I'm not sure if they have agreed on why they are there. 

They have defined a process model for something and agreed on how to manage the process model.  After some 90 minutes, they do not yet seem to have agreed on what purpose the process model is to serve.

They do not yet seem to have agreed on a reason for the process model to exist. 

Perhaps that is the difference.  One group has a shared purpose - a sense of why they are there.  "Leadership" of that group changes hands whenever someone starts a tune.  The other group?  They are managing their group but failing at leading it.

NOTE - Sunday morning, it became apparent that the non-musical group was a collection of people, parents and grown children and friends of each generation.  This made clear some of the phrases that came up over and over.  It should also be noted there is a shuttle bus that runs from the festival grounds to the nearest town with grocery stores, beer, wine and liquor stores and the like, every 30 minutes.  "Running Out" did not need to be a disaster, merely an inconvenience.  Their purpose seems to have been to have a good time.  I do not know if they succeeded.