Several people have asked if I’ve fallen off the face of the earth recently, well not quite. However along with being busy with client work I’ve been preparing my two Agile 2010 sessions with Roger Brown:

Wednesday, August 11, 1:30 – 3:00pm

Learning Best Approaches for your Brain

Do you mentor, coach, teach or just help other people? Do you wonder why, after what feels like your greatest teaching moments, some people still don’t get it? Neuroscience has started to provide us with insights into what happens in the learner’s brain when we’re teaching. Learning is really about building and reinforcing existing neural networks. Instead of providing a lot 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, sound and feel like.

See the recent article on InfoQ: The Science of Learning: Best Approaches for Your Brain, for a taste of the session.  Since its after lunch again, please consider avoiding High Fructose Corn Syrup (i.e. most desserts in North America). See: Diet-induced insulin resistance impairs hippocampal synaptic plasticity and cognition in middle-aged rats.

Thursday, August 12, 9:00 – 10:30am

Continuous Creativity for Agile Teams

Creativity can manifest in several ways including creation of something new, refinement of something that exists and problem solving. How do we support, enable and enhance the creative abilities of Agile teams? There are many ways to shape the work environment for greater creativity. We will present a summary of the literature that describes how creativity can be enhanced by providing a safe, nurturing environment, enhancing group interactions, pacing activities that utilize different sensory modes and trusting in the power of subconscious integration.

I know this will be a tough morning after the Wednesday night parties (i.e. Rally, VersionOne and Cyrus Innovations), I promise this will be worth waking up for.

Courtesy of a few hours delay from Ottawa to LaGuardia, I have some unexpected time to write a Quick Links.

I’m always explaining to clients the problems with traditional Test Automation approaches. With Why Test Automation Costs Too Much Elisabeth Hendrickson explains why Test Last will always fail. Now she just leaves the job of explaining what to do instead.

Derek Huether found an awesome Scrum Intro Video (by Hamid Shojaee, Founder and CEO of Axosoft) – its only 8 minutes long.

Odopod is an online sketch pad, I’ve not spent enough time playing yet but it has support for animation. Might be a great tool for users of Dan Roam’s “Unfolding the Napkin” and Dave Gray’s  “Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers” (Caveat Emptor I only just discovered Dave’s book today and so haven’t read it yet).

Hiring for a Collaborative Team from Esther Derby has a great set of ideas. I would only add one I recently hear from Pascal Van Cauwenberghe in an email to the agile games list where he describes introducing a potential hire to his company by playing the XP game with them.

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.

For the past year every time I give my “Learning Best Approaches for Your Brain Talk”, I’ve promised there would be an article on InfoQ. Well I kept to much work in progress and this week I took care of that problem and we’re live: The Science of Learning: Best Approaches for Your Brain

I’m frequently getting requests for good Agile Metrics and I’m never quite sure how to respond. Courtesy of some time waiting at LGA, I’ve been giving this some more thought. For many organizations metrics are irrelevant, don’t bother collecting them as they will just waste your time (and money).

If you must collect metrics, here is what I would consider.

Running Tested Purchased Features – Ron Jeffries is famous the metric Running Tested Features (RTF). I suggest that you consider taking it one step further until you’ve sold the feature to the customer you don’t know if they value it or not. For most product organizations this is a bit of stretch to measure in which case stick with Ron’s advice.

Questions to ask:

• What would you like to change?
• If you had the information the metric provided what action would you take? Can you take that action now without the proof of the metric?
• Your key measure (i.e. RTF), should measure your widest span of control – Sold Features > Deployed > Automated Acceptance Tests > …
• Measure Cycle Time – i.e. how long it takes to get something done and not people.
• Other measures can be used: i.e. test coverage from Unit Tests, but be careful they might measure what you think they mean.
• Measures can be gamed/fooled (intentionally or otherwise): For example test coverage measures whether or not a line of code has been visited. It doesn’t measure if there its meaningfully tested. If you must use a measure like this pay attention to the trend and not the absolute number. In this case a large jump might indicate someone having written a not very useful test of the outside api of your application.
• Metrics have best before dates. Eventually you will stop getting real value from them. At that stage throw them away.
• Ask can I get this information by walking around, observing and asking questions.

Alright you made it this far you deserve some options:

Martin Fowler says: CannotMeasureProductivity. Dave Nicolette presented on this at Agile 2009 (this article links to heaps of others). I wrote this for InfoQ last year:  What is a Good Agile Metric?. InfoQ also has: Metrics in an Agile World.

