Exercise: a 30 second video

"I like (something) because..."

Goal
To get 'hands-on' experience creating a video presentation.

Instructions
You have 30 minutes to produce a 30 second video.

1. Form groups, at least one member of each group to have a laptop computer on the wireless network.
2. Each use your own smartphone with video function
3. Announce the objective
• To create a video addressing a defined theme "I like the (something) because..."
• Completed video to be 30 seconds duration or less.

Tips First try producing the video in a single take (to avoid merging different shots or doing complicated edits). Planning a video... Start by brainstorming different ideas in the group. When brainstorming:

1. Let each member provide 2 or 3 ideas, capture each ideas with a post-it notes.
2. Suspend your judgment until everyone has stated their idea.
3. Next build on ideas, some ideas will be put aside at this stage.
4. At all times be aware of your own and other's personal safety.
5. Criticise the idea not the person.
6. Use serial discussion, everyone has a turn, no one person dominates.
7. Consider taking on roles but keep it democratic.

Producing a video Videos have a beginning, middle and end so consider writing a brief script. Assign roles...

1. to write the script.
2. to plan the shots.
3. to film.
4. to act.
5. find/create props.
6. to edit.

Do dry runs!

Perhaps you might

• Upload your video to Vimeo or YouTube?

---

Further reading

• My piece on storyboarding ideas (managingsystemsdevelopment.blogspot.com).
• Storyboarding is also used as a user-design technique for systems development. For examples see The Importance of Storyboarding Your iPhone App by Josh Clark and Storyboard technique for software projects by Adam Musial-Bright.
• Reynolds, G. (2008) Presentation Zen: Simple Ideas on Presentation Design and Delivery, Berkeley, CA, New Riders.
• Sawyer, B. (2009) The Learner's Journey in Practice. (blogs.oreilly.com)
• BBC video editor (link)
• Camista screen recorder (link)
• Quick and Easy Video with a Flip Cam (dspace.ndlr.ie)
• A Guide to Student-Generated Videos(www.studentgenerated.com)
• MINO HD FLIP CAMERA USER GUIDE (dspace.ndlr.ie)

Here's my pitch for you to 'storyboard' and some tips on how to do it.  Storyboarding from Allen Higgins on Vimeo.

My pinterest collection of video exercises and related presentations

How can I motivate people to play with programming tech?

