Tuesday, July 24, 2012

presentations: creating and presenting

had to give a presentation and listen to a number of other peoples' presentations recently, and it got me thinking about how to do it better -- more effectively and more efficiently. here are my notes.

getting motivated to document/present/publish: consider the knowledge transfer as a part of the software/system deployment. the job is not finished until the product is in the customers' hands and they're using it.

i have finally decided that draft presentations in front of other people is not optional for me. i am just not capable of doing a good job without feedback from an external perspective. i'm not good at anticipating what others will be thinking, what they already know, what will be misleading, or what info is required for them to reach the right conclusion. i need to plan for this, and schedule the time and line up the people to listen as part of my preparation. it took me about a week to prepare for a 15 min presentation. i want to shrink that down, but i've realized that i need to allow some time to pass, doing other things, between iterations to get a fresh look at it.

early iterations should produce some factor (2x?) beyond the length of what will end up in the final. it's much easier to pick out things to trim from a complete narrative than to figure out what's missing. it also allows me to try different ways to explain the same thing. for getting feedback, it's easier for the audience to sat "i didn't understand this part" or "that part was repetitive/redundant/boring" vs. "here's what you should have added to make me understand this thing i don't understand". and i can't really crystalize the single main point and the few underlying points without seeing some content first.

i also realized that it is faster for me to write out a script of exactly what i will say, rather than just trying to wing it. by the time i have practised enough to be able to wing it, i will have come up with and memorized an unwritten script anyway, and it will have taken longer. i do still need to practice saying it, though, because the flow doesn't work the same when it's spoken vs. read. once i have written the script and practised it a few times, i won't need to actually look at it when i'm presenting. and i need to be able to deliver the spoken words and gestures/pointing without thinking about it too much, so that i will be free to observe the audience reaction and respond to it. also helps with getting the timing right.

characteristics of a good presentation and questions
-what do they want to know? what do they want to know?
-they will feel good about what they have learned if they have learned something they wanted to know.
-they have to be convinced that they want to know it, or else they won't even pay enough attention to learn it.
-would someone who didn't _need_ to know this material still be interested in its presentation?

try writing conclusions first, then content, then intro and outline last.

plan prep time based on scope of the concepts presented, not on the speaking time allotted.
-related, but not exactly linear relationship because of need to close off a complete idea
-complex ideas will take more prep time because there will be more potential pitfalls on places to get lost, so will take more time to craft carefully and more iterations with feedback from other people. this prep time increase holds true even when the time to present it is held constant at a short duration.
-i think part of the difficulty is that concepts and ideas are connected in complex, nonlinear, and possibly tree-like or digraph patterns, but a coherent presentation of an idea must be a linear narrative (in fact, i want desperately to keep their thoughts from wondering off the linear path.

review presentation slides from the perspective of someone with different types of gaps: caps in background knowledge, gaps in attention (someone missing the beginning or (more likely) not paying attention for 1 or more slides in the middle).

put in a "credibility" slide every once in a while to show that there is real, complex, impressive work behind the talk. Make all the other slides as simple as possible, to focus attention and ensure basic ideas are communicated.
-one mistake i see people making is to make jumbled slides with way too much to absorb in short time they flash it up there. (maybe it comes from trying to condense a longer talk or throw together slides from everyone who works for them.) it makes me think they're trying too hard to impress me, but i'm not impressed when nothing sinks in.
-otoh, i don't want to make it all so simple that someone will miss the relevance or genius of the simplicity. i don't want to leave the impression that i haven't done anything difficult or important.
-maybe make one complex slide at the beginning to establish credibility and gain interest. then immediately drop the complexity very low for pedagogical purposes. then increase complexity gradually as you explain the concepts. then jump complexity up again at the end when you show the application to demonstrate the relevance to and usefulness of the application.

if you have to use a big slide full of text, don't expect people to read it linearly. highlight words and phrases with color cues to guide their eyes to the important parts and things they need to remember.
-i just did a presentation with a number of moving parts that people needed to remember and keep distinct and organized throughout the talk. i tried using a color-coding system where i put every reference to a particular type of variable in a consistent color. i think that helped people follow the references, and it helped me organize things, too.

visuals should support what you want to say, not impede or force you to interrupt yourself to explain it. this is also a good reason to practice saying it aloud, because the speaking pace should determine placement of the visual information.

no eyecharts, and don't put something on there that you then tell me to ignore! it makes me wonder what else i should be ignoring.

sometimes the truth is misleading. leave it out. i won't go so far as to be dishonest, but you need to reduce detail until the main point is learnable within the time you have. the exigencies of communication mean that no one will care about the assumptions and simplifications you need to make in order to clarify the immediate point. they should be detailed only when they are necessary for the communication and relevant to the context.

Thursday, July 5, 2012

agile planning links

http://neilperkin.typepad.com/only_dead_fish/agile-planning.html
http://www.ambysoft.com/essays/agileProjectPlanning.html
http://www.ibm.com/developerworks/linux/library/l-agile-plan/
http://www.agilehelpline.com/2011/04/6-levels-of-agile-planning.html
http://www.projectconnections.com/articles/120506-mcdonald.html

standalone python executables

some good links i've dug up for making standalone programs from python

http://docs.cython.org/src/userguide/extension_types.html
http://hg.cython.org/cython/file/8bff3332e34f/bin/cython_freeze
http://wiki.python.org/moin/Freeze
http://stackoverflow.com/questions/1681021/detailed-explanation-about-pythons-freeze
http://cx_freeze.readthedocs.org/en/latest/index.html
http://www.py2exe.org/index.cgi/Tutorial
http://hg.cython.org/cython-devel/file/tip/Demos/freeze/README.txt#l1
http://wiki.wxpython.org/CreatingStandaloneExecutables
http://stackoverflow.com/tags/cx-freeze/hot

book: agile estimating and planning

by mike cohn, 2006 (11th printing 2011) 005.1 COH

p xxii. can't plan away uncertainty. we reduce uncertainty by gaining knowledge, and we gain knowledge by executing the plan. plan, plan, plan-do vs. plan-do-adapt, plan-do-adapt
anticipation vs. adaptation
estimate size, derive duration

ch. 1
p 3. "planning is everything. plans are nothing." -- field marshal helmuth graf von moltke (i always thought eisenhower said something like this. maybe he ripped it off.) also, "no plan survives contact with the enemy."
p ?. planning helps us see risk (uncertainty) and make decisions about it. eg, we can try the riskiest part first to see if it will work.
p 6. the most critical risk facing most projects is the risk of developing the wrong product
p 6. failed project: no one came up with any better ideas than what was on the initial list of requirements
p 9. an agile plan is one that we are not only willing, but also eager to change. we don't want to change the plan just for the sake of changing, but we want to change because change means we've learned something or that we've avoided a mistake.
p 10. spread planning evenly over the duration of the project

two week timebox, with half day each fortnight for planning. don't let external pressures change requirements during the timebox; they have to wait until the next one.

the knowledge and insight we gain from planning persists long after one plan is torn up and a revised one put in its place. agile planning is focused more on the activity of planning than on the plan, and an agile plan is one that is easy to change.

ch. 2
2/3 of projects have significant cost overruns
64% features rarely or never used
100% average schedule estimate overrun

traditional planning concerns activities performed rather than features delivered.
this leads to schedule overruns:
-activities don't finish early
-lateness is passed down
-activities are not independent

p. 12 ...