The following tools will help you measure, but please remember they often have many bad measures (comments?) turned with the good ones. Think carefully when choosing your rulesets:

• Sonar – has a bunch of interesting measures: Cyclomatic Complexity, Duplicated code, … . While there are other plugins, its of most use in the Java world.
• JDepend – helps you spot good vs. bad dependencies.
• PMD, FindBugs, JLint – see a comparison of all three (pdf). Some of these tools check some pointless things: method name too short or too long? missing Javadoc comments? Please configure these with the help of a grown adult. But they can also be configured to spot methods (> 30-40 lines) and classes (>300-400 lines) that are too long.
• NDepend like JDepend and heaps more measures. Again please be careful configure only with an adults help :-) Caveat Emptor I’ve been given a free copy of NDepend (that I’ve never had a chance to use).
• Sonar for C# – yes according to StackOverflow.

When paying attention to measures of the code, what matters is the trend and not the absolute numbers. Finally just because a tool can measure it doesn’t mean its worth measuring, conversely some of the best measures don’t have tools to measure them. In this case note that none of the above tools measure cycle time.

Updated to make clear the point that you shouldn’t measure people and the limitations of tools.

Its been a busy few months since I last did one of these.

Whenever I collaborate on a presentation, article or some other activity where I can’t see the person I’m working with I use an online post it note tool (i.e. lino.it). Every tool I’ve used so far has some small annoying limitation so I was recently happily surprised to discover Edistorm via @GerryKirk and Hillary Johnson.

In “Mechanical Agile” Daryl Kulak tells five fictional (I hope) stories of teams went from be Agile to Fragile. Very funny as long as these are not your problems.

With “Agile: Not Just for Software Development Anymore” April B. (no last name) described the transition of the DAXKO Association marketing team to Agile.

James Carr describes his experience “Using Innovation Games as Retrospective Activities”. Interesting, I’m currently exploring Innovation Games so this comes at a timely juncture.

Roger Brown has two items this week: “Adventures in Accelerated Learning” which provides a couple of interesting and timely challenges. “Multitasking Gets You There Later”.

Your project schedule says that you will get 2 more team members this week and 3 more next month. How do you integrate them into the team? How do you bring them on board? How do you avoid slowdowns? In a word you can’t avoid the slowdown – adding new people to the project will slow the existing team down.

On any project it will take from 2-4 months for the team to integrate a new person and recover from the slowdown:

• The person will need to be trained: In your code base, how your application works, what coding style is, how you application works, …
• This person will disrupt the Teams Formation (see Tuckman’s model of team formation) – this is an especially important cost when the team has already reached the performing stage. This happens because the new person alters communication paths and will force people to renegotiate relationships around the entire team.
• The person will be a drag on the team requiring support to learn new tasks.
• The person will increase the communication complexity (i.e. the number of communication paths) within the team.

All of this leads us to discover Brook’s law: “adding manpower to a late software project makes it later” (from the Mythical Man Month 1975, reprinted in 1995). The physics of people hasn’t changed in 35 years.

So what can you do to solve this problem?

• Say no – if its too late in the project – in many cases 4-5 months before release is too late.
• Can’t say no consider what Project Udall (Surviving Object-Oriented Projects Alistair Cockburn, p20) did: Halt the big project, start a small project and add only the people who can contribute to its success to the new project. While its expensive to have people sitting idle, it may be cheaper than having them slow the project down.
• Bring on all the new people at once so at least you pay the costs once in the life of the project as opposed one person at a time.
• Create a new team staffed by the new people with one or two old timers. They won’t get very much done for a while, but at least they get in the way of the others.
• Get them to help with the exploratory testing, with the focus being the stories that are being written in that Sprint of iteration.
• Ask them to write or refactor some automated acceptance tests.
• Get them to read and write Unit tests – start by reading existing Unit tests, after all these should explain the code. If they’re not already Good Unit Tests then take the time to improve. If they’re good then do some small refactorings in the main code base – after you can trust your tests can’t you :-)
• Ask them to pair with another developer

Just remember adding more people to a project is a way of slowing your project down.

A recent challenge has made me realize that some things I thought were implicit need to be made explicit.

If you hire me to do some coaching, training or any other work you can be assured that your name and company name will never appear in my blog, twitter or any other public place. The most I will do is mention your name in private conversation. I will only violate this with your explicit permission i.e. we write an Experience Report for a conference. I will occasionally discuss issues that I see at a specific client in a general fashion, but you should find no specific mentions of your business. If you feel I’ve made a mistake contact me and I will correct it as quickly as possible.

