OOP 2007 Conference Feedback

March 6th, 2007

OOP 2007 Conference Feedback - I gave a tutorial and a keynote at the SIGS-DATACOMM OOP Conference in January. I was really honored to be asked to speak at this conference, as it was my first ever invitation to speak in Europe. The trip was a bit challenging because of the terrible weather, but the German people were so warm and inviting that I felt right at home. Perhaps my favorite story was that on Wed Jan 24th I needed to take the train from Munich to Heidelberg so that I could teach some Innovation Games(R) classes to staff members and friends of the SAP Design Services Team. Unfortunately, the original train was cancelled. I was lucky to find myself befriended by a German woman (from Brazil, no less!) who was also traveling to Heidelberg. Seven hours and three trains later — I was in Heidelberg.

Another great memory of the OOP conference was that I was invited by the conference organizers to attend a special reception dinner on Monday evening Jan 22nd. At the dinner we had a lively discussion about the pros/cons of changing the name of the conference. Like so many other conferences, the OOP conference has evolved substantially over the years. Yes, objects are still important, but so are many other facets of software development, all of which are covered at the OOP conference.

Should the OOP conference change its name? This is a tough branding question. Delegates from prior years know that the conference covers many topics. The concern, though, centers around new delegates: Will they be put off by a conference with “OOP” in the title if they’re looking for something about agile or product management? In the end, I told the conference organizers that I think they had already made up their mind to change the name of the conference and that we were really discussing “when” they should change the name and not “if” they should change the name. They smiled when I said this. I then told them that I agreed with their decision, and that in this case changing the name seemed like a sensible thing to do.

Here is my conference feedback, received today from Wolfgang Reuter, the very helpful and thoroughly organized Conference Organizer. Click here for the Excel feedback form.

——————————–

Luke,we would like to thank you on behalf of SIGS-DATACOM for your participation at OOP 2007 in Munich.

The initial feedback we received from our delegates was very positive.

Enclosed you will find the evaluated feedback forms of your session.

Many thanks again from the whole SIGS-DATACOM team

Wolfgang

——————————————————

Wolfgang Reuter

Konferenzmanager

Conference Manager

Tel. +49 (0)2241/2341-211

Fax: +49 (0)2241/2341-199

wolfgang.reuter@sigs-datacom.de

www.sigs-datacom.de

Aktuelle Veranstaltungen / Upcoming EventsSIGS-DATACOM GmbH - Geschäftsführer: Günter Fuhrmeister Sitz des Unternehmens: Lindlaustr. 2c, 53842 Troisdorf

Registergericht: Amtsgericht Siegburg, HRB 6552

ONE MORE TIME: You’ve Got To Talk With Customers

February 26th, 2007

I was visiting a client of Enthiosys to discuss Agile Software Development practices and during the meeting my client mentioned that her company had recently created a New Product Development / Ideation group.  I looked at the wall and noticed an ideation process map and asked if that map was how this group intended to work. She replied yes, that that process map was the current thinking from this group. She detailed the process, which showed several sources of input into the New Product Development group. Among the sources listed included:

  • Corporate strategy
  • Corporate capabilities
  • Competitive assessment
  • Analyst research
  • New technology
  • Core competencies

There were a few more, but I honestly can’t remember what they were because what was missing just hit me like a 2×4 in the chest. Customer. The actual customers of this client were never listed on this chart. Not once. Not in qualitative research. Not in quantitative research. Simply not listed.

When I asked my client about this, she replied something like “Well, this may not be the final version of their process. I think they are planning on talking to customers, but I’m not sure. Customer support is listed as an input into the diagram — that should help, right?”

I told her that yes, soliciting input for New Product Concepts from internal groups such as sales, professional services, and customer support was helpful, but I also told her that I thought it was an egregious mistake to create a New Product Development / Ideation group that doesn’t talk directly with customers.

In the hopes of stating what should be blatlantly obvious, the foundation of innovation is understanding your customers. This includes talking with them.

