I once heard that ‘Juggling is more about throwing than it is catching’.  So, that begs the question- are you throwing at least as much as you’re catching?

One of the hardest things to do, as a hands-on ‘doer’ and coach, is to delegate (throw).  In doing so, I’ve violated one of the key learning patterns- failure.  You see, by not throwing back to the teams occasionally (well-intended or not), I’ve prevented them some failures
(opportunities to learn).

Back to the question about how many ‘things’ you may be catching and throwing.  There is good evidence to support the thought that we as humans, pretty much ‘suck’ at multi-tasking.  A study of ‘time spent on task’ by a couple fellas from Harvard Business School revealed that in terms of ‘keeping the plates spinning’, we are at our best, with 2 plates spinning concurrently.  After that, time spent on task starts to fall off dramatically, actually making us less productive.  We need to know when to catch, and when to throw.

Young kids always make the joke- with two objects, throwing them up in the air and catching them, saying “Look- I’m juggling!”  And of course, we placate them and say good job to them, while really saying- “If you aren’t juggling with 3 items or more, you aren’t really juggling.”  (secretly, I’ve always known that the best approaches to most things in life were learned by kindergarten age!)  Who knew that the little guys got it right?

To that end, if I am going to be a really productive, active coach, I need to only have two plates spinning.  1) observing, and 2) responding (no circumstance to that ordering!).   And if I take my own advice from the top- I won’t ‘do’ on the behalf of the team, even if I see failure eminently approaching.  Of course, I could ask some leading questions…that
could be considered a ‘throw’, right?

Throw your teams a bone!

Posted in Agility, Coaching, Culture | Leave a comment

Don’t Get Testy with Me, Bernaise!

My Fellow Qualitarians,

Why is it that testing seems to be the common Achilles’ Heel for many *agile* organizations and teams?  Is it because of a shortage of literature?  A shortage of expertise?  Does it just not make sense?  I think not.

What many organizations set out to do when they decide to ‘go agile’, is speed up the delivery process.  This, in most people’s minds is comprised of two general ideas.

  1. Don’t spend forever creating requirements up front
  2. Develop product as quickly as possible

Wait a minute.  Don’t we still need to test?  Of course we do.  Right?  Isn’t #3 above supposed to be ‘ensure the customer gets what they asked for’?

I presume that QA started as an afterthought.  An afterthought?  How can that be in our software intensive world?  Apps here, Apps there, Apps, Apps Everywhere!  Forgive my Seuss-ism.  Assuming for a moment that you are on the brink of adopting / migrating / transforming or what have you to agile, what would you proactively want to build into your testing practices?  (Don’t worry- this isn’t a Covey rip-off.  I already did that)

1)  Test First, Test Last, Test All The Time, Sir!  Seriously, building your process so that you can get started before code is delivered is key.  So is a constant quality presence. Requirements.  Design.  Build.  Deliver.  No better way to do that, than to Automate First.

2)  Risk-Based Testing Approaches.  Whatever risk means to you, set yourself up to tackle this first.  Complexity.  High-Traffic Pathways.  Money.  Get used to doing a licked-finger in the wind analysis- often.

3)  Put Your Customer Specs On.  If you aren’t looking at things from the perspective of your customer, then you aren’t using the right lens.  Responsiveness.  Intuitiveness.  Flow.  Function.  And yes, Form.  I know what you’re thinking.  Not my job.  Tune in next time for the article, “It’s Everyone’s Job”.

4)  Flex.  Things change, and QA (if we’re being honest) is notorious for being too rigid.  Requirements change.  The customer’s ‘wants’ change.  Technology/Approaches change.  If we don’t flex with it and show value- something else is going to flex.  (Did you get that?)

Thank you, and good night.


Posted in Agility, Culture, Testing, Uncategorized | Leave a comment

Little League

I recently started coaching a little league team.  This is my 3rd year, in part or in whole. And like software projects, it’s funny how you always seem to have some of the same concerns, right at the beginning.

For this baseball league, I have no control over the random seeding of players that I receive.  With that comes a lack of knowledge of skill level, experience, athleticism, or if they even understand the game.  To boot- I get one, 1-hour practice with these guys to prepare for the first game.  Enter the conundrum- where do I start?  How do you eat an elephant?

One bite at a time of course.  But more importantly, where do you start?

Detracting from the baseball metaphor, this is the same as walking into any new engagement or project where I have to ‘be the expert’.  I find that there are common issues and problems with many project teams that are new to agility- but the difference is the symptom to those issues and problems.  Kind of like coming down with a bug, here is my ‘antibiotics salvo’ that I like to use as a catalyst for agile change:

  • Card Wall.  It’s nice to know what work you have to do, right?
  • Daily Scrum.  Talking, face to face.  It’s the new email.
  • Product Owner Enlistment.  If the biz is on our side, who could be against us?

All of this can be done without ever saying the ‘a-word’…

I know- you are dying to know what I did with my hour- right?  Offensively we spent a little time making contact with a swing, and running to (through) first base.  Defensively, we spent time fielding the ball and throwing to first base.  Incidentally, these are the only things that we will have to do in our first game.

Play Ball!

Posted in Agility, Coaching | Leave a comment

Correlation is not Causation

I am continually amazed at the stream of requests that I receive for ‘ROI’ with Agile. NEWS FLASH:  (as immortalized by Admiral Akbar) It’s a trap!

The moment the first number trickles from your lips- you are locked into this rate on return.  No appeals due to environment, team composition, corporate politics, etc.  Stuck. This begs the question, ‘why wouldn’t I qualify a salable ROI number?’  I’ll tell you why. Correlation is not causation.  Rather, just because something happens here, doesn’t mean it is going to happen there.  (A flurry of great 80’s movies flash in my mind- Better Off Dead- If I ski K-2 also, she’ll like me; Can’t Buy Me Love- If I walk, talk, dress, act like the popular crowd, then I’ll be popular; Pretty in Pink- maybe if I don’t hang out with my yuppy friends, she’ll like me; etc).

Another ‘why’, and keep this on the DL as I am about to reveal one of the major secrets of agile:  Agile is about people and relationships. Keep that under your hat.

AGILE IS ABOUT PEOPLE AND RELATIONSHIPS, people!  It’s got nothing, really, to do with software!

Bottom line- if your buddy goes to the gym, runs on the treadmill for 30 minutes a day- and loses weight, do you expect if you model his workout, that you will have the exact same results?  I hope not…  If your online team ‘goes agile’ and delivers 50% faster, then you shouldn’t expect your infrastructure team to suddenly become 50% faster if they ‘go agile’ as well- but I bet they will get something beneficial out of it!  Why the difference? Because people are an intangible set of variables and Agility is merely a tool to better understand that.

There’s a difference between knowing the path and walking the path.

Posted in Agility, Culture, Uncategorized | Leave a comment

Coaching, Geese, Term Papers- Oh My!

A mainstream service and buzzword that has surfaced in the agile world is the concept of Agile Coaching. You might think to yourself- why would I need a coach, specifically for agile? Or, coaches are for sports, not‘business’. Contrary to those thoughts, I think about Professional Football. NFL teams don’t have a stated number of coaches that they can have on staff- and the number does vary by team. Last year, the average NFL team had an amazing 18 coaches on staff. (Even I, a heavy-hearted Packers Fan, was shocked by this.) These coaches have the background, experience, and training to look at very specific areas of execution, while allowing the entire team to function, as a whole.

Coaching in and of itself, is defined: to give instruction or advice. Within that definition, a few things are inferred. First, the ability to Instruct- one must have the ability to act in a teaching capacity, relating concepts and ideas in a manner that is digestible to the target audience (individual, team, or teams). Secondly, inferred is the ability to advise- or consult with your audience best practices, approaches, and methods, based on knowledge and or experience, from specific to team-wide areas of execution.

When is a good time for a team to engage a coach? Any time! Seriously, a coach can be a great asset to the team(s) or organization as your spin up agile methods, to guide you along the way, or for a 2 year veteran team that is looking to make further strides. Studies show that most agile teams implement a series of agile methods or practices, reap the rewards over time for that, and without any further ‘spiking of the punch’, fall into a performance gap.

Another time that is a good indicator that a coach could be helpful- low morale. I personally think that teams undervalue the concept of ‘cheerleading’, or celebrating your successes. (It’s why geese honk! The lead goose in the vee is doing the hardest work, while the rest of the geese tuck in behind and honk, as if to say, “go! go! go!” And of course, they trade off who is in the lead position, as a whole team effort.) A coach can help you identify your ‘done wells’, and your ‘can do betters’ with a fresh set of eyes, exemplifying the ‘term paper effect’ (you re-read your paper 20 times and think it’s perfect- and then some chump looks at it and finds 4 spelling errors in 15 seconds). This influence can help you further develop your agile culture, and hurdle the next performance gap.

Keep honking, my friends.

Posted in Agility, Coaching, Culture | Leave a comment

Change is Hard- and Agile Ain’t Easy, Either

Thinking back upon the teams that I have been a part of, the really successful ones- we always went through what is called “Schneider’s Classic Change Curve”. You know the one, kind of like ‘Forming, Storming, Norming, Performing’…

It starts ‘on the up’, with High Expectations. You know- “oh cool, we’re going to try something…”

Then, expectations aren’t met. Ultimately, there is realization that some effort will be required to pull out of this downward dive.  Next, you hit the period of despair- at this point, folks are either building a rescue vessel, or are lining up their deck chairs.  And, if you are fortunate enough to be a part of the rescue vessel group, you get to see the light at the end of the tunnel (and yes, you are on the path to change for the better!) Congrats.

But how do we get here, and why? And why can’t we just take the easy path to get there?

The best way to relate to, and answer this, is the butterfly. Consider this: a butterfly starts as a little egg. He breaks out of his (or her to be fair!) egg as a little caterpillar. The caterpillar grows and grows, and ultimately starts to build the cocoon (or chrysalis, depending on the type) around itself, and starts the process of morphing into a butterfly. The cocoon bakes for a bit, until the butterfly is ready to emerge. Slowly, painfully, the butterfly works and works to make a little hole in the cocoon. Ultimately, through straining and pulling, the miracle occurs. All of this has to occur for the entire process to be successful.

Let’s then consider- if you are walking down a garden path and you see said cocoon. And you see that it is close to opening, and you decide to pull your pocketknife out and make a few nicks to weaken the cocoon, you know, just help the little guy out. What happens? It dies. Surely. The process is the process, in order for it to build the strength to survive. It just is. Like change. The process just is- for better or for worse. No shortcuts.

Bringing this back to Agile. So, the next time you realize that you are ‘working your way out of a cocoon’, acknowledge that moment. Understand what got you into that position. Take the moment in. And, be thankful that you are just a few days or weeks from a Retrospective, rather than another 4, 5, or 16 months from a ‘Project Post-Mortem’ (really? How macabre!) session. And of course, you don’t necessarily have to wait until the Retrospective to start talking about it…surely you are just a matter of a few hours from a standup where you can broach the subject, right?

Hopefully this wasn’t too abstract or touchy-feely for you all. I’ve just had a few bits of inspiration along this (garden) path this past week, with questions around teams making changes, and when they are going to ‘get there’.

Posted in Agility, Culture | Leave a comment

Agile Applied

I used to build houses in Mexico for a charitable organization. I have done 15 of these trips, having played the role as ‘grunt’ on the first 8 or so, team lead on 3 or 4, and construction lead on a few. A typical trip usually goes something like this:

  • Meet at 5:00 a.m. and drive to an IHOP in San Diego, just a stone’s throw from the border crossing.
  • Eat, use the ‘facilities’ for the last time until Sunday, and gather as a group to receive our ‘Mexican Insurance’.
  • Cross the border, drop our overnight gear at a hacienda, and head to the worksite, by noon or so.
  • Organize the materials, start the frame of the house, and call it a day by 4:00 or so.
  • Saturday Morning, up at 5:00, eat, and travel to the worksite by 8:00.
  • Finish the framing, siding, and structure of the roof and outhouse by 4:00 or so, and head back to camp for dinner.
  • Sunday, repeat of Saturday morning- stay until painted, dry-walled, and completed. Head to In n’ Out Burger in Palermo.

On my first trip as a construction co-lead (13th trip?), I pulled my other lead, Tom, aside. I told him about this idea of blocking out the work into disparate chunks, having the group of 16-20 volunteers (secretaries, stay-at-home moms, software engineers, 1 or 2 tradesmen, pastors, and salesmen- many “first timers”) naturally form into groups that had some energy, and allowing them to pick their direction. He thought I was a little nuts at first, probably more because he was a command and control tradesman, with his own construction oriented business- and that’s how stuff gets done! After some prodding, and convincing that we are probably no better off anyway, he agreed. Long story short, we ran it passed the team at breakfast- and everyone was ‘in’.

Tune in next week for the results.  Just kidding.

When we got to the worksite, the teams were already formed. People just started ‘doing stuff’. It was amazing. We took breaks every two hours, verified what direction everyone was operating in, and kept the pedal down. We reviewed at the end of the day Friday, retrospected around a campfire Friday night, and planned for the next day. Saturday, we kept the same pattern- AND FINISHED, at about 4:15. In all my trips, no team had everfinished on Saturday. Now, do you want to know the really fun part about this? There was a team working right next to us, with teams of people that had done this once before. On Friday, as our 4th wall was going up, they were taping a plotted Gantt chart to the side of a shack that was on their build lot. Just saying… Of course we helped them

Remember, as Keanu Reeves last attempt to motivate his team in “The Replacements”- “Pain heals, chicks dig scars, and Glory lasts forever.”

Take a chance on evangelizing Agile today- and look fondly upon the results!Scrum ain’t easy. Neither is sitting on the Mexico side of the border crossing on a Sunday night. You choose.

