It's not a secret anymore!*
The moose likes Agile and Other Processes and the fly likes Innovation Games: Does a customer even know? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Innovation Games: Does a customer even know?" Watch "Innovation Games: Does a customer even know?" New topic
Author

Innovation Games: Does a customer even know?

Branko Santo
Ranch Hand

Joined: Oct 15, 2005
Posts: 72
Hello,

a very interesting aproach, and right where it is needed. Programmers and especialy software engineers have a lot of problem with customers who themselves do not know what they want.

Engineer: What would you like your program to do?
Customer: I would like....{1, 2, 3, 4, 5, ...}
Engineer: Perhaps also...{a, b, c...}
Customer: Oh yeah that would be nice!

Two weeks pass, all the diagrams, preparations are set and coding is already underway.

Customer: Could I also get ... {55, 56, 57, 58..}...

This is so often the case with programming. I am looking foreward to aquiring your games and trying them out (offcourse first with friends).
Luke Hohmann
author
Greenhorn

Joined: Oct 05, 2006
Posts: 27
... and I am looking forward to hearing about your experiences with the games!


Regards,<br /> <br />Luke Hohmann | CEO | Enthiosys, Inc. | <a href="http://www.enthiosys.com" target="_blank" rel="nofollow">www.enthiosys.com</a> <br />Innovation Through Understanding<br />cell: (408) 529-0319 | lhohmann@enthiosys.com<br />| Join the Innovation Games Forum: [URL=http://www.enthiosys.com/forumAuthor of "Beyond Software Architecture: Creating and Sustaining Winning Solutions" and<br />"Innovation Games: Creating Breakthrough Products Through Collaborative Play"
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791

Two weeks pass, all the diagrams, preparations are set and coding is already underway.

Customer: Could I also get ... {55, 56, 57, 58..}...

Off the innovation topic ... If this is really your life, and you haven't already done it, read up on the way Agile methods describe iterative development with a "planning game" session for each iteration. HERE is one good resource.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

The "Could I also get" that comes two weeks later is often the result of that single person finally having conversations with other users/customers/stakeholders. This symptom reveals that more communication needs to happen across users before the developers receive laundry lists.

The innovation games should involve a selection of multiple users/customers/stakeholders. That way you can get those conversations to happen earlier in the project.

It's very likely that if you are getting frequent "Could I also get" comebacks, there are also multiple "That original thing I needed really isn't all that important" that you never hear about. That can waste a lot of developer time and unnecessarily bloat the software. Innovation games would also help to weed out these features that one person thought would be useful that later turned out not to be.

Innovation games cause more conversations. Conversations cause the users to better understand their needs and how to prioritize them.
[ November 01, 2006: Message edited by: Marc Peabody ]

A good workman is known by his tools.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Marc Peabody:
The "Could I also get" that comes two weeks later is often the result of that single person finally having conversations with other users/customers/stakeholders.


Or there was some other way to generate an insight tht lead to the new idea for a requirement.

Although games certainly can help to generate a huge amount of those insights earlier, I still think that some insights really only can be expected when the users start to actually use the real system. A technique that can probably help with this is the usage of prototypes (even paper prototypes - perhaps there are games that go in that direction?).

Still, I think it remains important to release a real running system to the customer as early as possible. The feedback from *that* experience cannot possibly be beat, in my experience.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Branko Santo
Ranch Hand

Joined: Oct 15, 2005
Posts: 72
Actually me being a single developer currently can not do too much about it.

But there always is a solution and the one I like is.

Customer: I need "function 1"
Product manager: Function 1 will take x time and cost y money. If you cancel within 1/2x than it will cost 60% of y,otherwise it will cost 100% of y.
Customer possibility 1: OK I really need it!
Customer possibility 2: Oh perhaps it is not as needed.


Bottom line is that developer time costs $$ and engineers time costs $$$$ so if they want to pay we can change the specs all day long for as long as they want.

Yeah not very agile but is a way out of situations like this.
Luke Hohmann
author
Greenhorn

Joined: Oct 05, 2006
Posts: 27
Branko, the situation you describe is referred to as "Non Recurring Engineering" and is a common practice that enables customer to increase the prioritization of highly valued items in the product backlog.

See, for example: http://www.pragmaticmarketing.com/productmarketing/topics/05/0503ds.asp
Branko Santo
Ranch Hand

Joined: Oct 15, 2005
Posts: 72
Luke thanks for the link

It was a nice read!
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Branko Santo:

Bottom line is that developer time costs $$ and engineers time costs $$$$ so if they want to pay we can change the specs all day long for as long as they want.

Yeah not very agile but is a way out of situations like this.


If you ask me, that's actually quite Agile.

Well, even more Agile would it be if you were able to reduce the costs to change the spec. In fact with a "fully Agile" approach, the costs of changing the *spec* become near zero - only when you change something that is already implemented, costs inevitably rise.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Innovation Games: Does a customer even know?
 
Similar Threads
Interactive Games?
Better Career path?
Innovation Games: Does the customer realy want to play games?
what would be your profession if there were no computers at all?
Difference between Programmer, S/W Developer and S/W Engineer