Weekly Project Tracking in Agile Projects

February 6th, 2007

One of the great virtues of agile methods is that they provide near real-time feedback into the status of the project. At the end of the iteration (or sprint) you know exactly where you stand, and you know which items from your iteration / release backlog have reached the “Done, Done” status of potentially releaseable software. When coupled with velocity and burn-up / burn-down charts, many agile teams think that they everything they need to properly communicate their status to the rest of the organization.Unfortunately, they’re wrong.  While it is certainly important to communicate velocity metrics, burn-up/burn-down charts, and the status of individual backlog items, a well-designed agile status reporting infrastructure communicates several additional and critical pieces of information.

I believe that a status report should serve the following goals.

  1. Publicly and openly communicate the status of the development to the organization in a way that is consistent with Agile practices and helps other groups within the company accomplish their job(s), most notably preparing for the release.
  2. Identify and track dependencies so that the organization manage the overall portfolio of projects.
  3. Identify and track project risks and associated risk mitigation strategies.
  4. Formally track agreements that affect the release.
  5. As needed, track and communicate resource used by the project.     

As you consider these goals, you might reflect that most of them have nothing to do with “agility” and instead have everything to do with sound principles of project management. 

These goals, however useful, mean nothing if the team is unwilling to regularly create and communicate status information. This can be a legitimate point of concern — if you’re spending more than 15 - 30 min a week generating status reports, something is wrong. I’ve long felt that status reports are generated most enthusiastically when:

  • They provide value to the person and/or team creating the report.
  • They are generated relatively easily using the tools that the team is already using to monitor progress.
  • Taken together over the life of the project / history of the release the status reports tell the abbreviated story of the project.  

This means that whatever tool that you’re using to manage and track your project should provide a means to output status information in a simple and straightforward manner. Ideally, this tool is the sole repository of information, so that merely accessing the tool is all that you need to communicate the status of the project.  

Agile 2006 Conference Feedback

January 15th, 2007

Here is the feedback I received from the Agile 2006 Conference. This is the entire email I received.

—————————————————————

Dear Luke,

Please find below the feedback on your tutorial at Agile2006. We hope you consider proposing a session for Agile2007 in Washington DC.

Our call for participation can be found here:
http://www.agile2007.org/index.php?page=submissions/tutorial/tutorial
and the deadline for submissions is January 26th.

Best regards,
Rachel Davies

Agile2006 Session Feedback

Title: Innovation Games Session id: TU8 Leader: Luke Hohmann
Strongly Agree Agree Neutral Disagree Strongly Disagree
1. The presenter/leader was well prepared 26 3      
2. The presenter/leader was knowledgeable on the subject 28 1      
3. The session held your interest 21 5      
4. The session abstract was accurate 18 9      
5. The A/V materials were appropriate and legible 21 8      
6. Overall this session was well worthwhile 22 7      
Comments:
Outstanding – best session so far, no doubt.
Great contribution of an often glossed-over part of agile in a whole new way.
I was surprised by the granularity and the pragmatism of the preparation steps. Most process descriptions leave out the “obvious stuff”, but of course obvious is subjective.
I felt rushed and wanted to play more games.
Would have liked to explore/play more games first hand.
Thanks for sharing your great ideas Luke, really appreciate it.
Good ideas
Very good session
Great content, technique, presentation and audience involvement
Luke has great energy!
Can’t wit to try to do some of these
Awesome!
Excellent ideas and presentation
Best presentation so far!
You’ve written a book?!!
Very helpful session
Thanks
Very fun!
Presenter didn’t know the session was as long as it was and so he filled in with more presenting and less interactive.
Let’s try more games!

QRCA 2006 Conference Feedback

January 15th, 2007

A few posts ago I advocated open evaluation of conference speakers. Since then, I’ve received more evaluation forms from conferences where I’ve been a speaker. Here is the first, from the QRCA Conference. I had a great time at this conference, and really do hope that I can attend and speak again in 2007.

I received the evaluation in the mail and scanned the entire document here.