Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 553 posts at DZone. You can read more from them at their website. View Full User Profile

Listening to feedback mechanisms

01.21.2011
| 3322 views |
  • submit to reddit

In Growing Object Oriented Software the authors talk about the value of listening to our tests to understand potential problems with our code and I’ve started to notice recently that there are implicit feedback mechanisms dotted around at a higher level which we can also listen to.

A couple of examples come to mind:

Nothing to show in the showcase

I’ve worked on a couple of projects where we’ve got to the end of the iteration and realised that we don’t actually have anything tangible to show the product owner.

This tends to be because we’ve spent the majority of our time working on ‘technical stories’ which typically have no visible output.

This may be as a result of horizontal slicing of work rather than vertical slicing but what it essentially means is that the work you’ve done has no immediate value to anyone.

Sometimes there are technical aspects to a solution which have a lot of unknowns and combining those with a vertically sliced story would mean that the story becomes too big to fit in an iteration.

From my experience a way around this which has worked well before is to run a spike/experiment card where we work out all the technical details/gotchas and setup any necessary ‘framework’ and then have the other vertically sliced chunks of work plug into this.

Having said that I’m no expert in breaking down work into manageable chunks so if anyone has any other ideas I’d be interested in hearing about those.

Boring meetings

The typical response if someone complains of being bored in a meeting or walks out of a meeting is that they should deal with it but that response doesn’t help us that much.

I think if people are bored then it’s an indication that the meeting isn’t particularly interactive/inclusive or that the person shouldn’t be in the meeting.

We can try to resolve that first point by having meetings which are designed more as a discussion/learning forum rather than a brain dump session by one person to the group.

This encourages more of a pull approach over a push one and seems to be more effective at keeping people’s attention as long as the topic of the discussion is actually relevant to them.

Frequently it seems that a more effective approach would be to have fewer people involved in a meeting and have one of the participants quickly summarise what happened for the rest of the team.

 

From http://www.markhneedham.com/blog/2011/01/21/listening-to-feedback-mechanisms/

Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: