Skatepark as Organic Learning Environment

The Ann Arbor Skatepark opened this year. It is a $1 million, 30,000 square foot wonderland of, well, all sorts of things that are great for skateboarders. As described by the City of Ann Arbor website,

Skateboarders will enjoy features such as kidney pools from 5 feet to 9.5 feet deep, a snake run, clover and flow bowls, rock ride and a slappy curb. Landscape features being incorporated into the design include native plants and bioswales and retention areas that exceed standard stormwater requirements.

I can’t really describe how cool this little place is. On a sunny mild Saturday in September, my son joined around 50 kids of all ages (well, not all ages, but every age from 5 to 30, notwithstanding my bruising 5 minute foray) having an absolute blast on skateboards, inline skates and Razor-type scooters.

What struck me was the park as an organic learning environment. The skater ethos and indeed the park's official etiquette and rules emphasize that there is no structure, no competition, and, especially, no coaching by parents. As such, I struggle to build even a flimsy metaphor or analogy to suggest how we might create more effective corporate (or for that matter, youth sports) learning environments. There are many clichés to describe the learning dynamic that we struggle to create in a more deliberately controlled setting. The cliches become beautiful realities in the skate park, without a whiff of irony or cynicism:

• Forming communities. The vast majority of kids were riding skateboards, with just a few on scooters and inline skates. Three of the better scooter riders found each other, and began travelling as one through the park. They would stop together and confer about how to do a trick or navigate the next feature. Nobody had to formally identify them as the best practitioners of their craft or bring them together so they could learn from one another. They just did it.
• Raising the bar. A group of four skaters is flying repeatedly over a set of stairs that is part of the park. Clearly, they are among the few that can do that trick, with grabs, ollies, and other variations thrown in. When that trick becomes easy, they set up their own challenge. They lay down a plastic garbage barrel at the top of a ramp and start trying to jump over it on their boards. If these kids were under the direct supervision of a manager, they wouldn’t be allowed to move the garbage can, and they would also be less safe practicing the same difficult trick using an existing park feature (namely, a cement barrier).
• Informal coaching and mentoring. For a few minutes, I observed the skateboarding of one young man I’ll call the Smooth Skater Wearing a Knit Cap on an 80 Degree Day. He was rolling along by himself all around the park, and I was struck by the fluidity of his skating and his occasional tricks. In my eyes, he was the best skater in the park, but he was by no means a show-off. All of the sudden, Smooth Skater stops next to a kid half his age, and gives him some coaching. Hey, Lil Bro, he seemed to be saying, you need to get more springiness in your knees as you go over the slopes, like this. Smooth Skater provides a quick demonstration of what he means by springiness in the knees, and watches as Lil Bro tries it. Then Smooth Skater shows him how one would apply the springy knees technique on a small slope about 5 feet away. He taps Lil Bro on the chest with the back of his hand and skates away. The whole thing took no more than 15 seconds. Lil Bro starts practicing the springy knee thing, statically at first, then down some easy ramps. It was a beautiful interaction, initiated by someone I’m sure never went to a corporate coaching class and never entered into a formal mentoring agreement, with Lil Bro or anyone else.
• An environment of trust, where mistakes are OK. Without a delineated path and dozens of kids doing their own thing in a relatively small space, there were collisions, near collisions and other mishaps occurring every few seconds. If one kid bumped into or cut off another, they both got up, someone said “are you OK?” and someone said “sorry, Bro.” They shared a fist bump or a laugh (more often both), and they moved on. You know what I did not see any of, in a full hour of observing the skatepark? Injuries, flaring tempers, hurt feelings, or interventions by authority figures.

How do these things just happen at the skate park, yet they happen only through great effort or divine providence in the large workplace? It is the design of the environment? Is it the bringing together of like-minded people? Is it the passion? Is it the wider culture of this hobby?

I don’t have good answers to these questions, but I'll keep thinking. I’d love to hear your ideas in the comments.

Coaching Skills for the Performance Consultant

