Tuesday, October 23, 2012

Working with Gremlin

If you want to learn more about graphs or graph databases you might want to check out Gremlin.

Gremlin is a graph traversal language that can be used for graph query, analysis, and manipulation. 

As a simple example, if we have this simple graph:























And we want to answer the question "Who are marko's codevelopers?" then we could write the following query in Gremlin:


That would give us "peter and josh"

With Gremlin it's possible to work with any graph (database) that implements the blueprints property graph data model., i.e Neo4J which is probably the most popular graph database right now.

The easiest way to start working with Neo4J is to start it in embedded more but a more production-like scenario would be to send Gremlin queries to a Neo4J server using the REST API and Spring's Neo4J template.

Check out Gremlin's Web Console if you want to try out Gremlin without installing anything.

Tuesday, October 9, 2012

Empty rituals


Most so-called "agile" teams follow the following routine every morning: they gather round and, one by one, answer the following questions:

* What did you do yesterday?
* What are you going to do today?
* Is there anything hindering you?

Actually most teams that I've encountered just ignore that third question completely.

In the worst case (people sitting during the meeting), what you see is that this meeting becomes almost absurd, people just answer the questions and go back to their smart phones when their turn has passed. In the meantime, the scrum master, team lead, etc writes/types ferociously trying to capture what people are saying. These notes will kept/posted somewhere where no one (other than the scrum master) will ever look.

If asked why they do it I guess the answer would be the same as when you ask people why they chose a relational database.

Anyway, here's a way to make this hopefully less meaningless by Jeff Sutherland.

Starting with the highest priority Sprint Backlog Item (SBI) that is not yet completed in each Daily Stand-Up, the entire Team discusses their collective contribution toward completing that SBI. They then estimate their collective contribution’s complexity in Story Points as if the previous day’s contribution had been presented during the Sprint Planning meeting as the entire goal of the body of work. The Team then collectively plans the fastest and most effective way to share the work in order to move that SBI into the Done column as quickly as possible. Finally, we discuss anything that blocks the work or has the potential to slow it down for any reason.  
So the restructured Daily Stand-Up questions become:  
1. What did WE achieve yesterday on Priority 1?
2. What was OUR contribution on Priority 1 worth in Story Points?
3. What is OUR plan for completing Priority 1 today?
4. What, if anything, is blocking US or has the potential to slow US down today?  
These questions are then repeated for each lower Priority remaining in the Sprint Backlog until either all SBIs have been discussed or the 15 minute allotted time has elapsed, whichever comes first. 
These modifications serve several purposes. Shifting the focus from the individual to backlog priorities helps people to function more as a Team. It encourages consideration of how to effectively subdivide the work for quicker completion, overcoming the technical silos that specialists tend to prefer. We also find better quality updates and more attentive participation from all Team Members as a result of question 2. 
Because each Team Member now has a need to understand the complexity that has been resolved in order to vote on it, updates on the order of “Yesterday, I worked on SBI 1. Today, I will keep working on SBI 1. No impediments.” are no longer tolerated by the Team. 
They become a self-policing group, both demanding quality updates and full attention from all Team Members to keep the meeting efficient.