...copyright Elena Yatzeck, 2010-2017

Wednesday, April 27, 2011

Shu Ha Ri: How To Train People To Want to See What They Don't Know

I read with interest my colleague Mark Needham's recent blog post about his experience as a trainer at ThoughtWorks University, the on-boarding program my company uses for entry-level employees.  TWU utilizes a training methodology invented by Jay Cross called "workscaping," which is ably described in this blog post by the TWU director, Sumeet Moghe.  This is a very cool program, not least because most entry-level new hires get flown from all over the world to India for six weeks to participate in it.

Sumeet's thesis is that the best way to teach people is to put them to work immediately, so they can become aware in context of things they need to learn, and then reach out for that knowledge.  Build the need, then satisfy the need.  And indeed my observation is that in this world, we are now much busier fending off information than reaching out for it.

A poignant, but useful digression, I promise:  When I was growing up in Appleton, Wisconsin, USA, I was incredibly excited about the one time I got to go to the Museum of Science and Industry on the south side of Chicago for a high school field trip. 

Downtown Appleton, Wisconsin, USA
The Whispering Gallery!  The dollhouse!  Interactive stuff!  I was enchanted.  In fact, I still remember that trip pretty vividly, and it was more than thirty years ago.

Whispering gallery at the Museum of Science and Industry
When I took on the daunting task of raising my own daughter in Chicago, we lived across the street from the Museum of Science and Industry.  I bought a membership!  She practically grew up there!  Until she turned five, and lost all interest.

Today, my daughter doesn't go into museums unless bribed or forced in some way.  Her dad recently convinced her to visit the Museum of Modern Art in New York City, and she told me that although she liked it, she found it overwhelming--there was too much there to analyze, too much to think about.  Zosie's opinion was apparently shared by "Julia" from Sao Paulo:
Copyright Moma 2011
Our society has become so efficient at aggregating things--museums, orchestras, books, schoolroom curricula, 24/7 internet on tap--that we need to build walls and set limits to avoid being constantly overwhelmed.  Goethe, as I am fond of saying, was the last person in a position to know "all there is to know," not just because there will never be another Goethe, but because since 1832, our collective information about the world has exploded, and although it is now almost all available at our fingertips, it is really hard to filter everything and to form a personal set of knowledge which is meaningful.

But what, you say, does this have to do with Sumeet Moghe, Mark Needham, ThoughtWorks University, and Alistair Cockburn's frequently cited agile references to "Shu Ha Ri," the Japanese budo concept roughly meaning "hold, break, leave?"

I'm here to advocate for the opposite of aggregation:  trainers who inspire and condense.  If we want to train people to do things, we need to put them into an Appleton state of mind:  aware of what they are missing and eager to learn it.  And ironically, I'm not sure that having people do "work" in a "workscape" is always as efficient as self-contained "artificial" training scenarios, or even, gasp, lectures, for making people fall in love with what they don't know.

Here's what Mark says about the difference between the experience he had getting old-fashioned classroom training (in the olden days of 2006), versus the kind of learning which occurred in this year's workscape:  "My general feeling is that although TWU v2.0 is better designed for helping people to learn, an advantage of the previous approach was that there was more opportunity to see the gaps in your skill-set."

There is something deeply inspiring about hearing the best of a senior person's years of experience condensed into a digestible presentation, especially one that can be revisited later by reading it in words, written examples and diagrams.  Although significant amounts of learning occur when a person is thrust into a position where they need to find a solution, there is a danger that having found the solution, the learner will lose interest in the topic altogether.  We need to create opportunities for that person to look beyond the moment, aspire to something better than the first solution to hand, and become aware of the value of lessons learned by others.

Rachel Davies has gone on record saying she is uncomfortable with the authoritarianism implicit in the "Shu Ha Ri" philosophy of teaching agile techniques.  "Just let people learn to think on their feet," she says.  I have to say that I'm not totally sure about this.  I've experienced an agile training where the trainer distributed people who were brand-new to agile into groups, positioned them near an empty wall, and said "okay, have a scrum meeting."  It was silly, and I doubt this is what Rachel had in mind, but I think we sometimes need to have heroes we admire telling us exactly what to do to get beyond ourselves and our own beliefs about our limitations.

