Quick Agile Links #4

December 7, 2009 in Links, Science by Mark Levison

screwdriver

I’m working with a client who runs a documentation team, so I was delighted to discover HeraTech, a  new blog dedicated to applying Agile to Technical Writing.

Preparing for TEDxOttawa this past week, I heard a couple of great talks—Dan Pink on the Surprising Science of Motivation (hint: individual rewards don’t work) and Dan Gilbert on Our Mistaken Expectations (he demonstrates that we’re really bad judges of value).

Henrik Mintzberg revisits Dan’s point to say No More Executive Bonuses!

I love seeing Agile applied in interesting places and seeing how it adapts—so I offer you the Agile Lawyers Association—it seems like a great idea, but the website needs a bit of work.

Michael Sahota visits one of my favorite topics: Joseph Pelrine and “Coaching Self-Organizing Teams,” I wrote about this last year—Coaching Self Organizing Teams and Part II.

Finally, Ilja Preuss gives some great tips on keeping time in a meeting (Agile or otherwise).

Quick Agile Links Week #3

November 30, 2009 in Agile, Links, Science by Mark Levison

This week I’m leading off with a pair of items on the brain and recovering from challenging cognitive tasks: Cognitive Recovery Time and A Dream Interpretation: Tuneups for the Brain (NY Times, login required). The first suggests that your brain needs time to recover after doing something challenging. The second reinforces the importance of sleep and dreams in integrating ideas and information. What does this mean for TEDx attendees next week? I’m not sure except that we presenters will have to work hard to make our ideas stick. I also think it’s a bad sign for the typical two-three day Agile training course.

Joe Little shares his: Agile Principles—examples: all WIP is bad; bad news doesn’t get better with age. You learn the fastest by small mistakes.

Ilja Preuss says something that’s been on my mind for a while: Index Cards are Tools, too!

Johanna Rothmann tells “How Not to Win Friends and Influence People”, and I’m only disappointed that she didn’t name names.

Finally Abby Fichtner reminds us: Agile Leadership: Methodology Ain’t Enough

I’m Speaking at TEDx Ottawa

in Science by Mark Levison

6a00d8341cc2cf53ef0120a6a18bf8970c-pi[1]

It’s just been announced that I’m speaking at TEDx Ottawa (a mini TED—ideas worth spreading) next weekend on my favourite topic: “Learning Best Approaches for Your Brain.” I’m pretty good company sharing the stage with the founder of Bridgehead, a man who has run across the Sahara and many more great speakers besides. I would invite you to rush out and buy a ticket, but attendance is limited to 100 people, and the tickets sold out a long time ago. On the upside, the entire event will be recorded and available online, so you will be able to see all the talks at a later date. Now I’m off to shrink my presentation from its original 90 minutes to the 15 that TED requires.

Learning Best Approaches for your Brain Slide Deck

November 2, 2009 in Books, Science by Mark Levison

go2.wordpress[1] As regular readers of this blog will know I’ve given a talk based on reading’s in Neuroscience, called “Learning Best Approaches for Your Brain” – several times this year (Agile 2009 and Agile Ottawa). After several requests I’m posting the slide deck (pdf) here – but I’m afraid that it will really only be useful to the people who attended the talk. Here’s the promo I’ve been using:

Do you mentor, coach, teach or just help other people? Do you wonder why after your greatest teaching moments people just don’t get it? In recent years neuroscience has started to provide us with a number of insights into what happens when we’re teaching. These insights make it clear that learning is really about building and reinforcing existing neural networks. Instead of providing lots of new ideas out of the blue, we need to understand the learners existing context and work with that. Instead of focusing on mistakes and errors, we need to focus on what good solutions look like.

Top 5 Reasons that traditional approaches to learning and mentoring fail:

  • Lead with the Abstract
  • Not Grounded in the Listeners experience
  • Passive students – i.e. Those just listening and taking notes, aren’t using all of the brain. They retain knowledge but don’t really understand it.
  • Rewards don’t work
  • High Fructose Corn Syrup

Benefits:

  • Students and Mentees will remember
  • Learn how to correct mistakes
  • Workshop Attendees will stay awake

References:

I promise that sometime in the next month or so I will publish the paper that Linda and I originally promised (threatened), that will include all of the details missing from slide deck. The only caveat no paper will every be as good or help you learn as much as an interactive, example driven presentation.

Download: Slide Deck (pdf)

Caveat Emptor – if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

Why Scrum Works??

July 4, 2007 in Agile, Science by Mark Levison

In the previous two posts in this series we examined how Scrum provides value to business and why Scrum helps to form high scrum performance teams. This post continues the second theme examining the remaining elements of Scrum.

Artifacts

Product Backlog

Basics: The product backlog is a prioritized list of features of everything needed and wanted in the finished product. To minimize waste only the next few iterations worth of stories are provided in any detail. The list is maintained by the product owner.

Values Supported:

  • Visible Long Term Goal

Does Scrum Work? Hell Yes!!! Why

June 26, 2007 in Agile, Science by Mark Levison

This is the second post in a series (thanks Mishkin for hosting the opener) – that discusses: Why does Scrum work? Why do any of the Agile Project Management methodology work?scrum Final part here.

Teams

At the core of any successful development project is a team. The team can either work together as a group of individuals or as a high performance team. A high performance team is one that has a track record of both delivering high quality software and meets or exceeds their iteration commitments. 

Nothing can guarantee the creation of high performance teams. The best you can do is put in place the conditions that will help them form.