I presented three 90-minute sessions at Agile 2009 with varying degrees of success. Most notably, in two of my sessions, where I expected to use a flipchart and draw diagrams as I spoke, I found myself in long, narrow rooms with in excess of 100 people. That meant that few people could see the flipchart, which proved a sizable disadvantage for them. To you who attended my sessions, but couldn’t see what I wrote on the flipchart, I apologize and have corrected the problem. Frankly, I feel good about having audiences large enough to have this problem!

While I felt quite good about the majority of attendee feedback, I did receive some feedback that puzzled me. I wanted to post that material here in hopes that if you gave me some of this feedback that you’d email me and help me understand either what you meant to say or how you intended me to use the information you gave me. I really do not want to lay your feedback to waste, but if I don’t understand it and can’t use it, then I simply won’t change anything related to it.

So if you gave any of this feedback, then please answer my questions by sending me email at the address you can see on every page.

Introduction to Agile with the Theory of Constraints

It’s boring to listen for 90 minutes; get the audience involved too.

I think this could work well, but I don’t know how to do that with this session in particular. Can you suggest one or two ways I could have got you involved in the session that you would have liked?

Room too big for just flipchart.

I gave this talk at AgileEE with a tablet PC as an e-flipchart and that appeared to work much better. I think I’ve solved this problem.

It may have been a little bit more organized and focused.

I appreciate this perspective. I have changed the session to include a 20-minute introduction of all the key Theory of Constraints topics: throughput accounting, bottlenecks, and even production/production capacity. I think this helps give the session a more focused feel. I like to keep the talk quite fluid, because I don’t know how to cover everything important in only 90 minutes. To talk about all the common agile practices, I think, would require a half day. I also don’t want to give exactly the same talk every time.

References to studies, concepts could use prepared diagrams, references so the flow isn’t interrupted.

I like this idea. As I give this talk more frequently, I will start identifying common bits that I use in every talk, and can start preparing some material like that. I recently gave this talk privately to a client and included some prepared, but handwritten, slides. I think it worked well, so I rather appreciate the suggestion.

Make sure to emphasize importance of bottleneck, provide facts and background [instead of ‘some study I read’], inventory == all work in progress

I appreciate these suggestions. I know I forgot bottlenecks, and have introduced a first-pass to the talk that ensures I talk about the key Theory of Constraints concepts, including throughput accountings, bottlenecks, and production/production capacity. When I gave the talk at AgileEE and again privately to a client, I made sure to highlight all these areas in the first 15 minutes.

I understand the desire to make the references more meaningful by using less handwaving. I admit that I simply don’t care that much about these references for such a session, and recognize that others care more about that. I suppose I have the attitude that I don’t intend my talk to fit into the academic style, even though I see how one could consider that a cop-out.

Puzzle: you present solutions, can you also include the problem-solving part?

I don’t quite understand this request. Can you tell me more about what you mean? Can you give me an example of what you’d expect?

It would have been nice to hear some positive arguments about the ‘softer side’ (team work, etc.)…

I can’t interpret this comment meaningfully, because I don’t know at all how it relates to this talk. Can you give me an example of a positive argument about teamwork that you think I could have included?

…and tips for selling agile to customers (the point of view was a bit business-restricted).

I simply don’t understand this comment. What do you mean by “business-restricted”?

Regarding selling agile to customers, I discuss this issue in detail in a different talk entitled “Strategic Selling and Agile”, which I perform with Niraj Khanna.

I would have liked a hand-out to help me know the outline/main points of the talk….

I agree that that would help, and as I give any talk more frequently, an outline emerges. In the most recent version of this talk, I gave an outline that I believe helped the audience better anticipate the content of the talk.

Also, references to books mentioned would be helpful on hand-out.

I will include a reference to a librarything.com list in future versions of the talk.

I found it difficult to take notes on everything because he talked quickly.

I appreciate the difficulty in taking notes when someone speaks quickly. I do try to speak at a more reasonable pace, but frankly I don’t know how easily nor how quickly I’ll manage to make a lasting change there. I will try.

Created slides would have been easier to follow, but you’d still want flip charts.

Thank you for acknowledging the value of both prepared material and spontaneous material. I will include some prepared material in future versions of this talk.

Have more expertise in ToC.

I suppose you mean that I should learn more about ToC. I agree that that could help, but I don’t yet see how more expertise in ToC would improve this talk in particular. Can you give me an example of how that would have helped?

In more recent versions of this talk I make a point of asking the audience whether anyone considers themselves an expert in Theory of Constraints. I then acknowledge my relatively broad and shallow knowledge of the topic and ask them to forgive any mistakes I make or correct me gently.

