Why I use Flip Charts not PPT Slides

Want to retain something you just heard - draw a doodle.

Want to engage learners - get them active.

Want to teach someone a skill - have them teach you.

Want to change some behavior - make it fun.

In all of these techniques the trick is to invert the traditional training paradigm.  The classroom was created to process children with unique talents into factory workers willing to follow directions of an authority.

Doodlers, unite! Sunni Brown on TED.com




Read Sharon Bowman's 'Training from the BACK of the Room!'.

Don't think you can doodle - come out of the closet with these techniques from Dan Roam 'Back of the Napkin'.

One can not doodle on the power-point slide one the screen. One can not quickly annotate a burndown chart in that spreadsheet (a learning moment). One can not give the marker to a participant and have them draw a diagram on your slide deck. You do not get their mental model of the problem domain when you show them your perfect architectural layer model. While sitting in perfect rows and columns the students are not allowed to engage with each other - only by signaling the authority (raising a hand) may the student (receiver of info) become active in the dialogue. Is that fun?

I encourage people to mark on the charts and diagrams on the flip charts - they really are not works of art. They do not have to be treated like paintings hanging in a museum. I've gotten in "trouble" for annotating (with sticky notes) a poster hanging in the work place. Oh-my, it started a conversation about the topic, what is wrong with that?  I didn't draw a mustache on the Mona Lisa.

If the traditional paradigm is not working - try an inversion principle.

This RSAnimate video was adapted from a talk given at the RSA by Sir Ken Robinson, world-renowned education and creativity expert.

How Happy Are You?

The Science of Happiness in depth report by Scientific American.

Learn the latest psychology behind why it's hard to be happy, and take the quiz to learn how your contentment compares to that in other cultures.

Scientific American

"Happiness varies not only from one person to the next but also from one country to another. (For more discussion of happiness around the world, see The Many Faces of Happiness.) Psychologists measure happiness in several ways. One approach involves the extent to which you experience positive versus negative emotions. Another assesses life satisfaction, or how pleased you are with your life as a whole."

Quiz: How Happy Are You?: Scientific American:

Change is easier with FUN!

OK - I've got to remember to bring the FUN. That's what empowers changing behaviors. Not Power-Points, not mission statements, not a list of 10 things you don't know, not a study done at Stanford. It's pure Fun!

100 Things You Should Know About People: #13 — Want To Change a Habit? Use Fun, Surprise, and a Crowd | What Makes Them Click:

What belongs on the Task Board?

I wonder about these questions a lot - what types of task belong on the task board?  Does every task have to belong to a Story?  Are some tasks just too small?  Are some tasks too obvious?  Obviously some task are too larger, but when should it be decomposed?  How will we know a task is too large?

I answer these questions with a question.  What about a task board motivates us to get work done?  The answer is: T.A.S.K.S. to DONE!