If I hire you do some work on behalf of me or my business, I expect the same courtesy. I expect that all discussions whether over email, Campfire, IM, … are private and are between the originally agreed on parties. I don’t expect to see our discussions played out on your blog.

In general if we have a discussion privately over email (whether or not we have a business relationship) to be kept in the strictest of confidence.

If I discuss something on this blog or a mailing list, Yahoo/Google/LinkedIn groups then feel free to quote me. If you’re feeling generous please tell (so I can respond) and link to this site.

The only gray area is twitter, while its fun, all the ideas I and anyone else express are context free. 140 chars is cute, but no more. If you want to quote or think my ramblings unclear please take the time to contact me, I will be delighted to clarify.

I employed foliovision early this year to help:

• Port my old typepad blog to Wordpress
• Make some small changes to my WooTuits theme two support two domains (the original notesfromatooluser.com and the new agilepainrelief.com)

So far so good. They did that very well and made some other small changes as well. As it happens foliovision is also a design firm and they offered to design a logo for me. Naively I didn’t ask about price up front. Very quickly the price of the logo jumped to be approximately half as much again as the originally quoted price for the job. I asked them to stop work on the logo and on reflection realized that the pill they showed in front of the logo didn’t reflect my ethos. My approach to coaching and consulting isn’t swallow a pill and it isn’t one size fits all. I work in an adaptive, iterative fashion in keeping with the “Inspect and Adapt” principle of Agile. Instead I created my current logo: a person carrying a doctor’s bag because its closer to reflecting me.

I also promised the people at foliovision that I would eventually write a followup post to thank them for time and to recommend them to others. Unfortunately I haven’t gotten around to that.

Imagine my surprise when I noticed a blog post that mentioned me by name, discussed my business choices and denigrated my own logo. I contacted folivision to raise my concerns but they were dismissed. I would quote Alec’s remarks to me in private, but that would violate my promise above. Suffice it to say I can no longer recommend foliovision since you don’t know whether they will treat your discussions with any confidentiality.

To be clear I acknowledge that this site needs some design work, its on my backlog. At the end of the day I put more time and effort into helping clients, personal contact and writing. Less into the site itself.

Continuous Improvement and Short Feedback loops (think: Test Driven Development; Sprint Demo/Review; …) are at the core of any Agile process. Without a structured improvement process it can be difficult for teams to improve and without improvement we stagnate. For methods like Scrum, XP and et al Retrospectives are that tool.

What is a Retrospective? It is a moment for the team to stop, breathe and take a break from the day to day grind. Its a chance to step back and reflect on the past iteration. To find things that worked well, things that need improvement and what the team has the energy to improve.

How do Retrospectives differ from Post Mortems (see CIO Update and PragmaticSW)?

• Post Mortems occur after the project is done (or even dead), when it’s too late to improve that project.
• Post Mortems are long feedback loops, once per project might mean every 6-18 months
• Post Mortems often generate nice reports that are placed on a shelf and ignored (also called write only documentation).
• Post Mortems sometimes turn into blame and shame events.

Well run retrospectives provide an opportunity for small improvements. The keys to a well run Retrospective:

• Retrospective Prime Directive (Norman Kerth): “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” The key here is to remind participants at the start of every retrospective this is not a blame and shame. Its about understanding what happened in the course of the last iteration. The focus is on events and not the people.
• A clear agenda – a simple one:
  • What happened in the last iteration (including what SMART goals did we achieve?)
  • What would like to celebrate/remember/…
  • What areas need improvement?
  • What do we have the energy to improve in the next two weeks?
• Clear Ground Rules see: Meeting Ground Rules Updated
• An Open Mind from all team members with the focus on solutions and not the problems.
• Appreciations – just take a few minutes to share something that you really appreciate that someone else on the team did. Interesting twist I just noticed that Ellen Gottesdiener puts appreciations at the beginning of her Retrospective. That’s very interesting, that will help put people in a positive frame of mind and make it easier to tackle the problems later. Elegant.
• Once you decide what you have the energy to tackle, set SMART Goals (Specific, Measurable, Attainable, Realistic/Relevant, Timely). See: SMART Goal Setting. In the context of an Agile/Scrum team I would always make timely less than two weeks, so that you check back in the next retrospective.
• A great facilitator who is able to stay out of the conversation and maintain the flow. Bring an outsider in occasionally, just to see a different approach.
• Mix-up your retrospective activities to maintain the energy and interest
  • Agile Retrospectives: Making Good Teams Great by Diana Larsen and Esther Derby,
  • Timelines and Mad/Sad/Glad:  (lots of other good retrospective ideas too)
  • SaMoLo (Same of; More of; Less of)
  • Retrospective Wiki

