Skip to content

Feed aggregator

The 3 Questions vs. Tools

Applied Frameworks - Tue, 07/22/2014 - 02:04
Why Tools Drive Daily Scrums into the Mud

I have observed a disturbing pattern in many Daily Scrums driven by an intense focus away from the three questions and to various Agile tools. I see people checking out of the interaction, I don't hear all voices, I don't feel any energy and I don't sense any collaboration or collective ownership of the work.

What I See...

Screen sharing like Live Meeting…whether 7 people in the room and 1 person remote or 2 people in the room and 6 people remove…almost always hosted by the ScrumMaster. A tool's task board displayed. The meeting flows from the top of the task board to the bottom with conversations like,

ScrumMaster: "OK, story B-01243…Sam - What's the status?"

Sam: "Oh, ummm, I finished the 1st task [but Sam hasn't moved it to 'Done'] yesterday. I started the other task but got blocked [also not yet moved by Sam]. Then I worked on the task for story B-01250 [at the bottom of the board]."

Everyone else during this conversation - Silence…Looking at who knows what on their screens.

ScrumMaster: "Sam, do you want me to move those tasks?" OR "Sam, please update your tasks." AND/OR "Any impediments?"

Note: If the ScrumMaster moves tasks, then we're in for a treat as he/she navigates down to find B-01250 wherever it is on the board to move tasks around.

Repeat for every BACKLOG ITEM on the board…Every day.

Why this Pattern Fails
  1. Violates the pattern of the 3 questions…No coherent, fast realization of progress toward the Sprint Goal.
  2. Focuses attention on the screen/task board, not people.
  3. Focuses on a top/down flow, which almost always does not reflect the actual nor optimal flow of the work in progress.
  4. Drives the WRONG behavior of stimulating excessive WIP - work in progress.
  5. The team is not self-organizing the meeting…Intentionally or not, the ScrumMaster is organizing the meeting to flow through the tool.
  6. Invariably the meeting runs longer than 15 minutes because this pattern drives so much wasteful conversation.
  7. No/Little synchronization of work because, in general, things on the board only have 1 person talking about them at a time.
Why Do We Do a Daily Scrum? Daily Scrum at Klean Denmark CC BY-SA 2.0 (photo cropped)

Daily Scrum at Klean Denmark CC BY-SA 2.0 (photo cropped)

From The Scrum Guide…my emphasis added.

"The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, the Development Team members explain:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

"The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal.

Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.

The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replay, the rest of the Sprint's work.

"The ScrumMaster ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The ScrumMaster teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.

"The ScrumMaster enforces the rule that only Development Team members participate in the Daily Scrum.

"Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team's level of knowledge. This is a key inspect and adapt meeting."

The Agile Atlas overview of Core Scrum provides a similar description of the Daily Scrum.

Disclaimer

Don't get me wrong, I have nothing against Agile tools for Application Lifecycle Management. These tools greatly support teams. They save a whole bunch of time generating useful information for Development Teams, Product Owners, Product Managers and organizations. They provide organizational 'memory' and collaboration as the single source of backlog information. They just stink as tools for Daily Scrums…and other Scrum activities.

What did we do before the tools?

We met in the team room and stood near the task board. Sometimes people referred to the board to jog their memory. Most just spoke off the top of their head, because that's what mattered - "Yesterday, I finished X. today, I'm going to do Y. I don't have any impediments. John, I would like to chat with you for 5 minutes when we're done about the whoozijiggy design."

(My friend Carlton Nettleton and my colleague Gil Broza have shared their unique and complementary ideas on this subject.)

What to Do as a Coach or ScrumMaster if You Observe or Facilitate this "Tool-Driven" Pattern?
  1. Ask the team if you can have a short conversation with them about the Daily Scrum. You're seeking permission.
  2. Have a mini-retrospective.
    • How valuable is the Daily Scrum?
    • How good are their daily plans to work together for the day once the Daily Scrum ends?
    • What would they like to change?
    • What might happen if they stopped using the tool and returned to the 3 questions with nothing in front of them except other people (if in person or notes or whatever if remote)?
    • How does everyone, including the ScrumMaster, feel about this?
  3. Ask them what they want to do.
  4. Let go and let the team move on.
  5. Check in with them a few days or a week later (if you have the invitation for an ongoing coaching relationship).

Your feedback is always welcome…What are YOU seeing at Daily Scrums?

