Clock Time, Event Time, and Bullet Time

When becoming agile, there are many ways that we start to look inward in order to change how flexible we can be.  We start to think about work differently.  We think about how we collaborate together.  We think about task, story and epic level things.  We also ponder time itself.    Is there a placeholder event for that?  Is this the appropriate time? Is the time-box up? I remember the high school teacher’s frustration at having students look eagerly at the clock – anticipating the moment when the bell would sound the end of class. Ultimately later in the year, the note underneath, which was posted and read “Time will pass.  Will you?”

 Clock Time

There are things that are run by clock time.  In the agile world we set limits on meetings and sprints Many organizations still account for hours. Things that are run by the clock.  It lends a sense of urgency and there is a certain puzzling in order to fit activities and interactions to fit appropriately.  Time does not stop. It marches.  What does change though – is our perception of time.  Some moments whiz by or instead as Shakespeare said slowly drags on and “Creeps in this petty pace from day to day, To the last syllable of recorded time”.  When our days are managed by the clock, I often wonder if this alien and measured arbiter of fate sometimes robs us of an empowered position.  Some teams often measure a sprint burn down with hours remaining (Which I’ve previously talked about here) .

Event Time

When timelines are populated by events they often give us a sense of achievement and better context than Chronos‘ stamp of numbers.  I am looking for a task to complete rather than time to run out.  Choosing achievement over activity and hallmarking instead by the memorable actions which have culminated in a sense of completion.  Sometimes ending a day in a ‘good spot’.  Event time seems to allow for creativity and innovation that spark and motivate just a little more.  Doing something Better than before, not just the same way over and over.  Is event time always better? probably not as with all things there is a balance.  It will Clock time that helps us determine if something ‘unsustainable’. But, again, only because we haven’t achieved the desired events. A Team might measure tasks, not as hours remaining, but rather as events – only wanting to know if they are in progress or done. A retrospective timeline will often be measured in 3 ways – the chronological timeline (1) earmarked with events (2) and our reactions (3).

Bullet Time

The matrix first coined the term, being fluid and moving faster than we thought possible.  Unfortunately it always seems to be during crisis moments.  Whether on a six story drop on an amusement park ride or in front of a release review.  Our brain registers everything and goes into a hyper protective mode.  It’s sometimes hard to remain calm and in a problem solving in a panic driven environment.  At times the uber-urgency brings out some of the best in our teams in an almost Apollo 13 type of way.  There are no lives on the line, but the sense of responsibility doesn’t seem any lessened.  It usually takes longer term investments in teams of people to make critical and good decisions.  To support those teams we invest in infrastructure and technologies.  We let them adopt lightweight processes which enable them to move quickly.  Bullet time is not a sustainable thing. But some of the best days are briefly ventured here, when the team pulls together and works itself out of a crisis.  Even better when the team plans to avoid the same thing from ever happening again and moves back into Clock or Event time.

The Agile Manifesto Pictionary

In 2001 something happened. A document was drafted and called the Agile Manifesto. It is wonderfully simple and requires just a bit of thought-full-ness  in order to consider a favored balance of someone or something OVER something else.    In order to help bring the point across I often draw a small picture of the document that goes something like this…

                                                                                                     The teams seem to remember iagilepictographt much, much better.

Individuals and interactions over processes and tools

My drawing for a person is simple and quick.  a stick figure.  the emphasis is that they share the same thought cloud.
a hammer and a wrench or some gears….  processes and tools were meant to enable people… not fetter them.

Working software over comprehensive documentation

A train made out of 1’s and Zeroes.  = working software.  In the old days we didn’t have enough 1’s to go around.
pieces and stacks of paper

Customer collaboration over contract negotiation

Simple Stick people – but one of the is holding a ‘$’… Just as in a USER buying our software.
Jail.  Locked down and imprisoned by paper that seemed to hold everything we wanted but quickly grew heavy and burdensome.  protecting a prior understanding rather than representing how we work together.

Responding to change over following a plan

A chameleon – and this is how I think of adaptability. Responding to change.  If I have some colored markers I’ll stripe a few bits if rainbow in there. We are teaching teams with an emphasis on problem solving skills.  They must adjust and respond to change, as no situation is ever ideal.
A treasure map.  A plan.  I Love me a plan. – Yet most experienced coaches and veterans will tell you that plans seldom encompass or foresee every detail when in the thick of action.  So you train your team to adapt, adjust, and be problem solvers in order to overcome the things that get in our way and the difficulties along the path.  Buried treasure, by the way, is not valuable. Like in software – if it is hidden and no-one uses it or knows it is there…  it is not worth much.

Try it and see if the 4 principles are easier to recall.  Even if you are recalling a gecko pirate…  wait another second and it will lead you to ‘adaptability over plan’.


The Dreaded, Embedded Coach…

There’s a disturbance in the Agile force.  Consultancies and coaches who look for clients with a vacant coaching parking lot.  A place where coaches can roam the halls by the hour and bill for it without actually adding value.  I call this Embedded coaching and it’s something we, as coaches have a responsibility to eradicate.  Embedded coaching is great for people who want to make money and, from the business perspective, I can understand the draw.  I mean, if an organization is willing to continue to pay money and not realize value, why not?  Embedded coaches aren’t great for organizations who really want to improve nor is it great for Agile coaches overall.

Now, there can be several reasons why a coach isn’t adding value.  Things like:

  1. The coach isn’t a good fit for the organization and/or the team(s).
  2. The client really isn’t certain what they want to achieve so, then, the coach isn’t either.
  3. The client isn’t willing to be coached or do any of the heavy lifting so there aren’t results despite the best efforts of the coach.
  4. The coach isn’t good.
  5. The coach ceases to be a coach and becomes a player.
  6. The client doesn’t take advantage of the coach when he/she is there.
  7. The coach has embedded.

Dan LeFebvre (aka: Coach Dan), a coach whom I admire and respect a great deal, offered a definition of an embedded coach:

“I define embedded coaching as someone who is there 5 days a week working with a handful of teams or may be occupying the SM or PO role (either explicitly or implicitly by usurping the actual SM or PO authority) while being called the coach.” – Coach Dan

It’s the embedding I want to focus on.   I have a theory there’s about a 6-9 month maximum span of efficacy for a coach.  Granted, if the organization or number of teams is large and/or the problem is incredibly complex (transformation) more time may still be valuable and warranted as long as value is being added.  The reason I say this is because the more time you spend in a place, the harder it is to remain completely objective.  You come to expect and excuse certain behaviors – the “it is what it is” mentality can creep in (if you’re not very careful).  And, it’s after this time a coach is in danger of becoming embedded.

The embedded coach attends events and meetings, throws out some advice or observational feedback and vanishes down the hall.  He doesn’t collaborate – he pontificates.  He throws out a thought-provoking question and makes noises of interest in the responses, shrugs his shoulders and shakes his head.  Meanwhile, clients wonder “What, exactly, does he do and how is he spending his time?   At this point the client is wasting money and the coach is wasting time.  Not only that, the value of a coach and, perhaps, Agile is called into question as well.  And, this (calling into question the value of coaches and Agile)is NOT okay.

Coach Dan also offers the following for your consideration:

“I think coaches should work with the teams for a sprint or two then exclusively work with SM and leaders to improve their ability to operate with the agile mindset. Enterprise coaches also focus on establishing what I call the 3 necessary mechanisms to re-enforce agility: 1) impediments removal mechanism where slowdowns in the flow are rapidly identified, escalated and resolved; 2) building the capacity for internal coaching through internal people opting-in to the coaches role or through communities of practice; 3) agile portfolio management where the entire product/value flow is pull-based rather than push. A possible fourth is the “opt-in” cultural aspects that all good self-organizing systems need to truly multiply the effectiveness and delivery of value.” – Coach Dan

Dan Mezick, another coach whom I admire and respect, contributed the following Coaching Values which, I believe, are worthy of mention and introspection.  He also details supporting principles.

In serving our clients, we have come to value:

Creating Independence over generating billing
Championing Learning over avoiding risk
Building Relationships over building transactions
Inviting Participation over assigning responsibility

Ideally, coaches have chosen this profession because they love it and, happily, are able to support themselves and their families.  As coaches, we owe it to the profession and the clients we serve to ensure both are set up for success.   There are things we can do:

  1. Align on the goals of the engagement and the definition of value.  Meet regularly to openly discuss the progress and re-align.
  2. Ask the client “What value have I provided this week?”.  If he can’t answer, immediately diagnose the root cause together and agree on actions.
  3. Actively communicate what you’re doing, why you’re doing it and the results – realized or expected.
  4. Don’t establish a need for physical presence 5 days a week where you become a regular fixture of the environment and are taken for granted.
  5. Be honest and true.  You know when you’re not adding value.  Remove yourself with offers of alternate coaches or course of action.

Thank you for your time.

Yes. Size DOES Matter.

Contrary to popular belief Bigger is NOT better.  Big organizations want BIG stuff.  Whether it be projects, programs, releases, teams, scope, architecture…you name it, they want it BIG!  Even Org charts.  The more levels and boxes, the better.  But, when it comes time to getting things done the people you need to execute now have to jump through BIG hoops to make it happen.  And, after all of that BIG effort, the end result ends up being not so big.  Despite this notion of bigger not being better being proven time and time again, it’s still a challenge for people believe it.  I’ve blogged about this before and I offer my apologies for being repetitive.  Events have put this top of mind – again – and I just couldn’t control the urge.  Big <insert item here> leads to BIG problems.

Team Size – More people means more potential communication gaps, lack of alignment – to the commitment, the work and the vision, inability to unify into a single entity and difficulty collaborating.

Scope Size – Everything and the kitchen sink means greater risk.  Risk to what you ask?  Risk that what finally gets put into production is no longer relevant.  You put too much out there, something doesn’t work and you have no idea what that something is.  The problem you initially set out to address is diluted and gets lost in the shinier things people have managed to shove in.  There’s so much you have to move quickly and quality and deliberate decision making goes out the window.

Story Size – Well, the hood’s open so we may as well….. Wait.  What was this story delivering again?  There’s no way we can complete that in a sprint.  Now, what you thought was a quick fix ends up taking a quarter.

Process Size – Rather than addressing the root cause, we have a process to make sure that – what was it we were trying to prevent again?  Big Process is indicative of an inefficient organization/system.

Decision Size – You can’t empower anyone to decide to decide anything b/c the potential impact is (also) TOO BIG.  This means everything takes way too long.  The date you’re shooting for?  Add 6 or so months to it.

WIP Size – There’s so much in progress that focus is lost.  Congratulations, you now have 20 things in progress and completion of any one of them is no where on the horizon.  Makes for some BIG reporting though.  WOOT!

Want to scale?  All of the above applies times a gazillion.  Size matters.  If you’re seeing problems with being able to deliver quality software frequently and efficiently, dig into the size of everything.  Be warned.  You could find yourself standing in a very BIG hole.


The Burn Down – Using it for GOOD vs. EVIL

As  a Scrum Master, some of my teams resented the burn down and me for pestering them to update their time.  Sometimes, teams feel the updating of hours and the burn down are ways to make make micro-managing easier.  And, sometimes, that’s EXACTLY what it is used for.  It’s sad but true.  So, what happens when this “evil” scenario is true?

1.  Managers have a false sense of security that all is right with the delivery team.  They really like that.  As managers, it’s a bragging point.

2.  Teams don’t get a sense of what might be off easily.  This means a delay in realizing there’s a problem.  This is good when teams don’t want their managers to know there is a problem.

3.  The environment teams work within doesn’t improve enough to foster honesty and transparency.  This means no one really wants to learn about problems much less prevent or fix them.

4.  The evil cycle continues because without transparency, you can’t build trust.  A good burn down isn’t, by itself, a reason to trust.  Also, teams who have managers who manage to the burn down may have a hard time trusting their manager.  Does the manager REALLY want to know about, care about or help fix a problem?

5.  The Principle “Working Software is the Primary Measure of Progress” isn’t ever true.  I mean, as long as the burn down is pretty, who cares about working software? No ONE b/c the burn down is perfect!


When managers show value for the burn down rather than meeting the Sprint Goals and the team commitment, the team will ensure what the manager values looks AWESOME thereby completely missing the point.  The burn down is a great tool when used for good and a Scrum Master can help educate teams and managers on the goodness.  Frankly, when a burn down looks too good, I’m a little skeptical.

A daily burn down is an easy, quick, daily graphical representation of how the team is doing against their plan.  The key word there is THEIR plan.  If something looks off, it’s a signal for all of them to take a look.  There’s something taking longer than they thought.  Time is being added at a rate equal to or greater than time is being burned.  The team isn’t updating their work rendering the burn down inaccurate. There are other possibilities as well but, the point here is the team needs to take action.

They own their commitment right?  They also own the plan.  If something is taking longer, what is it and what can be done – now – to correct it?  There’s no need to wait for retro.  They can jump on it and get back on track.  It could be scope creep introduced somewhere.  It could be an impediment they’re spending too much time trying to resolve and need to escalate outside to get help.  It could be something they’re making more complex than it needs to be (perfect is the enemy of good).