Follow-up:

• Post your SMART goals on the team’s Information Radiator and check up on them in the Daily Scrum.
• If you don’t make the improvements that people choose then Retrospectives will quickly lose their value as people say: “Nothing ever happens from these”.

When: At the end of every iteration or sprint. Allow one hour for every week of iteration. So a 1 week sprint would have 1 hr, 2 weeks a 2 hour retrospective. 3 weeks a 3 hour retrospective, 4 weeks – no one does those anymore right?

Who: The whole team – I like to see (or hear) the Product Owner and the Scrum Master. Some people will tell you that the PO isn’t necessary. Fine, but if they’re not there they can’t help make things better.

In the past two days I’ve presented “Learning Best Approaches for Your Brain” to two audiences. First in Toronto for XPToronto and then Quebec City for AgileQuebec. We got fair sized audiences for each and both groups seemed to have a lot of fun. Given my lack of French I’m truly amazed about how engaged the Quebec audience was – neuroscience doesn’t transcend language barriers easily.

I would to thank  the organizers of XPToronto (Lawrence Ludlow, Michael Sahota, and anyone else I missed) you created a great evening. I would especially like to thank Lawrence for picking me up from the airport and bringing me into Intelliware for the day.

I would like to thank Karl Metivier for remembering me from Agile2009, inviting me to Quebec City and driving to pick me up. I would to thank Louis-Phillippe Carignan, Alex and George (sorry I didn’t get last names), for organizing Agile Quebec and growing it, to its current size.

I was asked for my current slides, even with the notes they’re not very helpful. Nonetheless here they are: Learning Best Approaches for Your Brain.

Finally after the presentation I was made aware that I hurt (emotionally) one of my attendees. During my survey he said that he “wanted to learn about Agile”, I wanted to say that this presentation wouldn’t help, but that isn’t what he understood. He felt attacked. Later on I made use of his example again, I can’t remember what I said. He felt attacked again. I apologized in person and he said he didn’t buy it. I accept that. This is my public apology. I pride myself on being a ‘human focused’ Agile coach and obviously didn’t live up to my own standards. For that I’m truly sorry.

I will speaking at XPToronto on Tuesday May 18th at 7pm and Quebec City on the following evening at 6pm. Hopefully I can visit Montreal and Waterloo another time.

Do you wonder why people don’t understand the idea you’re trying to get across in a meeting? Are you mentoring another developer and struggling to understand why the still don’t get it? Do you run training courses and wonder why the attendees only learn 10% of the material. All of us are teachers whether as informal mentors, coaches, trainers or parents. Yet only professional educators receive training in this area.

Only Twenty years ago most people in the world of neuroscience believed that the connections between the neurons in your brain were fixed by the time you were a teenager (or even younger)[1]. Now we understand that our wiring continues to change (even new neurons can grow) as we grow older. It’s just the rate of change that slows down. This is called Neuroplasticity, the discoveries around it are what make this presentation possible.

To find out more come attend the sessions. Can’t make it? Join me at Agile2010.

I started this week’s Quick Links last week at home in Canada. This week I’m at a client in the States and seem to have even less time in the evenings to write. How does that happen?

In People, Processes then (Maybe) Technology, Elliot Ross finds another angle one of my favorite thoughts. Tools are just enablers of process. When someone says which Agile tool (i.e. Rally, VersionOne, Danube/CollabNet, ………………) should I use, I reply “wait until you understand how you do agile, then you can decide which if any tool you need”.

Nigel Shaw writes: No Wonder Agile Guys Shun Tools in it he lists some of the many ways that agile tools fail in their attempt to mimic whiteboards. I add to his list: “As good as you make a tool displayed on a screen, it will still suffer from the problem that no one looks at the webpage very often. People walk past a physical story board many times a day, during standup they can touch the stories they worked on. Finally when someone comes up with a bright new idea for the board you implement it minutes with tape, PostIt Notes and white board marker.”

Steven “Doc” List talks about “A Culture of Heroism” and its ill effects on a team.

How I Learned to Let My Workers Lead – the story of Ralph Stayer the CEO of Johnsonville Foods. A great story of he completely changed the way his family Sausage company worked.

Michael Spayd has written a brilliant distillation of Scrum, as The Tao of Scrum. It boils Scrum down to its soul and essence. (Yes Sandy Scrum does have a soul).

George Dinwiddie reminds us that estimates really are just estimates: The Importance of Precise Estimates.