Show people a whole functioning system mastered by a person who has spent years on it, and ask them to internalize small parts of it one at a time before going on to look for variations.  Go ahead and let them see someone who is really great, and be inspired to emulate them and to take advantage of the community's experience.  Shu Ha Ri -- learn the rules, break the rules, then ignore the rules.

Thursday, April 21, 2011

Agile Project Management and the PMP

Two years ago, an interviewer asked me with tactful pity how I happened to have gotten a Project Management Institute "Project Management Professional" certification, (and why I had the bad taste to include that fact on my resume).  I was applying for a job as an agile project manager, and my age and PMP certification both counted heavily against me in this endeavor, although of course we were all being tactful about the age thing.  I was told gravely that people like me are pretty set in our ways and it is usually hard for us to be light enough on our feet to handle an agile project.  I was quizzed heavily (and quite skeptically) on the fine points of stand-up etiquette and card wall techniques.



I was taken aback by this experience.  Honestly, I did briefly flirt with the idea that I should just grab my Big Upfront Design binders and totter home.

But something funny happened on my way to the glue factory.  It turns out that in real-life, you can't just take a college graduate or even an experienced agile developer and expect her to go out and start making money as a project manager solely using techniques she could pick up from the writings of the Agile Founding Fathers, even as awesome as those writings are.  Search as you will, and even Jim Highsmith's amazing Agile Project Management doesn't tell you about executive client management, handling a budget, billing, invoicing, risk assessment and mitigation, appropriate communications plans, or how to do a project close-out.

Those topics weren't left out because we shouldn't do them any more or because they were BAD--they were left out because they were taken for granted by early agile writers.  They were second nature.  Our Agile Founders were skilled entrepreneurs and consultants who took a significant part of their intrinsic knowledge and everyday survival practices for granted, and only wrote about the new stuff they were doing.

So where does that leave us?  To me, it means there are some fields of inquiry into agile approaches to practices wide-open to further discussion, with the PMBOK serving as a really well-organized outline.  I've already talked about the "agile communication plan."  What could the agile risk-management plan look like?  Or agile project inception?  And it turns out I'm not alone in rediscovering the PMBOK as a wonderland of options for use which need to be dusted off.  Like minded allies including Alistair Cockburn are jumping into the fray, with his "Oath of Non-Alligiance:" "I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation."



Rather than looking down our agile noses at the Project Management Institute, I vote that we systematically work our way through all of the standard practices and take a new look at them.  We could systematically blow them up, one by one, I suppose, if they don't suit our current needs, but if so, at least we would know we were doing a very thorough job of it.  To arms, agile comrades!  In this, the 10-year anniversary of our movement, the PMBOK is the new Manifesto!

And just in time, too, since PMI is now granting agile certifications...

Wednesday, April 6, 2011

Agile Project Communications Management

Pop quiz:  as an agile project manager, how much attention do you pay to your communications plan?
  • A:  Dude, see the Agile Manifesto!  We're all busy creating working software here, and if you want to know what's going on, come to our biweekly showcase, or just drop by and visit the team room.
  • B:  Ho ho!  My group has "Communications Plan" language we can just re-use for all of the projects, so I don't have to spend a lot of time thinking about it--I just drop it into the charter and off we go! 
  • C:  I think we're fine.  We're using application lifecycle management (ALM) software, and we keep it up to date for anyone who wants to check.  Plus we have some regular meetings and a distributed email list people can subscribe to, and that seems to get the job done.
  • D:  [runs away screaming]
  • E:  Ahem.  "Project Communications Management" is number 7 of the 9 Project Management Institute (PMI) Project Management Body Of Knowledge (PMBOK) Knowledge Areas.  It can be divided into four project activities:  "Communication Planning," "Information Distribution," "Performance Reporting," and "Administrative Closure."  As specified in PMBOK, I create a communications plan during the early phases of the project, follow it all the way through, and review it as I go to make sure it is still working.