Time being added faster than the burn down means they’ve learned more as they dove into the story further and there’s more to it than they thought.  They can work with the PO to see what modifications to scope can be made.  They didn’t really take planning all that seriously and need to re-visit their plan quickly to correct and let the PO know what has changed and what it means.

The team isn’t burning their time down.  This could be because they don’t see the value as a result of never having used it for its intended purpose.  If teams aren’t using it and aren’t taking action to refine and adjust as they go, surprises await the PO and stakeholders at the end of a sprint which is no good.

Helping the team see the value and teaching managers to value the accuracy of it rather than the ideal and actual lining up nicely is a good first step.  The team demonstrating their value for it through the actions they take – when necessary – to address it builds trust with the PO and the managers.  Reminding managers of the true goal – WORKING SOFTWARE and the importance of hitting the established sprint goals – and focusing on those rather than the burn down is preferred.

I like to leverage the demos to do this.  Review the sprint goals with the audience.  Speak to the target and actual velocity.  Show the burn down and walk through the learning points of the sprint with everyone.  If the burn down looks good  but the goals and target velocity were missed THAT is what managers need to spend time on.  I also like all of the above to use in Retro too.  Let the team consider the data to inform their growth opportunities and actions coming out of retro.

Burn downs are good…unless they’re obsolete and not used correctly.  Then, they’re evil and can impediments to Agility themselves.  Manage to the burn down and you will get a pretty burn down.  Manage towards a team’s ability to reliably and frequently deliver working software and meet their sprint goals and you will get a team who cares about that, takes their commitment seriously and ensures you are never surprised and are always aware of what’s going on.

An Armchair Agile QB

It’s been an interesting time in the Agile world lately.  I have read posts, tweets and the related threads with a little bit of amusement but, really, it has all just made me a little sad.  Dave Thomas, a signor of the manifesto, offers a perspective here regarding Agility and says:

“The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.”

I read the discussions on twitter.  I read the blog posts and all the comments.  Here’s YET ANOTHER flaming rail against SAFe (because there haven’t been enough).  Be sure to read the comments.  That’s where the magic happens.  And I sit at home, after a long day working and coaching, wondering how people have the energy to throw verbal hissy fits when, in theory, we’re all working and passionate about the same thing.  Unless, we’re not…

The Agile manifesto was a call to action.  A cry to work differently.  A rallying point.  People were passionate about it and the ensuing alignment was natural and a testament to its simplicity and purpose.  Dave was proud of the work but, not THAT proud:

“However, since the Snowbird meeting, I haven’t participated in any Agile events,1 I haven’t affiliated with the Agile Alliance, and I haven’t done any “agile” consultancy. I didn’t attend the 10th anniversary celebrations.

Why? Because I didn’t think that any of these things were in the spirit of the manifesto we produced.”

So, after the Snowbird meeting the Manifesto immediately became  an arena for consultants and product hawkers.  That’s the Fastest.Impact.Ever.  He was part of something larger than himself and proud of it – until, seemingly, the very next day.  You’re proud your name is on it as a signor but not proud enough to advocate for it or help people learn?  You write a blog post to slam what others have done, but won’t have a face to face conversation with those same people because it’s not in the spirit of the manifesto?

I LOVE that the post was written.  It starts a good discussion and it’s honest.   I would really love to see him attend the conferences he eschews and work to address the problems he has identified.  Engage on the field rather than being an arm-chair QB.

It’s ludicrous to see coaches beating each other up over the brands, methods and certifications.  Seriously?  It’s all rooted in the same four core values that haven’t changed.  Not once. Though I have even seen suggestions to change them too.  If you don’t like the method/framework/brand, don’t teach it.  No one is forcing it down your throat.  These rants (mine included)  kill me because the simplicity and the power that lies in the Manifesto get lost. As Agile professionals we’re collectively responsible for our profession and what started it.   Regardless of HOW it’s adopted or approached, what’s important – to me anyway – is the values and principles are front and center.  If there’s a framework that doesn’t put them front and center for you, there’s nothing stopping you from doing it yourself.

Disagreement and dialogue are good when we’re all trying to achieve a common goal.  Are we?

I’m going to go ahead and blame Dave for all this craziness because he took his ball and went home but continued to watch through the window and holler at everyone.  ;)




Take It To The Team