I love seeing the application of Agile outside of software, John Cass writes: Thinking Iteratively With Agile Marketing.

In Effective exercises for teaching TDD Gojko Adzic writes about a problem I’ve had a few times.

If your presenting at Agile2010, you owe to you audience to read: Three Steps to Make Your Next Speech Your Best by Nick Morgan.

Glenn Waters gave a great session at Agile Ottawa a few days ago, it was a combination of conversation, workshop and talk. As part of the session we identified many ways standups breakdown.

So what did we find going wrong:

• Not held daily
• Boring – no commitment or engagement
• No perceived value
• Too much talking and chit chat (socializing, wandering off topic)
• Not adhering to the 15 minute rule
• Being late and not showing up
• Directed, i.e. one person taking over and telling team members what to do.
• Reporting Directly to a manager vs. sharing with the team.
• Not reporting to the team
• Mumble, mumble disease, i.e. team member not saying anything that the rest of the team can understand.
• Trivia report – reporting in so much detail that no one understands or cares.
• Repetition – someone saying that they worked on one story several days running.
• Not raising impediments
• Not prepared
• Problem solving

So how do we make things better? Lets start by checking in with the Scrum Guide (by Ken Schwaber and Jeff Sutherland):

Each Team meets daily for a 15-minute inspect and adapt meeting called the Daily Scrum. The Daily Scrum is at the same time and same place throughout the Sprints. During the meeting, each Team member explains:
1. What he or she has accomplished since the last meeting;
2. What he or she is going to do before the next meeting; and
3. What obstacles are in his or her way.

There are a lot of problems here and they have many different root causes. In one blog post I can’t possibly make suggestions on how to solve them all, instead here are just a few examples:

• When sharing I ask team members to walk up to the story board and touch the story they worked on to help make it clear what they’re talking about.
• If see repeated problems like chit-chat, mumble mumble, ill preparedness, etc. I work with the team member offline to be better prepared for the meeting.
• When someone is repeatedly late for the meeting, I ask them offline if there is a problem with the time etc, only if other attempts to solve the problem fail to I resort to a penalty (i.e. financial: a looney in the team beer fund; social: becoming the keeper of the late badge).
• If team members start problem solving I remind them to take it offline and meet again after the scrum
• Reporting to Manager – if individual coaching fails I will ask the manager to turn their back on the team for a few days, until team members remember the meeting is for their benefit and not just the managers.

What pathologies do you find? How do you solve them?

Update I forgot to mention other resources: Daily Standup Tips – a Roundup my own on InfoQ and Jason Yip’s famous: It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings.

On May 11th Agile Ottawa is proud to announce a joint event with the Ottawa Scrum User’s Group. 

Craig Larman, author, speaker and trainer will be our guest speaker for the Agile Ottawa May 11th meet-up.

The topic is Scaling Lean & Agile Development for very large, multi-site, and/or offshore development.

Sign up via EventBrite requested so that we have an idea of the audience size.

Come out and help make this the best attended event in the Agile Ottawa’s history.

For all the reasons Ron, Cory and others have mentioned Certification is Evil:

• The certification(s) only prove that you attended a two day course and may have paid attention
• Certifications alienate other members of the Agile community
• The CSM doesn’t create people who understand Agile
• ….

N.B. In this context we’re all talking about the CSM and CSPO, which are just two-three day courses. The CSP (Scrum Professional) has some teeth and the CSC (Scrum Coach) is hard to get. Also I don’t know enough about the CSD to judge yet.

But there are some other issues that we can’t ignore:

• HR departments and some Managers continue to demand certifications
• The pull of the certification has drawn many people to Agile in the first place. The result many people know about Agile who never would have before.
• Without the CSM the Agile Community would be much smaller and not on the edge of mainstream adoption
• In a vacuum other certifications will appear (google the WAQB) and gain credence instead. At least we know that the CST’s are knowledgeable about Agile and have met a minimum standard (the bar has just been raised considerably).

In fact I would venture that most of the people complaining about the certifications would not be employed today as Agile Coaches, Trainers and Consultants if weren’t for certification having helped to grow the market.

Instead of fighting over certifications lets work to make them better – where we can. Lets also rate the certifications on several axis using the outputs of the Agile Skills Project. Finally you could pitch in with Cory Foy, Uncle Bob et al: Create and Promote their Agile Skills Videos.

But whatever we do lets stop fighting and create some value.

Caveat Emptor I will be applying to become a CST – i.e. one of the evil people who hands teach certification courses. You might be concerned that this has coloured my thinking. That these were my views before I considered joining the dark side.