Last week I attended two enlightening classes with 30+ CA Technologies colleagues: Coaching Agile Teams, with Michael Spayd and Michael Hamman, and The Coaching Stance, with Lyssa Adkins and Cynthia Loy Darst. All of the facilitators were from the Agile Coaching Institute. The audience included internal Agile practitioners, mostly coaches and scrum masters, along with internal education consultants. The week ended with all of us armed with new Professional Coaching skills and a renewed sense of optimism that our alliance will bring our agile transformation to a new place.

Everyone took away something different from this experience. I learned three lessons about how to apply coaching skills to my practice of performance consulting.

Takeaway #1: Coaching and consulting are different skills.

A moment of clarity came when I realized the difference. Coaching is designed to help the client explore within herself. As a result of this facilitated introspection, the client draws her own conclusions about what is important and is able to articulate what they really want.

Consulting is designed for the benefit of the consultant, so that he can provide the service or product that will best align with business outcomes of the client.

Takeaway #2: Coaching can inform consulting to make it more powerful.

Consulting calls on you to rigorously analyze a business problem with the client, agreeing on the desired outcome and identifying the root cause. Often clients typically approach the education department with a solution in mind, but most often the solution is not aligned with the problem. Consultants help to remedy that by driving the conversation with consulting questions.

At certain points in the consulting conversation, it is beneficial to move into coach mode, applying higher levels listening and applying questions that prompt the client to better articulate their vision or true desires. This takes more time, and takes the consulting in a less linear direction. The coaching intervention can be more personally powerful, whereas the consulting conversation helps focus on a specific need for the client’s constituency.

Takeaway #3: Sometimes you coach.

While not central to the job, the performance consultant finds himself in situations, formal and informal, where the the consulting hammer is not appropriate for the screw that is presented. People simply need help finding ways to be more effective.

Since there is such an overlap in the coaching and consulting skill sets, the lessons for my practice were powerful but nuanced. The greatest source of hope was the profound transformation that many of my engineering colleagues experienced. Our coaches have tremendous technical and agile expertise, and the coaching skills really helped to complete their skill sets. The lessons they learned, about the human side of agile and the power of true coaching, have the potential to propel their influence to new heights.

Let the games begin.

Test Your Knowledge of the Scrum Guide™

Ken Schwaber and Jeff Sutherland,
authors of the Scrum Guide™

Among readers and non-readers alike, the list of books that people say they’ve read but actually haven’t read is a running joke. Among agile practitioners, Scrum Guide™, The Definitive Guide To Scrum: The Rules of the Game, developed and sustained by Ken Schwaber and Jeff Sutherland is the top book on that list.The book is available for free as a PDF from scrum.org, At 16 pages, it is light enough to require a paperweight (should you decide to print it).

I would advise anyone trying to practice scrum to look at the the Scrum Guide™ from time-to-time. Today I read it for probably the third time in two years, and I cannot believe the misconceptions to which I have fallen victim. Not that the Scrum Guide™ is the final or only word on Scrum (much less agile), but this book does a wonderful job of defining those certain things about Scrum that are immutable. You will also find clarification about issues where you or your team have decisions to make as a team. Aside from the rules of the game, there is wisdom and experience  in the words of the authors, as this book has been revised and re-released many times since 1991. On that basis alone, it is worth a look as you mature with the book.

Test your knowledge of the Scrum Guide™, July 2013.

How many of these 6 questions can you answer correctly? :

Q1: How many times does the Scrum Guide™ mention “software”?

Answer: 0.

This is interesting because it glosses over one of the oft-quoted Principles behind the Agile Manifesto: “Working software is the primary measure of progress.” As you read through, you can see that the rules of scrum have been wordsmithed, so that they can apply to any group of people making a “product” that is “released.” In place of working software, you will see references to “working product” (page 4). Scrum may have been invented by software people, but it can be applied to pretty much any work that involves an output of any kind.

Q2: What does the Scrum Guide™ say about Scrum Ceremonies?

Answer: Nothing.

But it does dedicate 5 of the 16 pages to “Scrum Events” (same thing, new name).

Q3: According to the Scrum Guide™, when is a Sprint Goal formulated?

