Agile Complexification Inverter

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 '. Maybe it all comes down to improvement, and the need to iterate - to recreate to improve . 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 diagr

The (USA) founding fathers declared that the pursuit of happiness was a right of the people.  So do you have a right to be happy at work?  No.  But you may pursue happiness there as well as anywhere.  And you may wonder if happiness at work will be more productive.  There is not yet enough study in this regard, and the studies of 19th C. work methods like the Hawthorne Studies might not be generalizable to the modern knowledge workers. The Surprising Myths About Happiness at Work  (Inc.com)  A body of research has found that a happy workforce doesn't necessarily equate to a productive one. The Research We’ve Ignored About Happiness at Work (HBR.com) The Science of Happiness  in depth report by Scientific American. The Harvard Life study of Happiness 75 years of it. 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

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 : The Dancing Traffic Light

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

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 Sah

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

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 specificall

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 sticki

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

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 pa