...copyright Elena Yatzeck, 2010-2017

Wednesday, February 23, 2011

Training Without PowerPoint

Are you a trainer? Are you a facilitator of any kind? Are you a person who hates being shown slides? (If not, please check out this famous PowerPoint rendering of the Gettysburg Address).

I just attended a very amazing two-day training course given by Luke Hohmann of Innovation Games(R).  The games themselves provide wonderful techniques for doing "qualitative market research" (if you're a marketing person) or "requirements gathering" (if you're a software developer).  You must try them, you must!  Check out the web site, buy the book, license the online tools, and use these techniques.  They are fabulous.

But as veteran qualitative researchers would tell you, the most interesting part of what I learned (and that's saying a lot) was from the medium, not the message.  The course was taught 100% PowerPoint free.  In fact, there was no projector.  It was the most devious and marvelously designed way to coax learning out of an group of adults I've ever seen.  So what did Luke do?
  • Tables covered with paper and strewn with fun office supplies:  each table had pens, sharpies, glitter glue, pipe-cleaners, really high-quality stickers, post-it notes, index cards, and so on, and each table was covered in paper, so if you wanted to illustrate a point to your table-mates, you could sketch it right there on the table.  Visual learning is a powerful thing, and equipping the tables this way set the course up to be non-threatening to participants, appealed to everyone's sense of humor, and (not, of course, an afterthought), put needed materials for later activities ready to hand.
  • Content posters:  core concepts from the course were conveyed on posters which he taped to the wall, and alluded to at appropriate points throughout the two days.  Full disclosure:  I believe PowerPoint might have been involved in the drafting of the posters, since it's WAY easier to use than most other drawing tools, but the slides weren't slapped up, discussed, whisked away, and then brought back in summary later on.
  • A really good in-class workbook for people to use and take home:  the book had a section of "course content" which included portable versions of the posters, a section of "case studies" for class discussion, printed worksheets to support some of the activities, and a bibliography for further reading.
  • Table discussions:  the case studies in the books were used to generate discussions around participant tables.  Once the tables discussed, Luke would facilitate a large-group discussion around findings, adding his own insights (and gestures towards the posters) as appropriate.
  • Discussion posters:  a number of class activities involved participants gathering around a poster with some type of image on it, and brainstorming by putting post-it notes of content onto different areas of the poster.  For example, participants thought of activities which would fit into a set of quadrants defined by "more or less pleasurable" (x axis) and "internally versus externally motivated" (y axis).  Or participants armed with sharpies filled out a whole wall of posters with activities which fit into the categories on those posters.
  • Participant-led discussion:  granted, it was a group of facilitators, but I think this would work with any group--for poster discussions, Luke occasionally drafted a participant to draw conclusions from the poster, rather than sorting the post-its and talking to them himself.
  • Games and simulations:  the course was an introduction to the games, which are facilitated in person and also over the web, so naturally the course involved participants playing the games.  However, in my view, games and simulations are great IN ANY TRAINING COURSE, for participant learning.  Far better than having a moderator try to dryly convey "content packages" in slide-sized chunks directly from her brain to that of the audience.
As a veteran trainer of adults, I can tell you that every time I bring out the slide deck, I know that after ten minutes or so, the tired people in the room are going to literally start falling asleep.  It won't be everyone, but about 5% of any given room has been up late last night, up early this morning, or both.  It's sad to watch as their eyelids flicker, and bam!  they're out.  I'm a goofily interactive instructor, but nobody can save a long slide presentation forever.  I am really challenged and excited by Luke's course design, both for training purposes and for team facilitation purposes in software development discovery and retrospective activities.

Thursday, February 17, 2011

Story Maps

I was startled to discover "story maps" a couple of months ago as an alternative to, or supporting documentation for, the "product backlog" or "master story list" (depending on whether you're Scrum flavored or XP flavored).  The maps should not have been a surprise to me:  it turns out a lot of the really cool agile teams are creating multi-dimensional "story maps" as part of their project inception.  In case some of you weren't aware of the story maps either, I just wanted to alert you before another day passes, and point you towards some help on the topic.   For the rest of you, why didn't you tell me??!

Jeff Patton posted this excellent overview of story maps versus backlogs in 2008, and as he says, this technique had already been used on the ground by a number of agilists other than himself for several years before that.  And responders to his post identified the story map as something akin to an old fashioned functional breakdown which dates back to the beginning of software development (say 1970, where unix time begins).

I strongly recommend that you simply read Jeff Patton's blog, but in case you're looking for a simple definition, here it is.

Recall that a "story" is a description of the behavior of a system described from the point of view of someone in the business.  In an agile project, stories are written on index cards.  For example:

As Patton says, in an agile project, the "requirements" for a new system would typically be described in dozens or hundreds of this type of story card.

A story map is an arrangement of these story cards which represents the sequence in which the stories will be needed by the business on the horizontal axis, and the priority of the stories on the vertical axis.  The horizontal axis should represent the minimum set of features needed by the system to allow it to be released.  As a corollary, you would typically have some large stories representing "user activities" across the top of the chart, in the order in which those activities would take place, and a breakdown of those activities into actionable stories in a vertical column under each of those activities.

In the example above, the "blue" cards represent a user activity, the sequence of blue cards indicates the minimum marketable features (MMF) for the product. However, for the team to actually build the system, they need to deliver some subset of the pink cards, which provide more detail about the blue cards.  Note that if you just delivered the first row of pink stories, you would have a basic system, and adding additional pink story cards below would start the gold plating process.

You can see how you could walk a stakeholder through this kind of story map, and they would immediately be able to see what you were missing, and you'd have a much better chance of delivering a complete system.

You might want to translate this story map into an actual "list" or "backlog" in your Agile Lifecycle Management (ALM) tool, but as Patton says, you would benefit by keeping the map around so that people can always revisit the big picture and orient themselves.

In other breaking news, apparently we "in the know" agilists now like to call "non functional requirements" "cross functional requirements" instead.  But that's fodder for another day.

Wednesday, February 16, 2011

Agoraphobia Meets Individual Genius

I read a really thought-provoking article from the Financial Post this week which was somewhat misleadingly titled "Innovation:  Group Dynamics Can Stifle a Great Idea."

I have to admit, I jumped right on this article, because in the Dark Days before I met Agile, I was one of those people (as perhaps you were) who always hated being forced to "work in teams."  Even today, I feel a slight twinge of fear when a speaker asks an assembly to "discuss [an idea] at your table," knowing this might be followed by a very awkward moment later on when some poor soul in each group will be forced to extemporaneously report on (or perhaps invent) it's "findings."  Perhaps some of you still fight off Fear of the Wisdom of Crowds sometimes too?

Of course the article does not actually say that "Group Dynamics" stifle "Great Ideas."  Instead, it points to research at Wharton which found that a group was best empowered to develop a great idea when some one individual, an "inventor" cast in the mold of an Albert Einstein or a Steve Jobs, had done significant thinking about the idea before laying it out in front of the group.  The study found that this hybrid approach worked better than group brainstorming alone.

We as agilists would add that the hybrid approach undoubtedly also works better than a command-and-control approach where the person with the bright idea orders a team to develop it exactly as invented, and then blames the team for failure to execute down the line.

Be that as it may, however, the Wharton research on the importance of individual brainstorming and initiative seems immediately applicable to many aspects of life on an agile team, particularly when it comes to the ideation and inception phases of a project, where the team first gets its overall sense of what the project is intended to accomplish.  Experience has shown again and again that we need a whole team to deliver a high-quality, valuable piece of software which will be robust for its normal life.

But in asking what the software should do and why, or even how, if a project is bringing innovation into an existing technology stack, we should not be too quick to insist that all ideas have to spring from the entire assembled membership of the group, and we should embrace our solo inventors.

Tuesday, February 8, 2011

On Trust

When I introduce friends to agile software development, the concept which stops them dead in their tracks is not "value points," "test driven development," or even "continuous delivery."  The seriously challenging concept is...trust.

Don't try this...ever.

Agile lives and dies on trust, but trust is a commodity in short supply in many of our work places.  Why do we value contracts over collaboration?  Because we want to know who to blame when (not if) the project goes south, that's why, and we want to be able to sue them, fire them, or at least hold them up for public humiliation.

So how do you turn on the trust spigot, the wellspring for all actual returns on your agile investment dollar?  I will confide a little known secret to you.  People do not owe you their trust.  That thing where you allow your lower lip to quiver when people don't immediately jump to support your far-fetched organizational transformation idea?  Or the thing where you wave your resume annoyingly in the face of the new people you've just met, and demand a desk by the window, and turn down meeting requests without even explaining why?  Give it up.  Trust is something which gets built up over time, and it is something you earn.

Here's how:
  1. Keep your promises, large and small.  If you tell someone you'll send them an email, send them the email.  If you agree to set up a meeting, set up a meeting.  If you goofily agreed to take minutes on the world's most boring meeting, and you promised to send your notes out to all the attendees after the meeting, send them out after the meeting.  The way to earn trust is to make tens, or hundreds, or thousands, or a lifetime's worth of handshake deals, and to treat each one, however small, with the respect you'd give a contract signed in blood.  Once you become too important to show up to meetings on time or keep your small promises, you're not a trusted partner.  You're a wildcard to be exploited, at best, and a depressing, largeish obstacle to work around, at worst.
  2. Be careful about what you promise.  Here's a corollary and a tip.  To avoid collapsing under the load of your small promises, think about what to promise before you do it.  Give clear signals when you can't make a promise, and explain why you can't, if that's not clear.  In a world where your word is your bond, you need to be sparing with your word.
  3. Give the other guy the benefit of the doubt the first time.  Game theory suggests that if you're in doubt about the motivations of a person you're working with, you should go ahead and extend your own trust to them in your first interaction.  Unless you are in actual danger in the worst case scenario (for example, if you're rock climbing, and the new person you're with says you should let them secure the rope), it's a good idea to trust in your first interaction.  The other person will appreciate getting the benefit of the doubt, and you will potentially make a new friend.
  4. If that didn't work, you know better next time.  That addage "fooled me once, shame on you; fooled me twice, shame on me," is actually a helpful guideline for successful corporate living.  There is no need to trumpet to the world that you've encountered a non-trustworthy person, but now you know.
There is no tool, platform, or method in the world that can help you manufacture trust.  Trust must be built one interaction at a time, and you need to allow time for the trust patterns in your environment to make themselves apparent.  But once you reap the harvest sown in time, attention, and effort, you've done the hardest thing of all on behalf of your agile revolution.

Tuesday, February 1, 2011

Scientia Potentia Est

It turns out the famous Francis Bacon phrase, "knowledge is power," doesn't actually appear in any Francis Bacon work.  According to our mutual best friend, Wikipedia, "The closest expression in Bacon's works is 'Human knowledge and human power meet in one; for where the cause is not known the effect cannot be produced. Nature to be commanded must be obeyed; and that which in contemplation is as the cause is in operation as the rule.'"

Which just goes to show you that, once again, hearsay gets it a little bit wrong.

Scalable communication is tricky, and not least because people are conservative about letting too many people have access to too many facts.  Witness the current controversies over "internet freedom," spurred by the wikileaks events, or the Egyptian government's recent move to completely shut down the internet in that country.    But bringing this down to a level or two below that of national security, let's talk seriously about the phenomenon of "not having too many people in the room."

We've all heard the phrase.  "No, sorry, we don't want X there--it's going to be too many people in the room."  Does it bother you when you hear that?  It bothers me.  That is a statement which simply can't be taken at face value.  It is a "smell."  How many is too many?  What is really going on here?  Agilists, unfortunately, are as quick as anyone else to seek small rooms that don't have "too many people" in them, when conferring on important issues.  Why is this?
  • Comfort:  Sometimes, it's a matter of comfort for the small group of people who are talking things over.  Retrospectives, for example, are classically held by the "core" agile team, because the team itself needs to determine what things are going well, and what things are not going well, and how to fix them.  The last thing the core team needs is for everyone's line manager to hang around hearing reports of non-optimal behavior.  In some environments, it may be difficult enough even to develop trust across the core team.
  • Fear of spamming:  These days, we are barraged with information, and in particular, we all get a lot of email.  A lot.  So groups may feel better about having a small private meeting and then trusting to "word of mouth" to get the results out, rather than "bothering" others with information.  A colleague of mine just apologized to me for sending out three useful blast email messages yesterday, hardly a matter for shame and regret.  It's a slippery slope from "fear of spam" to "not too many people in the room, and the message never gets out."
  • Conflict avoidance:   Let's face it.  There are some people you just don't want in the room with you, because they are unpleasant and disruptive.  If you're not ready to have a complete "let's look at your future with this company" talk today, or if the person is senior to you and no-one will ever have that talk with the person, then it may be easiest to simply draw the line around the small room, and define "too many" as "the number in the group plus one," where one equals "Dysfunctional But Un-Removable Bob."
  • Familiarity:  Sometimes, we just don't think to include people in meetings, because we're used to always meeting with the same people, and we don't want to disrupt something that is working well.  Fair enough, but one person's "dream team" may be another person's "tenure clique."
  • Wanting to avoid "raw" messaging:  A pattern which may happen is that a small team may want to fine-tune its message before conveying it to others, to avoid giving offense, or to increase the impact of the message.  But then they don't actually send the message.  Is this you?  I think you should think about this!
The bottom line is that no matter what your reason for including or non-including people in the room, and despite the fact that Bacon never actually put it this way, knowledge is still power.  Transparency has to occur inside the room and if the room isn't big enough to include all 10,000 of your company's employees, then communication needs to occur outside the room as well.  Yes, asynchronously!  Even if the message is not well-crafted.