Answer: It is created by the team during Sprint Planning. “After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal” (page 8).

I did not know that! In the past few months, I’ve spoken with several people about the idea of Sprint Goals, and I always assumed (as I think did some of my conversation partners) that the Product Owner created a Sprint Goal as part of Backlog Refinement. This document is full of little gems like this one.

Q4: How many times does the Scrum Guide™ mention Backlog Grooming?

Answer: 0.

The term is now Backlog Refinement.

Q5: How much time does the Scrum Guide™ suggest that the Development Team dedicate to Backlog Refinement?

Answer: “No more than 10% of the capacity of the Development Team” (page 13).

I can’t argue with that number, but it seems to be considerably less than our team perceives it to be. Agree or disagree, this nugget is a worthy team discussion point.

Q6: How many times does the Scrum Guide™ mention “Release Planning”?

Answer: 0.

There are three references to releasing product, but none to Release Planning. The document mentions “strategy” 0 times as well. It does mention “sprint plan” or “sprint planning” 15 times.

There is plenty written about the topic of release planning. One thing I found instructive was Mike Cohn’s blog Release Planning: Retiring the Term but not the Technique, Based on the comment warfare below that blog piece alone (87 comments), I hope the reader will understand that I consider myself well-advised simply express gratitude, because I now know that in 2012, Mike Cohn told us all to never, ever use that term again. “The term is no longer correct. We need a new term.”

Rest easy, release planners. Ken Rubin’s excellent book, Essential Scrum: A Practical Guide to the Most Popular Agile Process, “A Mike Cohn Signature Book” published in 2013, dedicates a whole chapter (23 pages) to release planning.

Notwithstanding the bombshell from the esteemed Mr. Cohn, I first decided to reread the Scrum Guide™ in search of an answer to my question about release planning. How does Scrum help Product Owners to take a long view of product development? Predictably (in hindsight), It turns out that the Scrum Guide™ does not address my question. Happily, Ken Rubin’s book does. Our team has struggled in part from focusing too much on Sprint Planning, taking very literally the notion of maximizing value on a sprint-to-sprint basis. We find that our planning is too myopic, too in-the-moment, and we lose track of the big picture. I need to do some more thinking and research as to how integrate long-term thinking into product development in Scrum.

Conclusions

1. I don’t need to tell you what getting 2 out of 6 correct or 6 out of 6 correct says about you. You know.
2. The global cottage industry that is Scrum continues to grow. That the Scrum Guide™ has been purged of every direct reference to software shows that the scrum business is looking to grow into other fields. The same can’t quite be said for  Scrum,org, the publisher of the Scrum Guide™, whose tagline remains “Improving the Profession of Software Development.”
3. I am reminded that when a reader of the Scrum Guide™ who works on scrum team also supports the agile enablement effort in a large software company, managing the training component of the agile transformation, the lexicographic hairsplitting of agile terminology by pontifical gasbags can grow tiresome.
4. LIke most great reference pieces, you can turn to it in times of confusion and within it find clarity and inspiration. You should keep it nearby and make a point to open it up once in a while.

Take a look at the Scrum Guide™ this week, whether or not you have read it before.

The Performance Consultant as Product Owner

In Scrum, the internal performance consultant is the Product Owner (PO). Clearly defined in the Scrum Guide (scrum.org) and elsewhere, the major responsibilities of the Product Owner are to  (1) define the stories (work items) in the backlog, and (2) put them in rank order. The highest ranked items are those that “maximiz[e] the value of the product and the work of the Development Team.”

The “what” is clear and simple. A significant gap in the definition is the “how.” How does one determine what the highest value work is? Consultants, analysts, executives, process improvement professionals all refer to a body of knowledge dedicated to determining what value is for their profession.  This is where the role of the human performance technologist comes in. In the HR/Education field, our consulting skills are focused on strengthening partnerships, viewing problems systemically, focusing on outcomes, and conducting performance and cause analysis. In agile, we still do all of those things, and we know that the principles of human performance technology conflict those of the Agile Manifesto only in nuanced ways. Thus, if we can quantify the value of our support and inventions, that will go a long way towards creating a backlog whose rank order is credible.