Categories: Companies

Does Agile Empower the Knowledge Worker?

TV Agile - Mon, 07/21/2014 - 23:31
In the information technology industry, decisions impacting the design, construction and implementation of projects were solely the realm of architects and project managers. These decisions would be made and locked down at the outset of the project and tasked to subsequent business analysts, developers and quality assurance personnel to define, construct and test, respectively. In […]
Categories: Blogs

The Value of the KCP Masterclass

I've listed a whole series of Kanban Coaching Professional (KCP) Masterclasses for the 2nd half of 2012. These classes are typically residential and can be consumed as 2 x 3-days or in a single 5-day week long intensive class. Typically 4 out of 5 people are choosing the 5-day version of the class since we introduced it at the beginning of 2014. These classes are a big commitment in time and money and we often get asked where the value is? I'd like  to explain.

read more

Categories: Companies

A Brief History of Kanban for Knowledge Work

Success has many fathers! Recently, there has been some content published elsewhere on the web that seeks to re-write the history of the adaptation of kanban systems into the field of creative knowledge work. The individuals publishing these alternative versions of history are generally doing it for self-serving reasons or in some cases as deliberate misinformation to try and undermine my business. To put the record straight, I've compiled this definitive history...

A History of Kanban for Creative Knowledge Work October 2004

Dragos Dumitriu, manager XIT Sustaining Engineering at Microsoft, asks me to help him. I design a pull system for Dragos' group and coach him on how to introduce it. He "sells' the idea to his bosses and his 4 product managers who act as his customers. The pull system was implemented on Microsoft Product Studio (a forerunner of Team Foundation Server). There was no physical board. The engineering team was offshore in Hyderabad, India. The system implemented was inspired by Theory of Constraints Drum-Buffer-Rope and worked on the assumption that Test was the bottleneck.

read more

Categories: Companies

First Keynote Announced for Agile Business Conference

Scrum Expert - Mon, 07/21/2014 - 19:02
The Agile Business Conference has announced that David J Anderson will deliver a keynote at the conference. David is the pioneer of the Kanban Method, an Agile and evolutionary approach to change, and his keynote ‘Fit for Purpose’ – resilience and agility in modern businesses – promises to be both refreshing and eye-opening.  In it David will look at how the Kanban Method enables evolutionary adaptability and how to define fitness criteria metrics to drive effective business performance. Complementing David’s keynote in the ‘How To…’ Track, Lazaro Wolf and Jose Casal ...
Categories: Communities

ALE UnConference, August 20-22 2014, Krakow Poland

Scrum Expert - Mon, 07/21/2014 - 18:23
ALE is a community of like-minded people who want to work, talk and have fun together to create a better Agile and Lean community in Europe. The ALE conference is a three-day conference that discusses the Agile, Lean and Scrum topics in software development. In the agenda of the 2014  ALE Unconference you can find topics like “Agile Leadership and emotional intelligence”, “David and Goliath – Rediscovered at Scaling of Agility in Really Huge Organizations”, “Storytelling – from Better Code to Awesome Organizations”, “Lean-Aware Self-Adaptive Systems”, “#NoEstimates Project Planning Using Monte ...
Categories: Communities

What's holding down your team's Velocity?

Agile Complexification Inverter - Mon, 07/21/2014 - 18:21
Is your "Agile Project Manager" driving the team to increase their velocity?  Has the Agile Death March begun?

Fred Brooks warned us of these dangers nearly 25 years ago in The Mythical Man-Month.

One antidote to the PM schedule crunching technique of throwing warm bodies at the problem is to remove the impediments that are known (or just under the surface) within the structure and environment that holds the team back from performing at more efficient delivery rates.  So many times the line workers (developers and testers) are well aware of these issues, and feel as if they have raised them many times and gotten little attention (mostly negative attention) from managers.  A classic game (Innovation Game) to expose these impediments is Speed Boat.

I just saw this image of the anvil holding the balloon down and thought it would make a great visual metaphor for the Speed Boat game.  See the article by Alan Dayley Velocity is Like a Helium Balloon to get a hi-res poster.

Categories: Blogs

Who's Managing Your Company?

J.D. Meier's Blog - Mon, 07/21/2014 - 18:13

One of the best books I’m reading lately is The Future of Management, by Gary Hamel.