Show some real examples of actual changes and how they helped change those critical parameters [meaning, I think, throughput, inventory, and operating expenses.

I really like this idea and have begun to think about how to include this in the 90-minute version of this talk, even though I find the short version already overflowing with material that I don’t usually get to talk about. In a longer version of the talk I’d find it easier to include such information.

Good, informative but heavy of XP practices, so less interesting to me.

I started learning about agile with XP, so I find it natural to use mostly XP examples. Which non-XP practices would you like me to have addressed? Perhaps I can do that some other way for you.

Slides would be helpful.

I had two talks with the same issue. I didn’t expect an audience of over 100 people in each one. Would you have preferred slides because you prefer them as reading material, or because you couldn’t see the flipchart, or for some other specific reason? I prefer not to assume to know the significance of your interest in slides. -

Shorter.

Understood. What would you suggest I cut?

Some facts wrong. Some sources quoted wrong.

Please believe me when I say that I made any such mistake unintentionally. Can you remember any facts or sources that I got wrong? I’d like to correct myself in future versions of the talk.

Wanted a bit more rigor around ToC, based on [the] title.

Can you give me an example of how I could have increased rigor around ToC for future versions of this talk?

Integration Tests Are A Scam

Not testable prior to presentation to customer

What do you mean by “testable prior to presentation by customer”?

Didn’t address some of the bigger problems we have like how to test integration + DB (unintelligible) quickly

I couldn’t read one key word in this comment. I would appreciate the commenter clarifying what he or she wrote.

Made a meal of explaining something quite simple

I think ideas derive power from simplicity, so I don’t necessarily view this as a negative. Moreover, if these concepts are so simple, then why isn’t everyone doing it?

Should have prepared charts

I don’t quite agree with the “should” party, but I do plan to use e-flipcharts for future presentations. I did this at AgileEE 2009 and it looks like it will work well and can leave attendees with something to which they can later refer.

Good presentation, more for developers only, which I was unaware by the description

I re-read the description and I can’t decide how to interpret it other than for programmers. Please tell me how you interpreted the description that didn’t strongly suggest the audience would consist of programmers.

Would be nice to have some tips of how to keep the tests in agreement. It’s not automatable, so humans need to keep track.

I thought I did this, but in case I didn’t, please read this example where, near the end, I describe the algorithm I use to match up collaboration tests and contracts tests. I believe one could automate some of this, either in the style of lint or in the style of Cucumber and its “here’s what you need to write to implement that step” feature.

Talk was on unit tests rather than ‘integration’ tests; felt session was mislabeled.

I understand this a little, but I don’t understand how the talk was not on integration tests. I talked about them all the way through. Moreover, since I titled it “integration tests are a scam”, I assume that would suggest that I wasn’t going to praise or recommend using integration tests.

You make the case integration tests are a waste of time and effort in almost all cases. You should outline where they do add value.

I really like this comment, and I will do that in this space sometime soon. Briefly, they add value when they check for system-level problems and unintended emergent behaviors that focused tests can’t find.

Too fast; too auditory – hard to integrate this way

I apologize for this. I do sometimes talk too quickly because the topic excites me. As I perform this presentation more, I can more easily create long-lasting artifacts that will help people remember what I described.

Took too long to get to interesting ‘contract tests’. Seemed somewhat disorganized.

I can appreciate this sentiment. I suppose that in every audience at least one person will feel this way. I think that for most people, most of the time, I need the introductory material before I describe contract tests.

As for feeling disorganized, what could I have done to make it feel more organized for you? An outline? Something you could see to keep track of my position in the talk?

I’m not sure half the room could read the easel.

Agreed. I didn’t expect so many people, and it makes me happy to know that my audience has started growing. I have started using a tablet as an e-flipchart. I hope that helps.

If the speaker’s argument that we need more unit and story-level tests on component modules, I buy that and he could have said so. If he said that integration tests are not a complete test regime for development, I agree. But integration tests are a scam → get real HIS TITLE is a scam.

I think I did say that we need more unit and story-level tests on component modules. I think I did say that integration tests are not a complete test regime for development. I still stand by the title: I believe there is more to the problem than that: integration tests sucker programmers into writing more integration tests, and that’s the scam.

35 minutes to get to mock objects and strategies for using mocks… yuck.

I can appreciate that perspective. What did you expect? I can try to give more of that next time.

I’d like to see some code, especially to see how this technique provides confidence through multiple levels of collaboration.

I agree that that would help. I don’t know how to do that well in a 90-minute session.

Would have loved to see some real example contract tests on a large system.

I appreciate this comment, and would love to have included some, but my clients don’t let me show their code. Also, I find it hard to include examples like that in a 90-minute session. In a half-day session I’d find it easy to do, if any of my clients would let me show their code.

I was looking for how to fix integration/BDD tests… Description of session should have made it clearer that it was programmer tests not standard integration/BDD tests.

I will look at how to improve the description to make that clearer.

Turned out to be a lot more basic than I thought — seemed to be ‘why use mock objects’ but handwaved over the difficulty of using them.

I wish you had got more of what you wanted from the session. I think this session includes more than just ‘why use mock objects’, but I can see why you might have that impression. As for ‘handwaving over the difficulty of using mock objects’, can you share some of the difficulties you would have liked me to discuss?

Handwriting so poor—can’t read the flip chart—use PPT. I found his swearing offensive.

I apologize for the quality of my handwriting. I know I need to raise my awareness of this issue, and I think I have started to do that. I prefer not to use PowerPoint in general, so I have started using a tablet PC as an electronic flipchart so that more people can easily read what I’ve written.

Regarding the swearing, I apologize for having offended you. I know that I take that risk and I understand that swearing represents lazy speaking.

Straightforward but a bit boring.

I wish you had been able to get more out of the session that you did. I find it surprising that you’d stay the entire time in a session that you found boring, but I appreciate your determination. What would you like me to do with this information? What might I have done to excite you more?

XP: My Greatest Misses 2000-2009

I wasn’t sure where we were in the list of misses. What I needed was a list, maybe on the flipchart.

I take full responsibility for this. I have written the misses as an article, which you can easily find online with google. I didn’t ask Agile 2009 to print this list as a handout because I wanted to save paper.

Also, as the talk evolves, my perspective about my misses evolves, and I don’t give this talk the same way I did in 2007 when I did it for the first time, so I worry that any list would become out of date and useless. Perhaps I underestimate the value of that list.

Over-labored one problem of mis-interpretations of one’s communications.

I suppose I find this problem so important that it merits emphasis. Also, thinking back to the talk, I saw links from other mistakes to miscommunication that I hadn’t seen before, and I wanted to share those new connections with you as they happened. I see how that would appear as over-laboring the point.

I expected more examples of things you can do wrong with XP rather than a discourse of (J. B.’s) personal mistakes.

I don’t quite know how to react to this comment. I think that both the title and the description make it clear that I will talk about my mistakes, and not about mistakes one might make. I even put “My” in the title to suggest that point. I don’t know how to make that clearer in the future, but if you can suggest something, then I’d like to know about it.

Good storyteller, but would have preferred a bit more focus.

I understand and agree. I like my talks to proceed somewhat in a stream-of-consciousness style, and I understand the risk I assume by doing this. When I give talks with a narrower technical focus, I tend to do a better job of following a clearer structure. I suppose I don’t see this talk as fitting into that category.

I find it surprising though, that you’d rate my presentation skills with the worst possible rating, but you only offer the comment “would have preferred more focus”. Your innocuous comment doesn’t appear to match your extremely low rating. Can you tell me more about what you feel I did wrong?

Too much talkative, too sleepy.

I don’t know what to do with this comment. It’s a talk. There will be talking. It’s a talk about my mistakes, and you can’t tell the audience my mistakes—only I can. What do you suggest that I could have done differently?

Personal info is good, helpful and helps develop rapport, but a few examples went a little too far (example: your wife crying).

I appreciate this sentiment, and I apologize for making you feel uncomfortable. I have a trusting nature, so I find myself more comfortable making myself more vulnerable than others do. I wanted to emphasize the significance of what I’d learned, showing that it goes far beyond my work as a consultant.

Don’t know that we actually got through 10 misses.

I understand. I don’t remember promising to get through 10 misses. :) To read all 10, please google “rainsberger greatest misses” and you’ll find the article with a similar title that provides a summary of 10 specific misses. I apologize if you didn’t get as much variety in the talk as you’d have liked. As I was talking, I felt things becoming a bit monotonous, but I didn’t know what to do about it at the moment. I suppose I could have just paused, admitted that I needed to move on to another idea, then done so. I can remember that for future versions of this talk.