Scrum brings three advantages to the internal consultant:

1. It highlights the importance of doing due diligence on a work item (front end analysis, relationship building) before tossing it to the team. There is a concept in agile called ‘definition of ready’. Each team can create their own definition, but generally speaking, ready means that the team has enough information to do the work; there are no impediments or dependencies in place that would prevent them from doing the work; and they understand what it means to be ‘done’. If the ‘Ready?’ field in the backlog says ‘No’, the team will not (and should not) commit to working on the story.
2. It compels us to make tough decisions about what should be done first. We can only make defensible decisions based on our analysis of the potential value of the work. This quantification of value is an aid when supplying customers with data about the choices they have to make. (I say ‘they’ because in scrum, the customer decides.) Additionally, scrum has processes built in where the team decides how much work they are going to tackle. Starting from the #1 ranked work item, the team will commit to work until they have reached their typical capacity for an iteration.
3. The story-writing format, which articulates the audience, the need and the outcome, reinforces the habit of focusing on employee behavior and results.

Herein lies the beauty of agile as applied to HR/Education and other non-software disciplines. In the case of the internal consultant, it provides built-in curbs on any inclination to forget what we are supposed to be doing.

Why Kirkpatrick Matters

Donald L. Kirkpatrick’s passing last week at age 90 caused a moment of reflection for me. I never met the man, but his ideas have been an ongoing subject of discussion and debate in my professional life.

In a dark and smoke-filled office at a place called Chemical Bank, near Wall Street in Manhattan, I was first told of Kirkpatrick. In my first months as a “training” person, coming off an unsuccessful stint as a high school English teacher, I was taking instructions from a senior member of the training staff on his expectations for me to design the evaluation of a new-hire training program. The man (whose name is long-forgotten) explained to me the four levels of the Kirkpatrick Model:

• Level 1: Reaction. Did people like the course?
• Level 2: Learning. Did they learn the stuff they were supposed to learn?
• Level 3: Behavior. Were they able to perform the skills on the job?
• Level 4: Results. Did the application of the skills lead to improved business results?

The beautiful order and simplicity of the system immediately appealed to me and set off a long-lasting moment of clarity. It was then that I first understood the difference between what we do as school teachers (teach people content, for no apparent reason, other than knowing all of the stuff that all educated people know) and what we do in corporate training functions (teach people skills, for the purpose of doing a job).

Over the years I participated in a number of task teams charged with implementing a Kirkpatrick-esque system of evaluation. Typically, the task team would spend 6-12 months creating a meticulously-crafted standard Level 1 Evaluation instrument (smile sheet, if you will), before running out of steam and disbanding. This very tendency points to the peril of Kirkpatrick – people get so focused on following the Levels one at a time, starting with Level 1, that they lose sight of why they were pursuing them in the first place. My experience is supported by copious research that repeatedly shows that almost all organizations have Level 1 instruments in place, and almost none of them have Level 4 systems in place. This only serves to reinforce the instinct within training types to expend too much energy thinking first of how to make their classes or eLearnings aesthetically appealing or, even better, fun!

My conception of why we train people has evolved considerably in the intervening 20 years. Rather than a sequence, I prefer to think of the Kirkpatrick Levels as a taxonomy. All evaluative activities fall in to two categories: Measures that Training people care about and measures that Business people care about. While there is value in the former, we should emphasize the latter.

I know that Kirkpatrick himself understood this critique and tried to get out in front of it. Today, his family’s company, Kirkpatrick Partners, has consciously clarified and updated the presentation of the original concept in the form of the New World Kirkpatrick Model.

Being misunderstood and over-simplified is a fate that Donald Kirkpatrick shares with Winston Royce, the “inventor” of the waterfall method of managing large software development projects. In 1970, Royce wrote a highly influential paper that is often cited as the basis of the Software Development Life Cycle (SDLC), which today is routinely massacred by agile development enthusiasts. His paper explicitly denounces the end-to-end, one-way street that is waterfall planning, yet it spawned a multi-million dollar cottage industry. Royce and Kirkpatrick both gave the world ideas that were almost too elegant for their own good, so much so that many of those espousing the method only considered the ideas themselves in a superficial manner.