It is inevitable and tempting that many decisions that affect the team are made without ever consulting the ones that are primarily targeted.  Even if  enacted with good intent.  We still see this on a different scale when the software user was never consulted but significant choices were made in their best interests as well.  Certainly there is a balance somewhere in something that might be too small or trivial and as opposed to another extreme where the user is relegated to insignificance.  Taking choices to the teams and discussing solutions which impact them, is every bit as important as involving a software user.

  • Find out what they think and how they think.  This is a chance to connect and understand; an opportunity for innovation and creativity.
  • Get impact that you might not have considered.  Omniscience is not a human ability.
  • Consider some alternatives and adjustments to the plan from the team. Consider even that sometimes you may not be thinking ‘heads-up’ enough for vision and strategy if this is something the team could/should already be capable of deciding.
  • The team may not get the Last word or Decision – but include them in every step of the way.  They are learning about the organization and processes.  What they elect to change might surprise you and start to shift the organization or process in a better direction.

I wrote up a small Empowerment Quiz considering the posture of the teams I encountered.  Were they defensive? Perhaps timid? Spending time having the right conversations, actions and decisions to become better teams is important for me.  Ever made easier because the team is always important to me.  To be able to represent the team as working on the most valuable work to the organization, that the team’s work was high quality, and that we were adjusting to meet the needs of the user is a great job to have.  That a team is also improving the product, as well as it’s own skills, processes, and tools… even more so.

Shared leadership is a chance to grow and learn in an environment conducive to improvement.  We help each other to be accountable.  We are teaching and learning to see from different levels of perspective.  Being an active part of the solution is far more valuable than swept along in the tide.  The answers we search for and find ourselves tend to be more valued than the ones we are readily given. If there is a decision likely to involve them, before one is made, take it to the team.


To Whom It Should Concern

To Whom It Should Concern,

I am writing to you on behalf of a team I have will have the distinct pleasure to work with.  I don’t know when – as I have yet to meet them,  but they are out there.  Some when in time. This team will adopt an entirely new way of working and will change many of the processes around them. They will also change the tools they are used to.   This team is a natural collaborator.  They may not have all the answers, but I will see them get stronger and more  resourceful with every challenge that they come across.   They will develop a calm and deliberate manner with which they approach the work.  They will help the organization to understand the product they inherited and their own capacity for work.  This team will often strive for opportunities to better themselves. They are earnest in delivering a product that is slowly becoming what the user really wants.  It may require a bit if patience as this team matures.  There will be sparks of innovation and creativity that pay small dividends and will continue to accumulate for the benefit and influence with the other teams.  This team will need your support and at times your patience.  They may even struggle at times or misstep as they find answers on their own.  They may even challenge you.  I will tell you, there is greatness in this team. They will grow and tackle some tough problems for the organization.  They will try, learn, teach, and influence others to improve just as they expect it from themselves.  Congratulations on having such a team.  They are the ones doing some heavy lifting.  I hope you trust their professionalism and that they honestly want to create something valuable.    Help them with obstacles and to celebrate the small wins along the way.  Stay engaged.  Your interest and guidance will eventually find that they will be able to run faster than you could imagine.  Congratulations.

Xtreme Feedback

I once posted that in an agile sense it seems like We Can Never Go Fast Enough.  Going fast means we need to have quick reflexes; the ability to adjust. This in turn relies upon feedback.  Some information that quickly lets us know how we are doing and allows us to steer back on course. If someone is YELLING, then it’s our ears. Very often, however, it is our eyes that tell us.  It is why we lean so heavily on information radiators and large visual displays.
There has been a growing trend for a while now in pursuing ever faster feedback mechanisms; often named Extreme Feedback.   

The Extreme isn’t so  bad. Not as in some reality show which uses shock collars when something gets broken, but rather in the ability to very quickly ascertain information.

1) Where the code is
2) What State the code is in
3) If Something undesired actually happens – Signal for help!  600px-Nabaztag-IMG_1666

Whether it’s a bunny from Nabaztag or an Arduino (Uno or Mega) with some LED’s like this starter kit – these indicators can be tied into a build process and let the entire team know what is happening.  Collocated or distributed, these devices are fun ways to immediately inform the team about what is going on.

A Team Foundation Server Build Bunny