Posted in Agility, Culture | Leave a comment

Filling Spaces

When did good enough become ‘enough’?  The more clients I work with, and more teams I encounter- the more I think complacency has become the new norm!  Enter Parkinson’s Law.  For those of you not familiar, Parkinson’s law is nothing more than an adage first noted by (surprise!) Cyril Parkinson in 1955.  It has little scientific founding; rather, it is an observation based on experience, and can be correlated to numerous situations and environments.  It goes (for our purposes) a little something like:

Work committed to, tends to fill the time frame allotted.

Now this seems like an axiom that we all could agree with.  I mean, we try not to take on too much work- right?  Consider the outcomes:

  1. We take on just the right amount of work.  Check.
  2. We take on too much work.  We remove some to fit.  Check.
  3. We take on too little work.  We catch up on other stuff, technical debt, etc. (and we try not to let on about it!)

To put a fine point on this, I would offer up 3 thoughts.

First, don’t take your foot off the gas.  It’s called a sprint for a reason.  I often see teams get ‘ahead’ on the burndown, and then relax- only to fail in delivering the full commitment.  And if you are delivering your full commitment, but quality is in question- you may need to reexamine your definition of done to satisfy both the needs of the business, as well as the quality of delivery that you want to represent your team.  Please don’t misinterpret what I am saying here- you do need to consider what is a sustainable pace for your team!

Second, if you are finding yourself in position #3 above, and there is true value to that work (other stuff), shouldn’t someone be lobbying for it in your sprint?  Technical debt should be considered first-class work as well, and you may need to employ a technical product owner (TPO) to represent this to your Product Owner (translation = get it in your backlog!  That whole visibility thing?). If this isn’t happening today, consider bringing it up in your retrospective.  If this is hindering you to a point of inefficiency, consider bringing it up today!  Yes, you can bring up a ‘done well’ or ‘not done well’ in advance of the retro (remember, the retro is simply a tool to create a forum to voice things like this- not a hardened rule that it’s the only place to do this!) J

Lastly, and many of my contemporaries would disagree with me on this point- stretch yourself.  Sometimes you don’t know what you can do until you try.  Kind of like not being able to get better at (insert sport here) until you play a better opponent.  I’m not saying to stuff your sprint to 150%, and I’m not saying to not manage your load along the sprint either.  I am saying that there is value in understanding the potential of your team, as well as understanding the dynamics of the team- and sometimes, stretching provides that perspective.

Search your feelings, you know it to be true.

Posted in Agility, Coaching, Culture | Leave a comment

Personal Responsibility

I recently heard a tale of a complete lack of personal responsibility, that I am a bit ashamed to say, made me chuckle.

At a house next to my folks, there lived an elderly couple.  They had at one point, not so long ago, desired to replace their carpeting.  Like any consumer, they called around, found a seemingly reputable company, and engaged with their services.  A year or so later, one of those nice old folks died.  The other, moved out of the home, and in with one of their children.  The child, acting upon dear old dad’s wishes arranged for the house to be sold.  In doing so, the furniture and ‘stuff’ had to come out, in order to prep for sale.

Did I mention that this nice old couple had a bit of a relic in a console television, that they still used?  Mammoth in size, a piece of furniture in it’s own rite.  Anywho- in moving this behemoth out of the room, an oddity was discovered: a patch of the old carpet!  That’s right, the carpet installers installed new carpet everywhere, except for the patch that this television was sitting on.  Congratulations, new winners of the ‘Not my job’ award.

While you take a moment to regain your composure, consider the fact that lots of us do something similar, every single day.  Kludges, workarounds, band-aids, etc.  It all adds up to technical debt.  We all do it for varying reasons- and there can be some good business reasons (very rarely) for doing something like this.  However, in doing so, you have to take the personal responsibility of:

  • Informing someone else about it- that’s right, a conversation
  • Noting what is required to ‘make it right’
  • Setting a goal of when you are going to make good on it

Anything but this, is simply short-cutting, taking the easy way out, copping out.

In taking the above steps, you might actually uncover a more simple, elegant solution.  Remember, agility is all about causing conversations!

[Update] – Okay, so on my way into work this morning, I see a fender bender on the side of the road.  Still mulling over hitting the ‘publish’ button on this article, I felt my sense of personal responsibility tugging at me- and had to stop.  An ’emotional discussion’ was taking place between the two parties, so I inserted myself.  No altercation, good conversation and relevant information [and a focus on personal well-being] , and all was good, save for that poor Hyundai.

Stay ‘chatty’, my friends.

Posted in Agility, Culture | Leave a comment