Maybe I did not understand the topic description. I thought it would be examples from the industry.

I think I included plenty of examples of my work in the industry, although I did also include more personal examples that occurred outside my work as a consultant. As for misunderstanding the topic description, what did you expect from the session given the way you interpreted the description?

This talk is valuable to experienced coaches, but not too much would be evident to a novice coach. It might be hard for them to identify a big idea or theme. [Best idea was saved for last.]

I had hoped that novice coaches would find my mistakes useful in that they could watch out for making those same mistakes themselves. Some other coaches and practitioners have told me directly that they notice themselves making similar mistakes and now have some ideas how to stop themselves before they do too much damage. So it seems at least some novice coaches managed to get from the talk what I intended to convey. Of course, I have no way to know how many other novice coaches left the room reeling and confused, because none of them have told me as much.

As for saving the best idea for last, I assure you that I didn’t do that intentionally. Sometimes it takes that long for the best idea to come out.

Go Leafs

You are bastard.

Editor’s note: I know who left the “Go Leafs” comment. We are friends and I am joking with him. Please hold your cards and letters.

Joe, I hope you feel better! You’re smart enough, you’re good enough, and by golly, I like you!

I appreciate the sentiment, and I further appreciate you letting me know who you are in your comments, but then I don’t understand why you rated the session so poorly. That doesn’t match your comment, which appeared humorously supportive in nature. I don’t want to interpret your comment as sarcasm and condescension, but given your ratings, I find it hard to interpret it otherwise.

I wish there was more time for Q&A.

I apologize. I wish there were clocks in the room so that I could have managed my time better. I think I simply need to stop after 2/3 of the time available, even mid-sentence, just to ensure we have enough time for Q&A.

I thought Joe’s insights and ideas were great, really valuable. It just didn’t match description. Should de-couple the XP in the title.

I don’t understand why the content didn’t match the description. I would like to know more about the mismatch you perceived. I use XP as my primary toolset when I consult, so most of, if not all, my misses come from XP or XP-leaning projects. What could I have said or done that would have made that connection clearer for you?