By any measure, Donald Kirkpatrick was a giant in the field of learning and development. His evaluation concept was first presented it as his PhD dissertation topic in 1959, and it was refined in many articles and books in the ensuing 50 years. To those of us steadfastly pursuing the holy grail of correlating training to business outcomes, he has been a constant inspiration.

One Man, Two Conferences

I’m fairly certain that I’m the only person who attended both THE Performance Improvement Conference #ISPI14 and the Global Scrum Gathering #SGNOLA this spring. I hold professional designations from both the International Society for Performance Improvement (CPT - Certified Performance Technologist) and the ScrumAlliance (CSPO - Certified Scrum Product Owner). As one who works as a education person among technologists, I’m interested in considering the distinction between the two conference crowds and the ethos of the attendees.

The conferences themselves were comparable in size, agenda structure, and cost. Both were more of an educational event than a trade show. Both had a lot more good than bad, and both experiences filled my little head with a boat load of information and ideas.

Below are two lists that show how they are distinct. I would love to hear your comments.

Conference versus Conference

Theme	ScrumAlliance	ISPI
Typical profession	External Agile Scrum Consultant	Internal performance consultant
Touted Credentials	ScrumAlliance certifications	Academic degrees
Gender mix	80% male, 20% female	50% male, 50% female
Conference locations	World-class cities: New Orleans, Paris, Berlin	2nd tier cities: Indianapolis, San Antonio, Reno
Book you need to have read or pretend to have read before attending	The Scrum Guide, by Schwaber and Sutherland	Human Competence: Engineering Worthy Performance, by Thomas F. Gilbert
Venue-based Metaphor	Music (New Orleans)	Auto racing (Indianapolis)
Conference groove	Networking	Forming bonds
Most popular tweet	A slide	A selfie
Awesome keynote speaker that had everyone buzzing	Kenny Rubin	David Maxfield
Book giveaway to support the awesome keynote presentation	Essential Scrum, A Practice Guide to the Most Popular Agile Process	Influencer, the New Science of Leading Change
Gadget giveaway	Portable smart phone charger	Thumb drive
Laughing, crying	Almost none	Almost constant
Typical model	Circular and repeating	Horizontals and verticals
Involvement of forefathers of the profession at the conference	None of the original Agile Manifesto signatories present	Almost every living performance improvement guru was present

Ethos versus Ethos

Theme	ScrumAlliance	ISPI
Foundation	Experience	Research
Holy grail	Delivering value	Measuring value
Common reference	Failed software projects	Skinnerian behavioral science
Before becoming a consultant, I spent years as a(n)….	Software engineer	Instructional designer
It all starts with articulation of….	An idea	An outcome
People are….	Resources	The most important thing
Management are….	Adversaries who don’t understand us and how we want to work	Leaders who don’t yet realize how much we can help them
Love/hate relationships	Hate for project managers. Disdain for HR.	Love everyone
About measurement	A lot of talk about things that should not be measured (defects, release cadence)	A lot of talk about what can and should be measured
On Training	One capable person can pollinate specific skills within a specific team	Scalable solutions and support structures need to be put in place
Don’t forget to….	Follow applicable scrum rules	Measure
People love to talk about how nobody talks about….	Continuous integration	Root cause analysis
View of the future	#noestimates	Predictive evaluation
They are snarky about….	Manual testing processes	Training as a standalone solution
Language of success	defect-free, minimum viable, value flow	greater discretionary effort, improved performance, employee satisfaction
Fancy word to describe most problems	Recursive	Unaligned
Fancy word to describe solutions	Automated	Holistic
What needs to be scaled	Coaching	Performance support
What attendees would learn if they attended the opposite conference.	An appreciation for the human component of success	An appreciation for the great learning agility that exists within work teams
And they would also learn	In order to quantify value, you need more sophisticated measurement techniques	People on teams don’t care about corporate interventions unless they have immediate prima facie value