Inherent in the acronym TASKS is the point of all tasks, to get to done.  That is the measure of if the task is the right size.  Does it motivate us to get the work done?  (see notes on Dan Pink's book: Drive - The surprising Truth about what motivates us) If we are forgetting to do some class of task then putting it on the board will help us remember.  If we think some small task is being done by someone else, then putting it on the board will validate that someone else is actually doing it.  If a task is obvious, then putting it on the board will take virtually no time and promote the well being of getting things done.  If a task is too large it will never move to done.

Sisyphean - adjective (of a task) such
that it can never be completed.

I walked up to a task board just this week and saw a set of Sisyphean Tasks.  It was a signal that the board would not be helpful.  No flow would happen.  The task would get to In-Process and stay there for life.  What information would radiate from this board?  A static task board sends the one signal - we don't know what we are working on, and we can't tell you.

The solution for this group was to realize that those epic tasks were a story or a class of work and after reforming the task board a bit, we made a minor improvement.  Hey, that's what it's all about. 

Oh... no, maybe that's the Hokey-Pokey.

Thinking about company culture

What does a company culture (wikipedia's definition) tell you about their Agility?


When I think of culture and models to describe these very complex human dynamics I think of the song "Hair Styles and Attitudes" by Timbuk 3.  In this song they sing of how scientist have categorized our attitudes into 3 basic types (a model of attitudes).  This is the Three Stooges model of attitude.  I liked this model so much that I created a slide show of my company's people as a prelude to a project retrospective.  This project had a clash with the client culture.  The project ended, but I'd have to say it didn't end pretty.  It did not end in a win-win situation.



Slide show of Hair Styles and Attitudes

Would some coaching from Lysaa Adkins on team conflict have save the contract?  Boy, I wish we would have know about it and tried.

Navigating Conflict on Agile Teams: Why Resolving it Won't Work

One of the best blogs on the topic is Michael Sahota's Agile Culture Series Reading Guide.
Michael uses the Schneider Culture Model to describe efforts to transition a culture.

This is a reading guide to the series that explores corporate culture and how that has a direct impact (sometimes very negative) on efforts towards Agile adoption. It is a must-read for anyone that is considering taking their company agile or for coaches and consultants whose trade is based on Agile. The role of Kanban is quite distinct and is discussed throughout.

References:

“That’s the Way We Do Things Around Here”: An Overview of Organizational Culture by M. Jason Martin

The Reengineering Alternative: A plan for making your current culture work by William Schneider.

How we do things around here in order to succeed.  Agile 2010 conference session by Israel Gat.

How to Find Out If the Company's Culture Is Right for You by Whelan Stone

The 25 Smartest Things Steve Jobs Ever Said

By Morgan Housel on The Motley Fool

[Reposted without permission - hey I'm an Apple Fan Boy - sue me.]

Steve Jobs and I quote:

25. "Being the richest man in the cemetery doesn't matter to me. Going to bed saying we've done something wonderful ... that matters to me."
24. "I read a study that measured the efficiency of locomotion for various species on the planet. The condor used the least energy to move a kilometer. Humans came in with a rather unimpressive showing about a third of the way down the list ... That didn't look so good, but then someone at Scientific American had the insight to test the efficiency of locomotion for a man on a bicycle. And a man on a bicycle blew the condor away. That's what a computer is to me: the computer is the most remarkable tool that we've ever come up with. It's the equivalent of a bicycle for our minds."
23. "In most people's vocabularies, design means veneer. It's interior decorating. It's the fabric of the curtains of the sofa. But to me, nothing could be further from the meaning of design. Design is the fundamental soul of a human-made creation that ends up expressing itself in successive outer layers of the product or service."
22. "I'm as proud of what we don't do as I am of what we do."
21. "We don't get a chance to do that many things, and every one should be really excellent. Because this is our life. Life is brief, and then you die, you know? And we've all chosen to do this with our lives. So it better be damn good. It better be worth it."
20. "My model for business is The Beatles: They were four guys that kept each other's negative tendencies in check; they balanced each other. And the total was greater than the sum of the parts. Great things in business are never done by one person; they are done by a team of people."
19. "The system is that there is no system. That doesn't mean we don't have process. Apple is a very disciplined company, and we have great processes. But that's not what it's about. Process makes you more efficient. But innovation comes from people meeting up in the hallways or calling each other at 10:30 at night with a new idea, or because they realized something that shoots holes in how we've been thinking about a problem. It's ad hoc meetings of six people called by someone who thinks he has figured out the coolest new thing ever and who wants to know what other people think of his idea. And it comes from saying no to 1,000 things to make sure we don't get on the wrong track or try to do too much. We're always thinking about new markets we could enter, but it's only by saying no that you can concentrate on the things that are really important."
18. "I wish [Bill Gates] the best, I really do. I just think he and Microsoft are a bit narrow. He'd be a broader guy if he had dropped acid once or gone off to an ashram when he was younger.''
17. "My self-identity does not revolve around being a businessman, though I recognize that is what I do. I think of myself more as a person who builds neat things. I like building neat things. I like making tools that are useful to people. I like working with very bright people. I like interacting in the world of ideas, though somehow those ideas have to be tied to some physical reality. One of the things I like the most is dropping a new idea on a bunch of incredibly smart and talented people and then letting them work it out themselves. I like all of that very, very much."
16. "Innovation has nothing to do with how many R&D dollars you have. When Apple came up with the Mac, IBM was spending at least 100 times more on R&D. It's not about money. It's about the people you have, how you're led, and how much you get it."
15. "Your time is limited, so don't waste it living someone else's life. Don't be trapped by dogma -- which is living with the results of other people's thinking. Don't let the noise of others' opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary."
14. "You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new."
13. "A lot of times, people don't know what they want until you show it to them."
12. "We're gambling on our vision, and we would rather do that than make 'me, too' products. Let some other companies do that. For us, it's always the next dream."
11. "The cure for Apple is not cost-cutting. The cure for Apple is to innovate its way out of its current predicament."
10. "A lot of companies have chosen to downsize, and maybe that was the right thing for them. We chose a different path. Our belief was that if we kept putting great products in front of customers, they would continue to open their wallets."
9. "When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can often times arrive at some very elegant and simple solutions. Most people just don't put in the time or energy to get there."
8. "That's been one of my mantras -- focus and simplicity. Simple can be harder than complex."
7. "We didn't build the Mac for anybody else. We built it for ourselves. We were the group of people who were going to judge whether it was great or not. We weren't going to go out and do market research. We just wanted to build the best thing we could build."
6. "Be a yardstick of quality. Some people aren't used to an environment where excellence is expected."
5. "We've never worried about numbers. In the marketplace, Apple is trying to focus the spotlight on products, because products really make a difference. ... You can't con people in this business. The products speak for themselves."
4. "You can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something -- your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life."
3. "Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn't really do it, they just saw something. It seemed obvious to them after a while. That's because they were able to connect experiences they've had and synthesize new things. And the reason they were able to do that was that they've had more experiences or they have thought more about their experiences than other people."
2. "Sometimes life hits you in the head with a brick. Don't lose faith. I'm convinced that the only thing that kept me going was that I loved what I did. You've got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven't found it yet, keep looking. Don't settle. As with all matters of the heart, you'll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don't settle."
1. "Stay Hungry. Stay Foolish." * not by originally by Jobs.

*  Stewart Brand - The Last Whole Earth Catalog. Jobs noted Stewart Brand in his Stanford speech.

What are the Principles?

The agile reboot is underway... the company says it is using "Agile" yet there is no methodology/process/framework that defines "Agile" is there.  So it is not a very valid statement to say we do Agile.  Agile is a philosophy - defined by 4 comparative value statements and 12 principles.  So the top-dog rightly focuses the company on one well defined Agile process - Scrum.  Great move for a change initiative.  Focus is going to be important.  Now we need to discriminate the change - what is it that we want to quit doing and what do we wish to start doing?  We must label these things.

Three of the 12 principles of Agile with engineering
practices mapped to them (TDD, Pair Programming, etc).
When we tried to map our existing practices - we found
we didn't have very many disciplined practices, so this
is a mapping of a desired future state.

Typically it is easy - one applies the Waterfall label to the old and the Agile or Lean label or more specifically Scrum/XP or Kanban to the new.  That has worked for me in the past very well.  But what to do when it doesn't work?  What to do, if the company has brainwashed itself into thinking it is practicing Agile.




I must resist the Stockholm syndrome. That culture of just get it done - is not a process - and by any definition of the word - it is not Agile.

But then perhaps in a moment of desperation they look around and ask - "what are the principles"?  What is the foundational philosophy of this Scrum process?  We want to know these so that we will know where we can customize this process.  We want to know what we can bend, what we can circle around - how can we keep doing what our culture dictates and just install the scrum.

Agile Culture Series Reading Guide Written by: Michael Sahota

How many times does a process get broken before it is tried - before it is adopted - before any experience what-so-ever with the designed process, we say "we can't do that - we must change it" - not our selves - we change the process.  We all know that it is easier to change something else than it is to change ourselves.  So we search for the exceptions that will prove the case that process step 23-C will not work here - we have decided that we are so special that the Sun actually revolves around us.

Scrum designers have done a wonderful job of defining a very small list of things that must be done - if you do them - then you are doing Scrum.  If you break the rules, bend the framework to suit you special case - well then do you think you will get the desired outcome?

So that first question of what are the principles may be more subversive than it appears.  Because if you slip up and define a gap in the principle fabric then there will be a hole for the monsters to slip back through.   Given that I'm not going to be able to articulate each principle and you will not quite understand my meaning just perfectly.  Is this not a slippery slope.

So if you want to customize your process - one that has been built/designed/tested/refactored over years by experts - and you think you are qualified to state when we can just re-jigger this piece, skipping that piece, it is just a waste, never understood it anyway, so we'll just do it our way.  Well I don't want any part of your bastardization.

If you want the principles - they were stated - as best we have found in the Manifesto.  Don't re-invent the principles - just re-use them.  Have we not learned this concept yet.

Exercise :: Mapping Engineering Principles to Agile Practices
(PDF) by David Koontz

 

Trusted & Motivated People - a label for
one of 12 Agile principles is well supported
by 5 practices.

Jay summing up 'User Stories' supports 7 principles

David Koontz
Pointing at the root of our principles
Agile Manifesto

Lovely space at Microsoft NERD center.
Mapping Engineering Practices to Agile Principles at
Agile Games 2011 in Cambridge.
Note circular whiteboard - awesome!

Another Exercise:  The Definition of Done & Ready!

Another Info-Cooler bites the dust.

Built another Scrum task board today for a team.  I first described it on the whiteboard, and a bit about how it worked, how we could choose vertical story and status columns or horizontal - gave them the choice.  We could start with the simplest thing that might work - 3 states (ToDo, In process, Done) and add states if needed (another choice). 

The simplest thing that could possible work.
A Scrum task board (ToDo, In Process, Done).
Tasks flow down the page.

I gave my standard disclaimer - the first version was going to be designed to be thrown away - so bad that they would have to re-do it to make it better.  That's a trick I've learned to sell them ownership of their board.  After a few mock examples on the whiteboard they were getting restless and wanted action.  They bought it.  Sold!

After 6 flip charts got pasted to the wall (3 h. x 2 v.) and a bit of labels and lines - we ran some examples of what it might look like with Story stickies and Task stickies.  Then we played a simulation standup for a few simulated days.  The simulation worked wonderfully.  They got into the make-believe and started adding to the Improv.  I was switching hats - Coach... ScrumMaster... Team Member with a really bad performance record on a task.  They improv-ed some situations and  one or two really great question later we had a team that was going to learn Scrum the old fassion way - by doing it.  No powerpoints, no death by bullet points, just good old Polish hard work and positive attitude.

I did pull out one acronym and we talked about homonyms (I'm from the south so my dialect allows me to pronounce 'pen' == 'pin' - but they are Polish and it all sounds English to them).

T - those
A - awesome
S - stickies
K - keep
S - Sliding to DONE!

That's as close to a slide as we got.

Sorry Rally/VersionOne/etc. - that's a three person team that is not going to use your Information Cooler.

Video at 11.

Queen - Another One Bites the Dust. 

Scrum Task board loaded and in action.
A Polish Impediments list on the right wall.

How do we form teams?

One question that is constantly coming up is this one – How do we form Scrum Teams?

Here' my opinion – and blunt answer:

It does NOT matter what team you form the first time you will get it wrong!  So what matters is HOW you plan to re-form the teams.  Rather than assuming you can get the correct solution – figure out a way to work toward a better solution.  This is applying the concepts from Complex Adaptive Systems (CAS) the great grandmother of Scrum.  Almost any system with a human is going to be complex – the question is – will it be adaptive.  FIRST - Plan to form your second team – how will you reform teams.  Then it doesn't so much matter what the first (and obviously wrong) team is – you will have a way for that team to decide when & how to reform into a better team.   So now we need some ideas about what might decided when and what might decide who and what might be a measure of good & bad and good enough the criteria by which the team decides to reform.

So I'm not going to tell a group who should be on what team.  I them to realize there is not a perfect answer – but we do have principles!

What are those principles?  Come on – dig deep – what principles can we draw upon to define Scrum teams?



Here' some background on this – if you want to have an informed opinion about Scrum and team formatting – this is a great place to start…
http://featureteamprimer.org/

Simulations are tools for fun.

If you want to learn a new skill, create a safe simulated environment in which to practice.  I feel this is a lost technique for most technologist.  Perhaps it is too easy for us to just start writing some new module in a new language just because we wish to learn.  We think that we will just solve the real world (work) problem at the same time.   I learned of this case recently.

A developer used their work environment to learn a new skill.   In this case the programmer decided to learn design patterns.  So to do this he started applying every design pattern he could to the application he was working upon.  Now, if you imagine this is a beginner at the technique of pattern application then you may imagine that he may have gotten a bit carried away.  And that is what I've heard happened.  Now the code has nice fancy patterns, some quite complex and many are used just to experiment with the pattern.  This happens to be code that is sold to clients, and the over exuberant use of patterns have made the code worse, and harder to maintain.  Quite the opposite of the intent of design patterns.  In fact had the programmer learned his subject well, he might have found that he was applying the 'cargo cult programming' anti-pattern.

What interest me is why this happened.  Why did the programmer feel the need to learn patterns.  Why did he apply them to the clients code base (application) while he was learning?  Why did he not have a 'safe' sandbox to learn and play within.  Why did the company allow this behavior - perhaps they encouraged it?

I think many of these root cause issues come down to a human need to learn, and that learning needs to take place in the appropriate place and context.  In this example case the developer had a context (the work environment and the companies application code).  But, clearly, this was not an appropriate place to learn this skill set.

What would happen if the developer had a sandbox that he could apply those skills he wished to learn and they after a few experiments with design patterns he would take that new knowledge to the actual work?  This is a concept used in so many other industries, yet in an industry where creating virtual worlds and models are our forte, we don't use them for our own learning.  We learn on our clients new application.  A common behavior pattern is to learn the next skill needed by gold platting the current application.

Why not have a simulation-lab where this type of learning may take place?

My sister-in-law is in town to do a sailing level II course (she is skipping the level I - so that she can get certified to go on a training cruise in a few months)  She has never really sailed.  She has studied the books, knows all the equipment names, parts of the sail boat, she can talk like a pirate.  But, there is some part of sailing that is experience.  Knowing which way the wind is blowing just by the pressure effects on the hairs on your body.  And the spacial relationships of the sail, boat, and wind - not to mention the difference in apparent wind, true wind, apparent velocity, etc.   Being expected to captain a boat for the first time can be a nerve wrecking experience.  Why not simulate this experience.

My wife created a mock up sail boat, a small model.  A cardboard boat and a mast with a plastic sail.  A little fan provides the all important wind.   Switch it on and the simulation is underway - the learning begins.  Sailing - like Scrum - is an empirical game.  In sailing one measures the wind and always adjust to the wind's force and direction.  Everything is relative to the wind.  They spend the afternoon learning to sail in the simulation of the apartment.  When the model doesn't provide the proper scale for the next lesson, a bit of refactoring on the mock up leads to the swiffer mop becoming the mast and the coffee table becoming the boat.  This time the model is complete with main sail and jib.  Now the simulation has taken on a complex relationship and there is no risk of capsizing or running aground.


When learning becomes experiential and fun humans retain more.  We don't just learn in our heads,  We use the whole body to process and store information.  Remember the reference to body hairs.  Yes, those tiny little hairs are how we know the direction and force of the wind.  We have to learn to process the signals they are sending and map that sensory information onto the model of how a sail boat converts wind into propulsion.  When a person has done this a few time, even if it is in a living room, they know how to sail.

So why are we in the high-tech industry not creating simulation labs?  Why don't we have a Matrix Construct, where we down load an application that needs some refactoring and a few patterns applied.  This simulation would not be the clients application code.  But a reusable learning environment.  If we value learning, and we better, because in the 21st century the modes of wealth creation changes - it is not how much you can produce, it is how much you can learn, and apply that knowledge.