Give them a goal they can achieve using programming tech!
Using (for example)...
Jampot's TheAppBuilder (link)
The MIT App Inventor (link)
HTML5 (many courses available e.g. Udacity's game course (link)

Must project managers be technically savvy?

On the question 'must project managers be technically savvy' posed by Luc Richard (link), my answer is a fairly obvious 'yes', however I will qualify it by saying that the project manager does not need to be the technical architect, indeed I judge that the two roles should be completely separate in teams of greater than 3 people. Richard makes some strong claims:

On estimating

"In order to create a project plan, you must be able to estimate how much effort is required to complete all of the required tasks. Needless to say, you can't estimate effort unless you truly understand what's involved in designing and implementing those features."

On scheduling:

"A project manager must be able to schedule activities in a logical sequence."

Assuming you are starting from the conventional project management perspective you will find that the questions raised by Richard are, as it happens (coincidence?), the defining areas of the PMBOK. But a careful reading of Richard's responses reveals something else, an underlying assumption that the project manager does everything.

In response to Richard's assertion that "To be an effective project manager, you must be capable of designing and developing the solution yourself." I claim to be an effective project manager you must instead develop skills and sensitivities for getting the best out of heterogeneous, multitalented, multidisciplinary, mixed gender, culture, age, experience teams!

Unless of course you're working on a team of 1! (or 2, or 3)

As an antidote to too much PMBOK and too much Technology I strongly recommend having the following on your bookshelf:

Beck, K. (2000) Extreme Programming Explained : embrace change, Reading, MA, Addison-Wesley.

Brooks Jr., F. P. (1995 (1987)) The Mythical Man-Month : Essays on Software Engineering, Reading, Mass., Addison-Wesley Pub. Co.

Cockburn, A. (2002) Agile Software Development, Indianapolis, IN, USA, Pearson.

Cohn, M. (2006) Agile Estimating and Planning, Upper Saddle River, NJ, Pearson Education.

Demarco, T. & Lister, T. (1999) Peopleware: productive projects and teams, New York, NY, Dorset House Publishing.

Kidder, T. (1981) The Soul of a New Machine, New York, NY., Little, Brown and Company. Hachette Book Group.

Mcconnell, S. (1996) Rapid development: taming wild software schedules, Microsoft Press.

Poppendieck, M. & Poppendieck, T. (2003) Lean Software Development: An Agile Toolkit Upper Saddle River, NJ, USA, Addison Wesley.

User experience or engagement?

There is a rather subtle aspect of technology design that is often neglected, that is 'how design works within a whole context'. This idea is rather like thinking in terms of a design ecology rather than a design 'thing'. The truly difficult issue to address is 'the audience' or users, actual people.

Engagement is a long term value. A good user experience doesn't necessarily equate with engagement with a technology system. The basic unit of analysis for user experience is probably a strand of end-to-end goal driven interaction, whereas engagement looks at involvement with the technology system over days and weeks, ideally years. Engagement also considers performance within the technology ecosystem. While engagement isn't the same as 'product as a service', many successful technology engagement experiences are with long duration technology systems that operate as services.

I was thinking about examples of good and not so good engagement experiences. A good user experience may well be successfully paying my bin collection fee online or reviewing my phone bill online. I complete the tasks in less than 10 minutes, I feel confident the process is safe, I get feedback on progress and successful completion. But I'm not engaged with either of those experiences, I don't return out of curiosity or to tweak my preferences or add things. A good engagement experience might be my preferred use os Chrome for logging into 10+ different webmail accounts, my tweaking of the Chrome bookmarks or launch page. Engagement is evident in the whole experience of using my iPod, taking photos, curating some of my photos on Instagram, linking some of them to my Facebook, and the quick seamless experience of my Apps, particularly the email client on that device.

Jim Kalbach expands on his version of this discussion on his Wordpress blog (link).

Bringing it all together: Agile Product Management

Henrik Kniberg's Agile product ownership in a nutshell video: brings it all together nicely. It provides a great overview of how agile systems development actually works from the product management perspective.



Should we build the right thing? Build the thing right? Build the thing quickly?

Python programming for novices

Is Python a good language to learn programming?

A question regularly posed to Slashdot followers is "how to become a programmer?" or "what programming language is the best to learn?" There are no easy answers because it is not easy to learn to program nor is there one best language for learning to program or to program 'professionally'. However a broad consensus exists that Python is useful both as language for learning how to program and as a programming language in its own right suitable for developing serious software applications.

A terminal session driving my python program.

Learn Python The Hard Way (2nd Ed) by Zed A. Shaw is a sufficiently challenging yet productive step-wise set of exercises that you can use to gradually learn both how to wrangle your computer and how to program. You will learn that the answer is both out there (thanks search engines and people who post to blogs or groups) so long as you ask the question, and within you if you work hard enough to discover and understand why something doesn't work the way you expect it to work. You will find that docs.python.org is an essential resource for understanding the whats and whys of Python, and Wikipedia an aid for learning fundamental concepts.

What python course does google use? Google's own python class offers a well paced introduction to the language https://developers.google.com/edu/python/ (link)

Thoughtful reflection on software roots

We should pay attention to our roots. If we don't know where we came from we'll never really know where we're going. After all, how can you go anywhere without leaving somewhere?

Here the idea was why technology courses at college neglect its history. Not some potted Babbage begat Eniac begat Apple begat Internet. Something substantial that actually studies software, why it worked well, what succeeded, what didn't, what was before its time, of its time, or timeless about the actual software we used.

The post that started this on Threads (link) and also flick through the posts on Slashdot to expand the range of possibles (link).

Another take on Creativity...

A nice video on the topic of ideas & brainstorming. Note the shift to an essentialist vision of the superiority of ideas; ideas as entities that function, that can be generated, contrasted and combined. 

http://www.youtube.com/watch?v=NugRZGDbPFU

Critique: While not explicitly stated in the video the stance conveyed is the commonly held view that ideas are contained in individuals, the inventors that conceived them.

I would however like to caution against appealing to explanations that resort to the notion of a singular inventive genius at the centre of an innovation. I would try to avoid or at leaset be conscious of the 'essentialist turn of phrase'; that creative ideas are out there jostling for attention, that half an idea can become a full idea in combination with another half etc. Appealing to this kind of 'obvious' way of dealing with ideas is an easy naturalistic way of thinking about the creative process however it mingles the 'idea' with a kind of technical agency, that is it attributes essential qualities to the conceptual object of an idea. This then leads to a kind of teleological explanans for why the final condition of a successful innovation is achieved. Fitness, technical superiority, and a kind of Darwinian competition between ideas in networks that produces a new innovation. This way of describing ideation, while easy to understand, is not founded empirically; ideas and innovations do not have their own lives therefore employing this mode of understanding innovation  seems to me to make for bad policy and management. Why? Because it does not explain the underlying phenomena. What I observe, in the field, is a much messier, involved, uncertain, porous, negotiated and tenuous process that unfolds progressively in an un-plan-able manner. The creative process is more an artistic process than a decision making process of playful discovery, aesthetics and judgement mixed in with inspiration, serendipity and sweat. Ideas aren't atoms of meaning that can be combined into new elements or molecules. Rather, they emerge in contexts, from experience, and through interaction with others.

The five minute CIO: David Miller

Terminalfour's COO offers a view on how to bridge within the high-tech business, between a production and a business focus...

It all comes back to people [from a technical discipline] recognising that there’s a different world to the world they’re in. The best people are the ones who combine the two [business and IT]. 

http://www.siliconrepublic.com/strategy/item/29933-the-five-minute-cio-david/

Use a process that produces data

These three columns or position pieces by 'Uncle Bob' Robert C. Martin of ObjectMentor, setup the classical problem of systems development and offer a well-thought-through response. Consider that Bob wrote these in the days prior to our wider awareness of practice-oriented approaches that were just then gaining ground such as XP, SCRUM and the Agile Manifesto. However, to paraphrase from Martin's Engineering Notebook on IID (Martin, 1999)

"Don’t let these articles mislead you.  If you follow the advice above and begin developing projects in an iterative and incremental way, bluebirds will not fill your sky.  Schedules will still be missed, there will still be bugs, problems, and mis-aligned expectations.  Software is, after all, software; and software is hard. However, what you will be doing is using a process that produces data; whereas waterfall produces none. With that data, managers can try to manage the project."

The articles:

http://www.objectmentor.com/resources/articles/IIDI.pdf
http://www.objectmentor.com/resources/articles/IIDII.pdf
http://www.objectmentor.com/resources/articles/IIDIII.pdf

Ship Wars@ Google Waterloo

Ship Wars is a competition in which participants code their own intergalactic crafts in the programming language of their choice, and then battle against each other in a virtual environment.

Take a look at these development environments...

http://goo.gl/JaQyd and http://goo.gl/RJjOK

Simplified Grade Descriptor

Simplified grade descriptor for grading standard.

A
The report is complete and covers all important topics.
Appropriate significance is attached to the information presented.
There is a compelling logic to the report that reveals clear insight and understanding of the issues.
Analytical techniques used are appropriate and correctly deployed.
The analysis is convincing, complete and enables creative insight.
The report is written in a clear, lucid, thoughtful and integrated manner-with complete grammatical accuracy and appropriate transitions.

B
The report is complete and covers all important topics.
Appropriate significance is attached to the information presented.
There is a clear logic to the report that reveals insight.
Analytical techniques used are appropriate and correctly deployed.
The analysis is convincing, complete and enables clear insight.
The report is written in a clear, lucid, and thoughtful manner-with a high degree of grammatical.

C
The report is substantially complete, but an important aspect of the topic is not addressed.
The report used information in a way that was inappropriate. There is a clear logic to the report.
Analytical techniques are deployed appropriately.
The analysis is clear and the authors draw clear, but not comprehensive conclusions for their analyses.
The report is written in a clear, lucid and thoughtful manner, with a good degree of grammatical accuracy.

D
The report is incomplete, with important aspects not addressed.
The report frequently used information that was substantially inappropriate or inappropriately deployed.
The report’s analysis is incomplete and authors fail to draw relevant conclusions.
The report is poorly written.

E/F
The report is substantially incomplete.
Whatever information provided is used inappropriately.
There is little analysis and the report is inconclusive.
The report is poorly written and presented.

Further reading
See the UCD registry for a more complete outline grade descriptor (pdf file link).
See grading in the module curriculum for conversions between grade points (gp), gp values, and marks (pdf file link)

Kanban objects and interaction

看板

In Japanese; Kanban: Literally, a ‘watch over – board’: a billboard, poster or sign. The first character (reading "kan") combines the primitive elements of heavenly/above and eyes/see to convey watch over or oversee. The second character (reading "ban") combines the elements of wood with bending/resistance meaning which together are taken to be 'board'.

A time-lapse video of a physical kanban/scrum board being used by the Vodafone Web Team in Copenhagen, Denmark.

The underlying mechanism for Scrum is based on kanban which originated in the Toyota Product System. We see these Kanban boards in many workplaces. Kanban is just a board but it becomes a focal point, a social/organisational device. The operation of a Kanban is based on two principles: Pull system, and Visibility.

The other essential aspect of a Kanban in software development is design collaboration; collective involvement in design decisions. Kanban and collaborative design are complementary practices. They act to flatten hierarchy, and enable communication. But 'flat' and democratic, while reducing propensity for individuals to ‘dominate’ also reduces the opportunity to for them to ‘hide’. Agile teams can be very tricky to run as they bring issues of power, control, reputation, face, failing and succeeding into the public sphere of work.

Are there organisational archetypes for high-tech firms?

Alex reminded me of this funny take on organisational charts emphasising the influence of the Owner/Founder/CEO in IT companies. Amazon appears as a classical top down hierarchy with no inter-communication among peers. In Google's case its two founders: Larry Page, Sergey Brin,  plus one (Eric Schmidt I presume) appear to be cloned throughout a tiered organisational with multiple lines of communication among all levels. Facebook is presented as a mesh with no layering and isolated local pockets of communication. Microsoft as a network of hierarchies with each subdivision at odds with all of the others. Oracle as a legal firm with a small engineering division attached to it and both divisions reporting directly to Larry Ellison the CEO. And Apple as a blob of individuals, each one under the direct supervision of the then CEO Steve Jobs, suggesting a minimum of delegation.

http://usingapple.com/2011/06/funny-organizational-chart-for-apple-facebook-google-amazon-microsoft-oracle/

Consider relating the ideas behind these depictions to Steve Sawyer's social archetypes of software development teams... The sequential model of task/role separation seeks to address the challenge of control, the group model fulfils the desire for intercommunication where task/role separation is infeasible, and the network model resolves task/role specialisation by establishing responsibilities specific to the production being performed. We might consider the possibility too perhaps that each archetype is a remedy for the problems arising from over dependence on one of the others.

Exercise: Table Label, aka Marshmallow Tower Challenge

Allocate at approximately 1 hour to run the exercise. 10" setup and briefing. 30" experiment. 5" extra time. 15" debriefing. You will need a large space with scattered desks to accommodate the exercise.

Overview

• A design/build challenge is set.
• Each group will employ a ‘thinking aloud’ protocol as they run the experiment. The builder/designers comment aloud to highlight ideas, key transitions or changes in their thinking about the problem.
• One person will act as the researcher, capturing a time-record of the designers’ comments or activity at any moment. The researcher role is not allowed to take part in the design and construction.
• Change the person in the researcher role every 5 minutes to give all team members an opportunity to contribute to the design and construction.
• Output: A ‘Design Activity Graph’ recording design/build activity over time, for example:
  
  • Scenario thinking
  • Requirement thinking
  • High level solution thinking/building
  • Medium level solution thinking/building
  • Low level solution thinking/building
  • Key ideas.
  • Testing or Review.

For an alternate take on this activity see Peter Skillman's 'Marshmallow Challenge.'

Practical Aim: "As a teach I want to see ‘group labels’ for each table ‘over the sea of heads’ in a classroom so that I can call on groups to respond and encourage for class participation."

Knowledge Aim: To assess the different activities people engage in in open-ended problem solving design/build work.

Materials
A pack of sticks, some plasticine, some rubber bands, and an index card. A tape measure.
A sheet of graph paper to capture the team's graph.

Competitive dimension/evaluation: 
Which group can construct the most useable table label!
The tutor will need a ruler to measure and compare the height of the table labels.

Reflection
Ask each group to classify the activities they underwent (perhaps over 4 or 6 distinct kinds of activity)
Ask each group to estimate how much time they spent on each activity.
Ask the groups to reflect on how they won (or lost!) and to reflect on the contributions their different experience, backgrounds, disciplines made to the solution.
Were there collaboration problems?
Were transitory objects used?
Were conflicts resolved?
What roles were evident?
What is the impact of time pressure?
Can you identify who is responsible for the design?
What evidence of design work is available (diagrams, prototypes, experimental trials)?
What would you expect to happen if the exercise was performed again and again?
Where/when does the design occur?
Was the creative aspect to this exercise essential?
Was your design planned or accidental?
...

Design Demand: Understanding 'need' through the design process

Seminar Invitation:

When? Oct 23, 2012 from 06:30 PM to 07:30 PM

Where? Room Q107, The Collaborative Space, 1st floor, the Quinn Building, UCD Belfield. 
Google Map reference for directions: http://goo.gl/maps/iyhoh.

Contact Name: Allen Higgins

Henry Poskitt from frontend.com poses the question "what is design?"

There are two contrasting views on the design of objects for use; one that a successful design disappears from view; the other, that design is evident in its outward character be it aesthetic, arresting, bold, pleasing etc. Although the aspiration to produce good design is pretty well embedded in the language of digital development what does it mean, really? And how do users really fare? Particularly users outside of the one-standard-deviation-from-the-bell-curve of the normal distribution?

Siobhán Long and Karl O'Keeffe from Enable Ireland Disability Services will also be on hand to field questions dealing with how users with different needs and abilities evaluate the systems that designers produce.