It’s all about how management innovation is the best competitive advantage, whether you look through the history of great businesses or the history of great militaries.  Hamel makes a great case that strategic innovation, product or service innovation, and operational innovation are fleeting advantages, but management innovation leads to competitive advantage for the long haul.

In The Future of Management, Hamel poses a powerful question …

“Who is managing your company?”

Via The Future of Management:

“Who's managing your company?  You might be tempted to answer, 'the CEO,' or 'the executive team,' or 'all of us in middle management.'  And you'd be right, but that wouldn't be the whole truth.  To a large extent, your company is being managed right now by a small coterie of long-departed theorists and practitioners who invented the rules and conventions of 'modern' management back in the early years of the 20th century.  They are the poltergeists who inhabit the musty machinery of management.  It is their edicts, echoing across the decades, that invisibly shape the way your company allocates resources, sets budgets, distributes power, rewards people, and makes decisions.”

That’s why it’s easy for CEOs to hop around companies …

Via The Future of Management:

“So pervasive is the influence of these patriarchs that the technology of management varies only slightly from firm to firm.  Most companies have a roughly similar management hierarchy (a cascade of EVPs, SVPs, and VPs).  They have analogous control systems, HR practices, and planning rituals, and rely on comparable reporting structures and review systems.  That's why it's so easy for a CEO to jump from one company to another -- the levers and dials of management are more or less the same in every corporate cockpit.”

What really struck me here is how much management approach has been handed down through the ages, and accepted as status quo.

It’s some great good for thought, especially given that management innovation is THE most powerful form of competitive advantage from an innovation standpoint (which Hamel really builds a strong case here throughout the entirety of the book.)

You Might Also Like

The New Competitive Landscape

Principles and Values Define a Culture

The Enterprise of the Future

Cognizant on The Next Generation Enterprise

Satya Nadella on the Future is Software

Categories: Blogs

Problem Solved: Formula to figure out How Much Detail is Required with Agile Requirements

Agile Management Blog - VersionOne - Mon, 07/21/2014 - 16:29

WARNING: Shameless plug for my session at Agile2014 ahead.

I recently got the priviledge to listen to Alistair Cockburn talk to a small group at the VersionOne offices. He told the story about Kent Beck and how the idea of how the user story on notecards was born (I’ve read about this before, but it was great hearing it from Alistair). He talked about how the card was just that — a card with a title that reminded the developer and the target customer/user what they were building, maybe there were a few notes jotted down on the card. The narrative about the story wasn’t captured on the card — the details were verbally communicated because the developer and customer were all in close proximity of one another — they did this crazy thing, they simply walked down the hallway and talked.

In addition to this story, Alistair spoke about his experiences with a team that had development in Singapore and the business folks and architecture worked in the states. The company was having challenges with the team in Singapore at getting things done efficiently and, in some cases, getting things done right. It seemed like there was an inordinate amount of time that had to be spent on discussing requirements and getting questions worked out. The company decided to send some of the business and architect team members to Singapore to work out some improvements. When they did — the quality and productivity went up. When they returned, it took just a couple weeks before productivity slipped and all gains were lost. The reason for these results seems obvious — timezones, communication barriers, and not being able to have impromptu conversations can have a great impact on how well teams understand the requirements especially since a lot of conversations capture the specifics.

Hearing these two stories triggered some ideas in my head, and I thought — why can’t there be a simple formula we can use to gauge the amount of detail (words) we capture in a story to make it work. Through some hard work — I’ve now have that formula.

Here are some factors that I think go into figuring this out:

  • Complexity – just how well does the team understand the story and how hard the team thinks it will be, either from experience or flat out guessing. Usually captured as story points.
  • Difference in Timezones – the number of hours that separate us greatly impacts how fast communications can happen, especially if the communications occur near the bookend points of the day.
  • Auditing Requirements – audits are generally costly and require an additional amount of documentation overhead.
  • Multiple Offices – when people are in different buildings, it raises the amount of details that have to be captured.
  • Offices on Different Continents – although this somewhat relates to timezones, there is also the fact that people speak different languages. Even if they all agree to use english as the primary business language, there’s still slang, accents, and even cultural differences that impact communications.

How Long the Team has Worked Together – knowing each other is key, we figure out accents, we are able to exchange less verbal words, and we learn how to work with one another — what level of information is required to work effectively as a team.

So I reached out to some friends and the folks at Tagri Tech, and with their help — here’s the formula we came up with:

Amount of Words in Story = (Complexity * (1+ max absolute difference between timezones) * (1 + # of annual audits) * (Total # of locations * # of continents)) / (# of quarters the team has worked together)

And here’s the formula in action:

DocFormula

Multiple simulations have been ran and I found that the formula works in less than 0.01% of the situations. The people I’ve been working with at Tagri Tech’s statistics analysis department have ascertained that every team is different, and every product is different — this means that no matter how much documentation you have — the people involved in creating the documentation or the target consumer of the documentation really are not going to read it. They found that while some documentation like compliance reporting and end user documentation are necessary, much of the collaboration level docs are only consumed by the person that created it.

Ultimately, Teams will generally work together to figure out how much details are truly required to facilitate working effectively. If your teams are having challenges with how much documentation is required within Agile Software Development projects, then please come to Agile 2014 and check out my session on Friday at 9AM in the Sanibel room, we’ll talk about some ways teams can workout their own formula.

Update: Hopefully you read all the way to the bottom of this post and realize, this is just a ruse, a joke, a farce, me not being serious. My point is, agile is hard and the concepts of documentation around building software makes it difficult as well. The right amount of details in our requirements is a trial-and-error thing, sometimes you’ll have too much details and at times too little.

Categories: Companies

100 Articles to Sharpen Your Mind

J.D. Meier's Blog - Mon, 07/21/2014 - 07:45

Actually, it's more than 100 articles for your mind.  I've tagged my articles with "mind" on Sources of Insight that focus on increasing your "intellectual horsepower":

Articles on Mind Power and the Power of Thoughts

Here are a few of the top mind articles that you can quickly get results with:

Note that if reading faster is important to you, then I recommend also reading How To Read 10,000 Words a Minute (it’s my ultimate edge) and The Truth About Speed Reading.

If there’s one little trick I use with reading (whether it’s a book, an email, or whatever), I ask myself “what’s the insight?” or “what’s the action?” or “how can I use this?"  You’d be surprised but just asking yourself those little focusing questions can help you parse down cluttered content fast and find the needles in the haystack.

Categories: Blogs

What is Your Minimum Agile Reading List?

Johanna Rothman - Sun, 07/20/2014 - 22:44

In preparation for my talk, Agile Projects, Programs, and Portfolio Management: No Air Quotes Required, I have created a Minimum Reading List for an Agile Transition. Note the emphasis on minimum.

I could have added many more books to this list. But the problem I see is that people don’t read anything. They think they do agile if they say they do agile.

But saying you do agile doesn’t mean anything if you don’t get to done on small stories and have the ability to change. I hope that if I suggest some small list of potential books, people will read the books, and realize, “I can do this!”

I am probably crazy-optimistic. But that hasn’t stopped me before.

I would like your help. Would you please review my list? Do you have better books? Do you have better suggestions? It’s my list. I might not change my mind. However, if you comment on that page, I would know what you think.

Thank you very much.

 

Categories: Blogs

R: ggplot – Plotting back to back bar charts

Mark Needham - Sun, 07/20/2014 - 18:50

I’ve been playing around with R’s ggplot library to explore the Neo4j London meetup and the next thing I wanted to do was plot back to back bar charts showing ‘yes’ and ‘no’ RSVPs.

I’d already done the ‘yes’ bar chart using the following code:

query = "MATCH (e:Event)<-[:TO]-(response {response: 'yes'})
         RETURN response.time AS time, e.time + e.utc_offset AS eventTime"
allYesRSVPs = cypher(graph, query)
allYesRSVPs$time = timestampToDate(allYesRSVPs$time)
allYesRSVPs$eventTime = timestampToDate(allYesRSVPs$eventTime)
allYesRSVPs$difference = as.numeric(allYesRSVPs$eventTime - allYesRSVPs$time, units="days")
 
ggplot(allYesRSVPs, aes(x=difference)) + geom_histogram(binwidth=1, fill="green")
2014 07 20 01 15 39

The next step was to create a similar thing for people who’d RSVP’d ‘no’ having originally RSVP’d ‘yes’ i.e. people who dropped out:

query = "MATCH (e:Event)<-[:TO]-(response {response: 'no'})<-[:NEXT]-()
         RETURN response.time AS time, e.time + e.utc_offset AS eventTime"
allNoRSVPs = cypher(graph, query)
allNoRSVPs$time = timestampToDate(allNoRSVPs$time)
allNoRSVPs$eventTime = timestampToDate(allNoRSVPs$eventTime)
allNoRSVPs$difference = as.numeric(allNoRSVPs$eventTime - allNoRSVPs$time, units="days")
 
ggplot(allNoRSVPs, aes(x=difference)) + geom_histogram(binwidth=1, fill="red")
2014 07 20 17 25 03

As expected if people are going to drop out they do so a day or two before the event happens. By including the need for a ‘NEXT’ relationship we only capture the people who replied ‘yes’ and changed it to ‘no’. We don’t capture the people who said ‘no’ straight away.

I thought it’d be cool to be able to have the two charts back to back using the same scale so I could compare them against each other which led to my first attempt:

yes = ggplot(allYesRSVPs, aes(x=difference)) + geom_histogram(binwidth=1, fill="green")
no = ggplot(allNoRSVPs, aes(x=difference)) + geom_histogram(binwidth=1, fill="red") + scale_y_reverse()
library(gridExtra)
grid.arrange(yes,no,ncol=1,widths=c(1,1))

scale_y_reverse() flips the y axis so we’d see the ‘no’ chart upside down. The last line plots the two charts in a grid containing 1 column which forces them to go next to each other vertically.

2014 07 20 17 29 27

When we compare them next to each other we can see that the ‘yes’ replies are much more spread out whereas if people are going to drop out it nearly always happens a week or so before the event happens. This is what we thought was happening but it’s cool to have it confirmed by the data.

One annoying thing about that visualisation is that the two charts aren’t on the same scale. The ‘no’ chart only goes up to 100 days whereas the ‘yes’ one goes up to 120 days. In addition, the top end of the ‘yes’ chart is around 200 whereas the ‘no’ is around 400.

Luckily we can solve that problem by fixing the axes for both plots:

yes = ggplot(allYesRSVPs, aes(x=difference)) + 
  geom_histogram(binwidth=1, fill="green") +
  xlim(0,120) + 
  ylim(0, 400)
 
no = ggplot(allNoRSVPs, aes(x=difference)) +
  geom_histogram(binwidth=1, fill="red") +
  xlim(0,120) + 
  ylim(0, 400) +
  scale_y_reverse()

Now if we re-render it looks much better:

2014 07 20 17 42 40

From having comparable axes we can see that a lot more people drop out of an event (500) as it approaches than new people sign up (300). This is quite helpful for working out how many people are likely to show up.

We’ve found that the number of people RSVP’d ‘yes’ to an event will drop by 15-20% overall from 2 days before an event up until the evening of the event and the data seems to confirm this.

The only annoying thing about this approach is that the axes are repeated due to them being completely separate charts.

I expect it would look better if I can work out how to combine the two data frames together and then pull out back to back charts based on a variable in the combined data frame.

I’m still working on that so suggestions are most welcome. The code is on github if you want to play with it.

Categories: Blogs

Neo4j 2.1.2: Finding where I am in a linked list

Mark Needham - Sun, 07/20/2014 - 17:13

I was recently asked how to calculate the position of a node in a linked list and realised that as the list increases in size this is one of the occasions when we should write an unmanaged extension rather than using cypher.

I wrote a quick bit of code to create a linked list with 10,000 elements in it:

public class Chains 
{
    public static void main(String[] args)
    {
        String simpleChains = "/tmp/longchains";
        populate( simpleChains, 10000 );
    }
 
    private static void populate( String path, int chainSize )
    {
        GraphDatabaseService db = new GraphDatabaseFactory().newEmbeddedDatabase( path );
        try(Transaction tx = db.beginTx()) {
            Node currentNode = null;
            for ( int i = 0; i < chainSize; i++ )
            {
                Node node = db.createNode();
 
                if(currentNode != null) {
                    currentNode.createRelationshipTo( node, NEXT );
                }
                currentNode = node;
            }
            tx.success();
        }
 
 
        db.shutdown();
    }
}

To find our distance from the end of the linked list we could write the following cypher query:

match n  where id(n) = {nodeId}  with n 
match path = (n)-[:NEXT*]->() 
RETURN id(n) AS nodeId, length(path) AS length 
ORDER BY length DESC 
LIMIT 1;

For simplicity we’re finding a node by it’s internal node id and then finding the ‘NEXT’ relationships going out from this node recursively. We then filter the results so that we only get the longest path back which will be our distance to the end of the list.

I noticed that this query would sometimes take 10s of seconds so I wrote a version using the Java Traversal API to see whether I could get it any quicker.

This is the Java version:

try(Transaction tx = db.beginTx()) {
    Node startNode = db.getNodeById( nodeId );
    TraversalDescription traversal = db.traversalDescription();
    Traverser traverse = traversal
            .depthFirst()
            .relationships( NEXT, Direction.OUTGOING )
            .sort( new Comparator<Path>()
            {
                @Override
                public int compare( Path o1, Path o2 )
                {
                    return Integer.valueOf( o2.length() ).compareTo( o1 .length() );
                }
            } )
            .traverse( startNode );
 
    Collection<Path> paths = IteratorUtil.asCollection( traverse );
 
    int maxLength = traverse.iterator().next().length();
    System.out.print( maxLength );
 
    tx.failure();
}

This is a bit more verbose than the cypher version but computes the same result. We’ve sorted the paths by length using a comparator to ensure we get the longest path back first.

I created a little program to warm up the caches and kick off a few iterations where I queried from different nodes and returned the length and time taken. These were the results:

--------
(Traversal API) Node:    1, Length: 9998, Time (ms):  15
       (Cypher) Node:    1, Length: 9998, Time (ms): 26225
(Traversal API) Node:  456, Length: 9543, Time (ms):  10
       (Cypher) Node:  456, Length: 9543, Time (ms): 24881
(Traversal API) Node:  761, Length: 9238, Time (ms):   9
       (Cypher) Node:  761, Length: 9238, Time (ms): 9941
--------
(Traversal API) Node:    1, Length: 9998, Time (ms):   9
       (Cypher) Node:    1, Length: 9998, Time (ms): 12537
(Traversal API) Node:  456, Length: 9543, Time (ms):   8
       (Cypher) Node:  456, Length: 9543, Time (ms): 15690
(Traversal API) Node:  761, Length: 9238, Time (ms):   7
       (Cypher) Node:  761, Length: 9238, Time (ms): 9202
--------
(Traversal API) Node:    1, Length: 9998, Time (ms):   8
       (Cypher) Node:    1, Length: 9998, Time (ms): 11905
(Traversal API) Node:  456, Length: 9543, Time (ms):   7
       (Cypher) Node:  456, Length: 9543, Time (ms): 22296
(Traversal API) Node:  761, Length: 9238, Time (ms):   8
       (Cypher) Node:  761, Length: 9238, Time (ms): 8739
--------

Interestingly when I reduced the size of the linked list to 1000 the difference wasn’t so pronounced:

--------
(Traversal API) Node:    1, Length: 998, Time (ms):   5
       (Cypher) Node:    1, Length: 998, Time (ms): 174
(Traversal API) Node:  456, Length: 543, Time (ms):   2
       (Cypher) Node:  456, Length: 543, Time (ms):  71
(Traversal API) Node:  761, Length: 238, Time (ms):   1
       (Cypher) Node:  761, Length: 238, Time (ms):  13
--------
(Traversal API) Node:    1, Length: 998, Time (ms):   2
       (Cypher) Node:    1, Length: 998, Time (ms): 111
(Traversal API) Node:  456, Length: 543, Time (ms):   1
       (Cypher) Node:  456, Length: 543, Time (ms):  40
(Traversal API) Node:  761, Length: 238, Time (ms):   1
       (Cypher) Node:  761, Length: 238, Time (ms):  12
--------
(Traversal API) Node:    1, Length: 998, Time (ms):   3
       (Cypher) Node:    1, Length: 998, Time (ms): 129
(Traversal API) Node:  456, Length: 543, Time (ms):   2
       (Cypher) Node:  456, Length: 543, Time (ms):  48
(Traversal API) Node:  761, Length: 238, Time (ms):   0
       (Cypher) Node:  761, Length: 238, Time (ms):  12
--------

which is good news as most linked lists that we’ll create will be in the 10s – 100s range rather than 10,000 which was what I was faced with.

I’m sure cypher will reach parity for this type of query in future which will be great as I like writing cypher much more than I do Java. For now though it’s good to know we have a backup option to call on when necessary.

The code is available as a gist if you want to play around with it further.

Categories: Blogs

R: ggplot – Don’t know how to automatically pick scale for object of type difftime – Discrete value supplied to continuous scale

Mark Needham - Sun, 07/20/2014 - 02:21

While reading ‘Why The R Programming Language Is Good For Business‘ I came across Udacity’s ‘Data Analysis with R‘ courses – part of which focuses exploring data sets using visualisations, something I haven’t done much of yet.

I thought it’d be interesting to create some visualisations around the times that people RSVP ‘yes’ to the various Neo4j events that we run in London.

I started off with the following query which returns the date time that people replied ‘Yes’ to an event and the date time of the event:

library(Rneo4j)
query = "MATCH (e:Event)<-[:TO]-(response {response: 'yes'})
         RETURN response.time AS time, e.time + e.utc_offset AS eventTime"
allYesRSVPs = cypher(graph, query)
allYesRSVPs$time = timestampToDate(allYesRSVPs$time)
allYesRSVPs$eventTime = timestampToDate(allYesRSVPs$eventTime)
 
> allYesRSVPs[1:10,]
                  time           eventTime
1  2011-06-05 12:12:27 2011-06-29 18:30:00
2  2011-06-05 14:49:04 2011-06-29 18:30:00
3  2011-06-10 11:22:47 2011-06-29 18:30:00
4  2011-06-07 15:27:07 2011-06-29 18:30:00
5  2011-06-06 20:21:45 2011-06-29 18:30:00
6  2011-07-04 19:49:04 2011-07-27 19:00:00
7  2011-07-05 16:40:10 2011-07-27 19:00:00
8  2011-08-19 07:41:10 2011-08-31 18:30:00
9  2011-08-24 12:47:40 2011-08-31 18:30:00
10 2011-08-18 09:56:53 2011-08-31 18:30:00

I wanted to create a bar chart showing the amount of time in advance of a meetup that people RSVP’d ‘yes’ so I added the following column to my data frame:

allYesRSVPs$difference = allYesRSVPs$eventTime - allYesRSVPs$time
 
> allYesRSVPs[1:10,]
                  time           eventTime    difference
1  2011-06-05 12:12:27 2011-06-29 18:30:00 34937.55 mins
2  2011-06-05 14:49:04 2011-06-29 18:30:00 34780.93 mins
3  2011-06-10 11:22:47 2011-06-29 18:30:00 27787.22 mins
4  2011-06-07 15:27:07 2011-06-29 18:30:00 31862.88 mins
5  2011-06-06 20:21:45 2011-06-29 18:30:00 33008.25 mins
6  2011-07-04 19:49:04 2011-07-27 19:00:00 33070.93 mins
7  2011-07-05 16:40:10 2011-07-27 19:00:00 31819.83 mins
8  2011-08-19 07:41:10 2011-08-31 18:30:00 17928.83 mins
9  2011-08-24 12:47:40 2011-08-31 18:30:00 10422.33 mins
10 2011-08-18 09:56:53 2011-08-31 18:30:00 19233.12 mins

I then tried to use ggplot to create a bar chart of that data:

> ggplot(allYesRSVPs, aes(x=difference)) + geom_histogram(binwidth=1, fill="green")

Unfortunately that resulted in this error:

Don't know how to automatically pick scale for object of type difftime. Defaulting to continuous
Error: Discrete value supplied to continuous scale

I couldn’t find anyone who had come across this problem before in my search but I did find the as.numeric function which seemed like it would put the difference into an appropriate format:

allYesRSVPs$difference = as.numeric(allYesRSVPs$eventTime - allYesRSVPs$time, units="days")
> ggplot(allYesRSVPs, aes(x=difference)) + geom_histogram(binwidth=1, fill="green")

that resulted in the following chart:

2014 07 20 01 15 39

We can see there is quite a heavy concentration of people RSVPing yes in the few days before the event and then the rest are scattered across the first 30 days.

We usually announce events 3/4 weeks in advance so I don’t know that it tells us anything interesting other than that it seems like people sign up for events when an email is sent out about them.

The date the meetup was announced (by email) isn’t currently exposed by the API but hopefully one day it will be.

The code is on github if you want to have a play – any suggestions welcome.

Categories: Blogs

With Me It’s All or Nuthin’

Agile Management Blog - VersionOne - Fri, 07/18/2014 - 21:38

Forgive me for bringing up show tunes.  I love the old musicals. One of the true classics of American all or nothingtheater is the show Oklahoma.  I got to thinking about this in a very roundabout way the other day.  The song, called “With Me It’s All or Nothing” got stuck in my head.  Let me tell you why…

If you like to cruise the various discussion groups, you will find to time see a question “When it comes to Agile practices, which ones should I do first?” or “Which Agile Practice is the most important of all?”  These questions are fun to argue about.  They are mental candy.  But the bottom line is, just like candy, they can also be bad for you.  If we decide that iterative and incremental development is the most important aspect of Agile, does that mean we can get rid of Test Driven Development?  Or, if we decide that Continuous Integration is the most important practice, does that mean we can break out the Gantt charts?  I don’t think it does.

The most egregious example I have seen in this, and it is unfortunately quite common, is the mistaken belief frustrated-programmerthat we can do all of those nifty Scrum ceremonies and activities, and ignore the development practices that make Agile work.  If you have  an iterative process that embraces change, even late in development, but have none of the practices that make that possible, you just have a lot of tired, frustrated programmers. This may be the source of some comments we’ve seen on this blog lately that say “I hate Scrum”.  I often wonder if it is Scrum that these folks hate, or if its the fact that only part of it is being used.

I’ve always seen Agile, or more specifically the implementation of Agile, as a whole package kind of deal.  The real power of Agile software development is not the fact that you do things in smaller increments, orpepperoni and mushroom pizza that you write your code test first, but in the supporting power of each of these elements.  The whole is so much more than the sum of its parts, that I can’t understand why one would chose to not implement the whole thing.  Its sort of like buying a pepperoni and mushroom pizza, then picking off all of the mushrooms.  If you didn’t want mushrooms, why did you order the pepperoni and mushroom?

This all came about because of a rather heated discussion around what is more important, Acceptance Test Driven Development, or Unit Test Driven Development.  The “antagonist” in this argument was contending that since the Unit Tests are “just for the developers” they really were unnecessary, and Acceptance Tests were all that was required.  After a while I couldn’t help but ask “why are we arguing about this?”  The real answer is we need Acceptance Test Driven Development, we need Unit Test Driven Development, Refactoring, Continuous Integration, and yes, Pair Programming.  You see, with me it really is All or Nothing.

 

Categories: Companies

Why Testing in Women Testers Magazine

Johanna Rothman - Fri, 07/18/2014 - 16:48

I have an article in a new online magazine, Women Testers, the July 2014 edition. My article is called “Why Testing?”

When I was a tester or a developer, I asked many questions. As a project manager, program manager or consultant, I still ask many questions. One of those is the Why question. This article examines that question from a number of perspectives.

Go read that article and many others from people such as Alexandra Moreira, Bolette Stubbe Teglbjærg, Smita Mishra, Sara Tabor, Karen N. Johnson, and Mike Lyles.

I bet you’ll enjoy it!

Categories: Blogs

Project Lessons Learned vs. Sprint Retrospective – 17 Points of Comparison

Learn more about our Scrum and Agile training sessions on WorldMindware.com

Another fantastic article by Mike Caspar: Sprint Retrospective vs. Lessons Learned (a Generalization)

Mike says:

Consider reviewing these differences in your environment to determine if you are getting benefit from your Sprint Retrospectives and following their intent.

 

Here are a few other Agile Advice articles about Retrospectives.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories: Blogs

Enalean announces Tuleap 7

DevAgile.com - Thu, 07/17/2014 - 19:09
Enalean, provider of Tuleap, the first Open Source Enterprise suite for Application Lifecycle Management, continues its enterprise quality 100% Open Source strategy by releasing Tuleap 7.This new release provides : Interface overhaul, Agile connector into Eclipse, Git industry-proven performance ...
Categories: Communities

Enalean announces Tuleap 7

Scrum Expert - Thu, 07/17/2014 - 19:06
Enalean, provider of Tuleap, the first Open Source Enterprise suite for Application Lifecycle Management, continues its enterprise quality 100% Open Source strategy by releasing Tuleap 7. New interface When you’ll try or install Tuleap (demo at demo-tuleap.enalean.com or free installation at tuleap.net), you’ll notice at first glance that the software gets a new look with an interface overhall : more friendly, easier to use…and that’s just the beginning. For Tuleap 7.0, interface updates have been applied to the artifacts view (tasks, bugs…), charts and agile tools. New Agile Tools Tuleap 7 is much easier ...
Categories: Communities

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.