So of the choices above, up until recently, I would probably put myself at "C," which at first glance looks to be the only pragmatic option the quiz offers.  If Mr. PMBOK confronted me, waving ISO compliance forms in a menacing way, I would be able quickly write up what I was doing and call it a plan.  If Agile Guy and I were chatting about Ruby and playing Beer Pong together, I wouldn't make him too uncomfortable either, if the topic of my communications plan came up.  Like Elizabeth I, but with less influence, I would be owning the whole via media thing.

Recently, however, I've begun to think that all of these options have a common flaw for agile project communications management:  an underlying belief that project-level communication is, in Mr. PMBOK's words, "information distribution."

Agile Guy will tell you that his showcase is richer than Mr PMBOK's weekly emailed status report, since it takes place in a shared space where something tangible is being shown, and where verbal and non-verbal message components can all get through optimally from the team to the stakeholders.  But both of these guys are picturing project communication as a one-way trip for some discreet pieces of project intelligence.

In the diagram below, "A" is the project team and "B" is the stakeholders:



Agile Guy would be quick to say that the whole point of agile software development is that it is collaborative and NOT just a set of one way communications.  It is a series of multi-person, multi-directional conversations which leverages and quickly builds the wisdom of the whole team, and which includes an evolving group consensus.  In the diagram above, the team room would be a literal shared space, and the one-way arrow would instead become a set of models (software pilots, wire frames, etc.) which everyone would contribute to.  Information would not be conveyed from point A to point B, because A and B would be sitting together in a shared reality building something real through words and actions.

Exactly!  I say.  Let's extend the communications model used INSIDE the project team, and do something more like that for communicating BETWEEN the team and its stakeholders.  While you're off in your shared space building something great, what about the stakeholders who aren't in the room?  Are you going to fob them off with a biweekly "showcase" which devolves back into transmission of "what we did" from Point A (team reality) to Point B (stakeholder reality)?  Well, it depends.

If you're building software which will make a significant difference to your business (and if not, why are you building it?), then your project communications plan should be creating a shared discussion among the stakeholders around that business change which is very analogous to the discussions occurring constantly in the team room.  You and your Product Owner jointly own that problem--you are the one with the experience to know you need an appropriate communications plan, and your Product Owner knows the stakeholders.

So what would this agile project communications plan look like?  Here we need the wisdom of Mr. PMBOK along with our own brilliantly agile selves, and we should all be taking a much closer look at the professional disciplines of marketing and "internal communications management," whose practitioners spend all of their time figuring out how to find people and speak with them in their own language.
  1. As Mr. PMBOK would tell you--spend some serious time up front with your Product Owner and your whole team thinking about what the "conversations" need to be among the stakeholders, and how you can get those conversations going and keep them going.
  2. Get people into a shared space:  physical, virtual, or at least mental.  This is way harder than you might think.  You need to think carefully about the media which will reach your stakeholders, and most likely this will require an energetic person to create a network of project champions by actually speaking with them, and getting them to agree to speak to others.  This is not a "knowledge management" issue--it is a human issue, especially today.
    • A project web presence is pretty useless unless someone seeks it out.  
    • Executives and techies are actually the LAST people you should attempt to reach through blast email.  Most executives I know will tell you straight out that they don't read their email.  Most of my tech-savvy friends get more than 1000 email messages a day.
    • And even if they knew about your ALM presence, your stakeholders are so busy fending off unwanted email, the LAST thing they're would do is take some time to log in and check out your awesome color-coded virtual project cards.
  3. Create occasions for conversations, not lectures.  This could be meetings or even one on one conversations.  A rule of thumb for many consultants is that client conversations should involve the client speaking 60% of the time.  You'll need communications techniques which involve leading with questions, and allowing information you might be eager to convey leak out at a pace you don't set.
  4. Plan to continue to put energy into building a shared project business environment all the way through to UAT and delivery.
  5. And as agile and PMI both mandate, keep checking to see if it's working--figure out what metrics you will use to judge whether the business is ready for your software and whether your various communications compaigns are working, so that you can know whether you're being effective and adjust if you're not.