I might choose the bunny because Easter is almost here! I might choose an Arduino because I am tired of Hidden Easter Eggs!
From the Quality side of things, I always disliked very long processes that went on and didn’t have any verification until a dozen or more changes were involved. Let alone another dozen processes had already been gone through.  It was even worse, if like in waterfall, the next stage was the verification of several months of work.  Extreme feedback pushes into the small changes that the build is compiling and does a great job of simply making everyone aware. Quality in the moment. Devices like this can be tied into deployments, and even into Test results. What about some aggregated sprint or release results? Granted the feedback on a release is going in the BIGGER direction – but the automated indicator of a :(  *sad* bunny is impetus enough to rouse ourselves to action and address the problem.  In a fun way of course.  

If the team has a budget (and I often think it should), this might be a great, fun, and motivating project to help the team to get ‘to good’ as soon as something goes wrong.  In TDD (Test Driven Development) terms “getting back into the green”.  A passing state, and out from the red, broken state, as soon as possible.  The term leverages from the eXtreme Programming or XP Practices that Kent Beck championed.

Have fun if your team decides to use one.  Let us know how creative you were.

Without A Net

As a traveler I know there is always something new just lurking around the corner.  Whether it is taking a metro train and navigating a city, navigating a building, or even meeting people for the very first time.  Sometimes even when I am doing something practiced, a new situation has the tendency to spill itself all over the comfortable events I had planned on neatly unfolding.

There was a book written a while ago Working Without a Net.  I liked the premise that – eventually we should get used to doing some great things without worrying if we had a safety net below us.  Now I do NOT condone physically working without safety equipment.  Yet the mental equivalent of something comfortable which might hold us back from trying something amazing now and again, resonates with me.   The chapter about channeling one’s anger, seemed outdated, since it suffices only as a very short term motivator. – But, back to my story…

I have had a slide deck around for a little while.  I spent an hour updating it.  Improving it a little each time I bring it out.  It might be getting a little long with all the cumulative material through the ages.  Yet it allows me to cover the breadth and depth of the material.  I am comfortable with the content.

I had arrived early to the room.  I usually like to get a feel for the space which I am going to be throwing ideas around in.  Often I will change the contents around in some formation that benefits the audience as they participate.  Sometimes just to introduce a a change that keeps a creative ember burning somewhere that spacial permanence has seemed to desensitize the returning audience.  Tables and chairs arranged. CHECK.

Then the projector, screen, computer, slide deck, and any typical markers or post-its that a ‘meeting-in-a-bag’ might offer.  CHECK.

I know my voice can dial up to carry across the room – no mic. needed.  Wireless presenter to allow for some mobility.  CHECK.

Audience is starting to trickle in now. CHECK.

and with a quorum – off we go.  First Slide… Starting into the topic… and the projector goes out.   *sigh*

Is there a quick 10 second fix… nope.. and then the priorities start to become clear.

Why are we here -FOR THE AUDIENCE.  These people are important to me and I absolutely do not want to wast their time.  They have asked me to explain and explore a topic they have all previously expressed an interest in learning more about….  Alright – I made the slides – and those were from my experiences and insights… I’m still functioning….   What do I have around me… I have just switched from assessing situation, and a quick personal (psychological) inventory to looking at my surroundings.  What in the environment can I use to aid my survival.  :)

Abandoning the projector and screen

I see a whiteboard… I’ve got a marker or two… and the slides now become the old ‘Chalk Talk’ using some dry erase markers.

What were the really REALLY important things I want them to come away with… my mind starts leaping forward and re-arranging the material instantly.  Let’s draw it out.

Along the way I reach out and offer some choices as an audience… there might be two different exercises we can do to practice this… ‘which one would you like?’  The decision from the crowd takes a few seconds… It is one way to characterize the group – how long do they take to make a decision and how many were vocal.

The time and breadth of topic passes quickly as we get questions along the way which perfectly explore some common areas that can be misunderstood.  GREAT Questions that actually lead me to cover areas I might have missed AND take the audience along the route they wish to explore.  I feel more like a guide than a presenter.  Our safari into the topic still leaves me with how fun it can be though I’ve been here many times before- just not in the same vehicle driving through it.

Joking, laughter, and even a few AHA moments.

And before we go, a few minutes for being retrospective and feedback about the time we spent together… Some pretty high marks…no mention of the projector.  The ability to switch manner of delivery and increase participation is perhaps left unstated; simply appreciated. No thing is perfect but our ability to make adjustments along the way is perhaps one of the basic tenants for agile – have a plan but get used to adapting.

A few linger afterward and want to explore other areas of knowledge.  I wonder if the teachers choose the students as often as students prefer to choose their teachers?

The NET that I was careful to prepare, the slide deck… seemed as if it held me back from really connecting and getting the best curiosity and participation from those who attended.  What else is there that might be so comfortable, it may actually hold back and keep from moving into some spectacular things?