Skip to content

Feed aggregator

[AgileScotland] Agile coaching course & conference update

Agile Scotland - Mon, 09/28/2015 - 18:43
1.  Wow!  This is cool news.  Greg @ Skyscanner just pinged me to let me know that they'll be hosting Lyssa Adkins (the author of Coaching Agile Teams) and Michael Spayd in November.
They'll be running their  Coaching Agile Teams workshop.  The details are:
  • In their words – Coaching Agile Teams is a three day workshop for experienced Agilists who wish to dramatically increase their overall agile coaching skills and effectiveness
  • It will run on November 9th – November 11th at Skyscanner's Edinburgh office 
  • You can find full details of the workshop here
  • And you can book yourself on the course here (there are 20 confirmed attendees already so don't wait too long to book…)
2.  I had lunch with Chris McDermot and he told me that the LeanAgileScotland conference, which spends all his spare time organising, is very close to selling out.  
Take a look here:  
If you're keen then I'd pounce quickly, especially if you're looking for single day tickets.
Categories: Communities

Scrum & Kanban Open Source Tools for Bugzilla

Scrum Expert - Mon, 09/28/2015 - 17:24
Bugzilla is a popular open source bug tracker created originally by the Mozilla Foundation. It has an open architecture that allows extending its basic functionalities. This article lists the Bugzilla plugins, called add-on in Bugzilla, that allows integrating an Agile project management approach like Scrum or Kanban around the bug tracking features of Bugzilla. There are currently 5 open source plugins that allows to add Scrum and Kanban features so that you can integrate an Agile project management approach with the basic functionalities of the Bugzilla open source bug tracking tool. ...
Categories: Communities

Doing Distributed Retrospectives with Retrium

Ben Linders - Mon, 09/28/2015 - 16:37
The Retrium tool for on-line retrospectives is a tool that makes retrospectives for distributed teams easy and effective. Team can use Retrium to reflect, learn and improve continuously. Continue reading →
Categories: Blogs

Do ES6 Arrow Functions Really Solve “this” In JavaScript?

Derick Bailey - new ThoughtStream - Mon, 09/28/2015 - 13:30

In the process of recording an episode on MongoDB / MongooseJS for WatchMeCode, I tried to use the new ES6 Arrow syntax for a callback on a Mongoose model’s method definition:

Everything looked like it was going to work – Yay! ES6 functions, running natively in Node!

But, then I tried to run the code.

Undefined this

At first, I thought this was a problem with Mongoose. But it’s not. It’s a problem with the way JavaScript evaluates “this” inside arrow functions.

When “this” Attacks

While I am nearly madly in love with the new (arrow) => { “function”; } syntax in ES6, it turns out there’s a downside to it in some circumstances – and the Mongoose implementation of it’s “method” … method … is a good example.

But let’s break it down in to something easier to understand, while reproducing the problem. 

Simplify The Problem

Start by creating a “method” method on an object.

This method takes in a callback function and assigns it to the object, by name. This is effectively creating a method on my object, as show below:

In this example, I am creating a “bar” method that does nothing more than a console.log. This code isn’t terribly exciting, but it sets up the scenario where ES6 arrow functions will fail. 

It Doesn’t Work The Way You Think It Does

With that in place, let’s add a bit of data to the object and to the module in which the code is contained. 

Line 3 attaches some data to the module level “this”. Line 6 uses the same attribute name, but on the “foo” object. After that, the same “method” method is set up, and a “bar” method is added, using the () => arrow function syntax instead of a regular function callback. 

Study this code for a moment and try to figure out what the call to “” will produce.

I expected it to say “attached to an object”. But instead, it says “attached to the module”… WHAT?!

How “this” Works With Arrow Functions

The ES6 arrow function syntax uses “lexical scoping” to figure out what the value of “this” should be. Lexical scoping is fancy way of saying it uses “this” from the surrounding code… the code that contains the code in question. 

In this case, the module contains the call to “foo.method(() => {… })”. There is no other code surrounding this call on line 16 of the above example. That means the value of “this” will always be the module, within that arrow function.

That is not what I wanted, nor is that what I expected.

What I want is the value of “this” to point at the “foo” object. To do that, I have to ditch arrow functions on line 16 and go back to standard “function” syntax for the callback:

In this example, the standard function syntax is used for the callback on line 16. The value of “this” is then managed by the other rules for JavaScript’s “this”, producing the expected result, “attached to an object”.

You Can’t Override An Arrow Function’s “this”

Given the lexical scoping problem and my desire to use arrow functions whenever I can, I thought that I would try to override the value of “this” when attaching my methods to the object. So I updated the code to use .bind and try to force “this” to be what I wanted:

Normally, having the .bind call on line 12 would force the value of “this” to always be the object that I want, on the method I am creating. But with arrow functions, this isn’t the case. No matter how hard I try to .bind the method to a specific context, it will not change. The ES6 arrow function syntax will always override any previously bound or dynamically determined value of “this”.

It seems, then, that arrow functions have a pretty severe limitation in their use. This limitation introduces yet another scenario where the specific behavior of a feature related to “this” has to be understood completely, or it will drive more developers to madness. 

Be Careful With Arrow Functions

Arrow functions are a tremendously powerful addition to ES6, and a feature that I use constantly. I appreciate the effort to make arrow functions work well and be consistent in behavior. But I continuously find places like this, where arrow functions are not usable.

While the intention was good and the direction is good, you can add ES6 arrow functions to the list rules that have to be mastered in all their nuance, to get the most out of “this” in JavaScript.

Categories: Blogs

Agile Slovenia, Ljubljana, Slovenia, December 3-4 2015

Scrum Expert - Mon, 09/28/2015 - 13:00
Agile Slovenia is a two-days conference focused on Agile and Scrum topics that take place in Ljubljana. Agile Slovenia is an event where you can turn theory in action, meet agile people, listen to agile pioneers, expand your knowledge. It features both local and international Agile experts. In the agenda of Agile Slovenia you can find topics like “Shifting from manufacturing product to creating a service”, “Complex Projects aren’t planable but controllable”, “There’s no such thing as an agile contract”, “How Agile Coaches help us win – the Agile Coach role ...
Categories: Communities

Learning How to Deal with Impediments Effectively

Ben Linders - Mon, 09/28/2015 - 09:11
In the impediment game people learn to recognize and analyse impediments and how to take appropriate action by deploying agile and lean good practices. I will play the impediment game with teams at the Agile Tour Brussels 2015 on November 2. Continue reading →
Categories: Blogs

R: data.table – Comparing adjacent rows

Mark Needham - Mon, 09/28/2015 - 00:02

As part of my exploration of the Land Registry price paid data set I wanted to compare the difference between consecutive sales of properties.

This means we need to group the sales by a property identifier and then get the previous sale price into a column on each row unless it’s the first sale in which case we’ll have ‘NA’. We can do this by creating a lag variable.

I’ll use a simpler data set which is very similar in structure to the Land Registry’s to demonstrate:

> blogDT = data.table(name = c("Property 1","Property 1","Property 1","Property 2","Property 2","Property 2"), 
                      price = c(10000, 12500, 18000, 245000, 512000, 1000000))
> blogDT
         name   price
1: Property 1   10000
2: Property 1   12500
3: Property 1   18000
4: Property 2  245000
5: Property 2  512000
6: Property 2 1000000

We want to group by the ‘name’ column and then have the price on row 1 show on row 2, the price on row 2 on row 3, the price on row 4 on row 5 and the price on row 5 on row 6. To do that we’ll introduce a ‘lag.price’ column:

> blogDT[, lag.price := c(NA, price[-.N]), by = name]
> blogDT
         name   price lag.price
1: Property 1   10000        NA
2: Property 1   12500     10000
3: Property 1   18000     12500
4: Property 2  245000        NA
5: Property 2  512000    245000
6: Property 2 1000000    512000

Next let’s calculate the difference between the two prices:

> blogDT[, diff := price - lag.price]
> blogDT
         name   price lag.price   diff
1: Property 1   10000        NA     NA
2: Property 1   12500     10000   2500
3: Property 1   18000     12500   5500
4: Property 2  245000        NA     NA
5: Property 2  512000    245000 267000
6: Property 2 1000000    512000 488000

Finally let’s order the data table by the biggest price gains:

> blogDT[order(-diff)]
         name   price lag.price   diff
1: Property 2 1000000    512000 488000
2: Property 2  512000    245000 267000
3: Property 1   18000     12500   5500
4: Property 1   12500     10000   2500
5: Property 1   10000        NA     NA
6: Property 2  245000        NA     NA
Categories: Blogs

[AgileScotland] Turbo-charge Agile with Goldratt's TOC (free public course, here in Scotland)

Agile Scotland - Sun, 09/27/2015 - 22:03
I'm *thinking* about running a free "TOC for software development" public course here in Scotland for my Agile friends (and friends to be), probably 2 or 3-nights worth, probably after work, probably in Edinburgh, probably starting in November or January.
Loads of "probably"s ...
These things are definite: - you'll learn how to deliver software faster, - you'll learn how to improve faster, - you'll learn how to deliver projects on time.  
This stuff works.  It's what I do in my day job and there are a lot of other "advanced practitioners" quietly doing TOC all around the world, and even a half-dozen in Scotland.  You might have seen my book about TOC in Software Development, "Rolling Rocks Downhill", or "The Phoenix Project" which is about DevOps, or maybe you've even read the original TOC book, Eli Goldratt's "The Goal" and wondered how it applies to your work.  It's simple stuff, though not necessarily easy, and it's more than just finding bottlenecks.
If you're interested let me know:
Categories: Communities

How to handle [fill-in-the-blank] work in Scrum

DFW Scrum User Group - Sun, 09/27/2015 - 14:17
As more teams are adopting Scrum around Dallas, I’ve been hearing more questions about how to handle work that is not specifically requested by the Product Owner.  How do you handle production support issues in Scrum?  How about technical debt? … Continue reading →
Categories: Communities

Code Profiling

Doc On Dev - Michael Norton - Sat, 09/26/2015 - 21:12
I recently gave a talk on the role of a Quality Analyst as an organization transitions from waterfall to agile. The talk was entitled "Switching Horses in Midstream" and covered a number of topics. One item in particular struck me as worthy of blogging about. It's a technique I've been using for years, but have never written about it. So here we go:

Legacy code bases with a lack of test coverage are often trepidatious places to hang out. You never know when a simple abstract method is going to create a sink-hole of logic and reason, eventually leading to your exhausted resolve to revert and leave it dirty.

Whenever I encounter a code base that lacks unit tests, I begin with a technique I call "Code Profiling". This is a nod to criminal behavioral profiling where scientists observe objectively and describe patterns observed.

First of all, you need a naming convention for your unit test. I don't much care what it is. I mean, I have an opinion or two on the matter, but for the purpose of this article and this technique, you just need to pick something and stick with it. Today, I'm going to go with a "Should_ExpectedBehavior_When_StateUnderTest" pattern as it lends itself well to this technique.

So let's say we're looking at a postal address class.

This is a close proximity of a class I encountered at a client a few years back. All of our properties have getters and setters. Pretty basic stuff at first glance.
When we profile the class, we change our naming convention from "Should_ExpectedBehavior_When_StateUnderTest" to "Does_ObservedBehavior_When_StateUnderTest". The key difference here is the "Does" instead of the "Should". The point is to clearly identify these as tests that were written after encountering untested code and are based on observed behavior.
For this particular class, we notice that both StateCode and StateName have getters and setters and that the StateName is optional in the constructor whereas StateCode is required. This is .... odd.
After reading the code a bit, we figure it would be entirely possible to set a StateCode and StateName that do not match. We take a look at the constructor and it protects against this by looking up the StateCode in a hash. If the StateName does not match, the code silently changes StateName to the match from the hash and moves on. No error. And a little more checking shows that we can update the StateName directly with no change to StateCode.
And here is the subtle significance of this approach. We make no judgement about what "Should" happen. We simply record what "Does" happen. The developers that missed this in the first place were likely thinking about what "Should" happen and missed these possible issues.
Now run through the tests with your product owner and/or QA. For those that are the desired behavior, rename them to fit the standard convention. For those that are not the desired behavior, if any, decide if they need to be fixed now or if they can be deferred. It is possible that the issue has been in the code for years and while it's annoying it is not an urgent fix. And it might take a lot of unravelling to actually fix it.
Your tests now indicate the desired behavior and the observed behavior that is not desired, but is not entirely "broken".
When you want to bring the behavior into alignment with expectation, I suggest commenting out the "Does" test and writing as many "Should" tests as necessary. Then, un-comment the "Does" test, ensure it fails, and delete it.

Categories: Blogs

New Case Study: Small company downscales SAFe to handle big-growth challenges

Agile Product Owner - Fri, 09/25/2015 - 17:31

infoqseamlessThe Seamless Payments case study recently highlighted in the recent InfoQ article, “Downscaling SAFe,” puts to rest a couple of popular misconceptions about SAFe: 1) it is solely for large enterprises, and 2) that it is too prescriptive.

The authors describe a fast-moving mobile payment startup about to cross the chasm from “Early Adopters” to “Early Majority;” the critical growth phase where companies are known to be especially vulnerable to failure. With 200+ employees spanning 4 countries, they turned to a slimmed down version of SAFe—along with major technical investments in the deployment pipeline—to provide a structure that would provide a solution for current challenges, and accommodate growing complexity.

The story of their SAFe transformation comes from Agile and Lean Product Development Expert, Mikael Lundgren, and Seamless Payments’ Software Engineering Manager, Tomek Pająk. They provide an account of the experience that is rich with detail, and goes beyond tactical execution to include the strategic thinking behind this scaled-down transformation. They recount:

  • How they down-scaled SAFe while maintaining its core ideas
  • Tools utilized for managing backlogs of features, epics, and stories
  • Recruiting Scrum Masters to act as Agile coaches for the entire organization
  • Establishing new roles to better support working environment
  • Introducing WIP-limited program execution where work is planned in Agile Release Trains

To sum up, the case study of Seamless is evidence that small or medium-sized companies can benefit from a scaled agile framework with custom modifications.”

Many thanks to Mikael Lundgren and Tomek Pająk for sharing your story and providing inspiration for small to medium-sized companies seeking scalable solutions as they face similar growth challenges.

Link to the case study here:

And if you haven’t already checked it out, make sure to visit our case studies page. We’ve got a fast-growing inventory of SAFe studies that are both inspiring and enlightening.

Stay SAFe,



Categories: Blogs

Creating a Shared Understanding

Leading Agile - Mike Cottmeyer - Fri, 09/25/2015 - 14:56

User stories are intended to communicate a shared understanding between a product owner and a scrum team. There is a standard accepted and anticipated format that helps promote consistency, and having good acceptance criteria attached to the story defines and clarifies scope.

But there is a very good reason why one of the principles of the agile manifesto states:

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Sometimes simple examples are the most effective examples. Here is something that happened to me today that made me consider the importance of communication for clarifying requirements.

First, some background. A few months ago, I created a model and a template that helps us evaluate and assess skill gaps for ScrumMasters who we’re working with. Once we identify skill gaps that we want the ScrumMaster to improve, we have specific skill-training modules (as an adjunct to our personal coaching plan) we can suggest that the ScrumMaster review.

This morning, I had some colleagues reach out to me. Here is the dialog that resulted.

Lisa – “Hi Jim, I am at a client with Jeff this week. I sat in on a session where Jeff was going through the scrum master assessment with a scrum master.  He would like to see if the dates could not be hardcoded in the legend on the graph.  Are you able to make that adjustment? Thanks, Lisa”

Jim (that’s me) – “I don’t know why you’d want to do that, Lisa.  To me, that implies that everyone will achieve competency within a six-week window.  In addition, I don’t see an easy way for me to make this change in Excel.  Not saying there isn’t a way, but I’ve looked at it a bit this morning and it is not evident how I’d make this change and still keep the template flexible for everyone’s use. What exactly is the issue with the way the graph dates extend out currently?”

Jeff – “Using today’s date doesn’t show in the graph.”

Jim – “Ok, I just tried that and you are right…that seems to break things.  That’s a different problem than what I understood described in Lisa’s note.  Let me look at that.”

Lisa and I were obviously on completely different pages in our initial interaction. Jeff weighed in with more information, and suddenly we had a shared understanding.

If we can experience confusion when communicating requirements that are this simple, consider how much more difficult a shared understanding is in the context of lots of teams working together in a large enterprise to bring a new feature to their customer.

Don’t underestimate the importance of building the right team structure, of implementing the right governance model, and of putting a process in place that enables collaboration to drive the ever-necessary shared understanding.

The post Creating a Shared Understanding appeared first on LeadingAgile.

Categories: Blogs

Working Effectively with Legacy Tests

Mistaeks I Hav Made - Nat Pryce - Fri, 09/25/2015 - 13:00
At the Agile Cambridge conference on the 1st of October, Duncan McGregor and I are running a workshop entitled Working Effectively with Legacy Tests. Legacy what‽ In Working Effectively with Legacy Code, Michael Feathers defined "legacy code" as "code without tests". But not all test code is a panacea. I have often encountered what I can only describe legacy tests. I define legacy tests as: You have legacy tests if you usually change the code then fix the tests to match the code Legacy tests are still useful. They reduce risk by catching unexpected regressions. But it is often difficult to know why a regression occurs and time is wasted diagnosing the underlying problem. Legacy tests don't pull their weight. They add a continual overhead to every change you make. Symptoms of legacy tests I have encountered include: Programmers have to read the production code to work out what the system does, rather than the tests. When a test fails programmers usually have to fix the test, not production code. When a test fails programmers have to step through code in the debugger to work out what failed. It takes a lot of effort to write a test, and after a few tests, writing another test isn’t any easier. Programmers have to carefully study the code of a test to work out what it is actually testing. Programmers have to carefully study the code of a test to work out what it is not testing. Tests are named after issue identifiers in the company's issue tracker. Bonus points if the issue tracker no longer exists. Test failures are ignored because the team know they are transient or meaningless. Does any of that sound familiar? If so, please bring some examples of your tests to our workshop. We will run the workshop as a cross between a mob programming session and a clinic. Bring some legacy tests from your own projects. We will work together, in a mob programming style, to improve them. Along the way we will share techniques for writing effective tests and refactoring tests from burdensome legacy to a strategic asset. Cartoon by Thomas Rowlandson, uploaded to Flickr by Adam Asar. Used under the Creative Commons Attribution 2.0 Generic license.
Categories: Blogs

New Blog Entry at

NetObjectives - Fri, 09/25/2015 - 12:47
Test-Driven Development can be tough to get started, sometimes, because people feel it won't be worth the extra effort. We have a blog about that: Let us know what you think in the comments section! -Scott Bain- Author: Scott BainTopics: TDDATDD

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

R: Querying a 20 million line CSV file – data.table vs data frame

Mark Needham - Fri, 09/25/2015 - 08:28

As I mentioned in a couple of blog posts already, I’ve been exploring the Land Registry price paid data set and although I’ve initially been using SparkR I was curious how easy it would be to explore the data set using plain R.

I thought I’d start out by loading the data into a data frame and run the same queries using deployer.

I’ve come across Hadley Wickham’s readr library before but hadn’t used it and since I needed to load a 20 million line CSV file this seemed the perfect time to give it a try.

The goal of readr is to provide a fast and friendly way to read tabular data into R.

Let’s’ get started:

> library(readr)
> system.time(read_csv("pp-complete.csv", col_names = FALSE))
   user  system elapsed 
127.367  21.957 159.963 
> df = read_csv("pp-complete.csv", col_names = FALSE)

So it took a little over 2 minutes to process the CSV file into a data frame. Let’s take a quick look at its contents:

> head(df)
Source: local data frame [6 x 16]
                                      X1     X2     X3       X4    X5    X6    X7    X8    X9
                                   (chr)  (int) (date)    (chr) (chr) (chr) (chr) (chr) (chr)
1 {0C7ADEF5-878D-4066-B785-0000003ED74A} 163000   <NA>  UB5 4PJ     T     N     F   106      
2 {35F67271-ABD4-40DA-AB09-00000085B9D3} 247500   <NA> TA19 9DD     D     N     F    58      
3 {B20B1C74-E8E1-4137-AB3E-0000011DF342} 320000   <NA>   W4 1DZ     F     N     L    58      
4 {7D6B0915-C56B-4275-AF9B-00000156BCE7} 104000   <NA> NE61 2BH     D     N     F    17      
5 {47B60101-B64C-413D-8F60-000002F1692D} 147995   <NA> PE33 0RU     D     N     F     4      
6 {51F797CA-7BEB-4958-821F-000003E464AE} 110000   <NA> NR35 2SF     T     N     F     5      
Variables not shown: X10 (chr), X11 (chr), X12 (chr), X13 (chr), X14 (chr), X15 (chr), address (chr)

Now let’s query the data frame to see which postcode has the highest average sale price. We’ll need to group by the ‘X4’ column before applying some aggregate functions:

> library(dplyr)
> system.time(df %>% 
                group_by(X4) %>% 
                summarise(total = sum(as.numeric(X2)), count = n(), ave = total / count) %>%
   user  system elapsed 
122.557   1.135 124.211 
Source: local data frame [1,164,396 x 4]
         X4     total count      ave
      (chr)     (dbl) (int)    (dbl)
1   SW7 1DW  39000000     1 39000000
2  SW1W 0NH  32477000     1 32477000
3   W1K 7PX  27000000     1 27000000
4  SW1Y 6HD  24750000     1 24750000
5   SW6 1BA  18000000     1 18000000
6  SW1X 7EE 101505645     6 16917608
7    N6 4LA  16850000     1 16850000
8  EC4N 5AE  16500000     1 16500000
9    W8 7EA  82075000     6 13679167
10  W1K 1DP  13500000     1 13500000

What about if instead of the average price by post code we want to find the most expensive property ever sold instead?

> system.time(df %>% group_by(X4) %>% summarise(max = max(X2)) %>% arrange(desc(max)))
   user  system elapsed 
 35.438   0.478  36.026 
Source: local data frame [1,164,396 x 2]
         X4      max
      (chr)    (int)
1  SW10 9SU 54959000
2   SW7 1QJ 50000000
3  SW1X 8HG 46013365
4   SW7 1DW 39000000
5  SW1W 0NH 32477000
6  SW1X 7LJ 29350000
7    W8 7EA 27900000
8   SW3 3SR 27750000
9   W1K 7PX 27000000
10 SW1X 7EE 25533000
..      ...      ...

Interestingly that one was much quicker than the first one even though it seems like we only did slightly less work.

At this point I mentioned my experiment to Ashok who suggested I give data.table a try to see if that fared any better. I’d not used it before but was able to get it up and running reasonably quickly:

> library(data.table)
> system.time(fread("pp-complete.csv", header = FALSE))
Read 20075122 rows and 15 (of 15) columns from 3.221 GB file in 00:01:05
   user  system elapsed 
 59.324   5.798  68.956 
> dt = fread("pp-complete.csv", header = FALSE)
> head(dt)
                                       V1     V2               V3       V4 V5 V6 V7  V8 V9
1: {0C7ADEF5-878D-4066-B785-0000003ED74A} 163000 2003-02-21 00:00  UB5 4PJ  T  N  F 106   
2: {35F67271-ABD4-40DA-AB09-00000085B9D3} 247500 2005-07-15 00:00 TA19 9DD  D  N  F  58   
3: {B20B1C74-E8E1-4137-AB3E-0000011DF342} 320000 2010-09-10 00:00   W4 1DZ  F  N  L  58   
4: {7D6B0915-C56B-4275-AF9B-00000156BCE7} 104000 1997-08-27 00:00 NE61 2BH  D  N  F  17   
5: {47B60101-B64C-413D-8F60-000002F1692D} 147995 2003-05-02 00:00 PE33 0RU  D  N  F   4   
6: {51F797CA-7BEB-4958-821F-000003E464AE} 110000 2013-03-22 00:00 NR35 2SF  T  N  F   5   
               V10         V11         V12                          V13            V14 V15
3:   WHELLOCK ROAD                  LONDON                       EALING GREATER LONDON   A

So we’ve already gained one minute in the parsing time which is pretty nice. Let’s try and find the postcode with the highest average price:

> dt[,list(length(V2), sum(V2)), by=V4][, V2 / V1, by=V4][order(-V1)][1:10]
Error in sum(V2) : invalid 'type' (character) of argument

Hmmm, seems like we need to make column ‘V2’ numeric. Let’s do that:

> dt = dt[, V2:= as.numeric(V2)]
> dt[,list(length(V2), sum(V2)), by=V4][, V2 / V1, by=V4][order(-V1)][1:10]
   user  system elapsed 
  5.108   0.670   6.183 
          V4       V1
 1:  SW7 1DW 39000000
 2: SW1W 0NH 32477000
 3:  W1K 7PX 27000000
 4: SW1Y 6HD 24750000
 5:  SW6 1BA 18000000
 6: SW1X 7EE 16917608
 7:   N6 4LA 16850000
 8: EC4N 5AE 16500000
 9:   W8 7EA 13679167
10:  W1K 1DP 13500000

That’s quite a bit faster than our data frame version – ~5 seconds compared to ~2 minutes. We have lost the total sales and number of sales columns but I expect that’s just because my data.table foo is weak and we could keep them if we wanted.

But a good start in terms of execution time. Now let’s try the maximum sale price by post code query:

> system.time(dt[,list(max(V2)), by=V4][order(-V1)][1:10])
   user  system elapsed 
  3.684   0.358   4.132 
          V4       V1
 1: SW10 9SU 54959000
 2:  SW7 1QJ 50000000
 3: SW1X 8HG 46013365
 4:  SW7 1DW 39000000
 5: SW1W 0NH 32477000
 6: SW1X 7LJ 29350000
 7:   W8 7EA 27900000
 8:  SW3 3SR 27750000
 9:  W1K 7PX 27000000
10: SW1X 7EE 25533000

We’ve got the same results as before and this time it took ~4 seconds compared to ~35 seconds.

We can actually do even better if we set the postcode column as a key:

> setkey(dt, V4)
> system.time(dt[,list(length(V2), sum(V2)), by=V4][, V2 / V1, by=V4][order(-V1)][1:10])
   user  system elapsed 
  1.500   0.047   1.548 
> system.time(dt[,list(max(V2)), by=V4][order(-V1)][1:10])
   user  system elapsed 
  0.578   0.026   0.604

And that’s as far as I’ve got with my experiment. If there’s anything else I can do to make either of the versions quicker do let me know in the comments.

Oh and for a bit of commentary on what we can learn from the queries…Knightsbridge is a seriously expensive area to live!

Categories: Blogs

Agile Elements

Agile Elements - Thu, 09/24/2015 - 23:35

National Podium

Agile is a way of approaching business.  It is about delivering value in everything. It is about always learning and always doing better. It is about creative problem solving. It is about discovery as you go and drawing on experience. It is about having enough savvy to know that no two problems are quite alike and enough experience to confidently explore differences. Agility gives us room to maneuver and grow. It is in that spirit that, my blog, Agile Elements is published.

Categories: Blogs

Lean Leadership, Culture and Tools

Watch this webinar to learn how Lean leadership, culture and tools form the foundation of lasting change. About This Webinar Chris Hefley, CEO at LeanKit, explains how without three elements — leadership, culture and tools — our efforts at Lean transformation are little better than building castles in the sand. During this session, Chris discusses: – The […]

The post Lean Leadership, Culture and Tools appeared first on Blog | LeanKit.

Categories: Companies

Agile Metrics That Matter

Scrum Expert - Thu, 09/24/2015 - 16:04
This session is born of the hard lessons learned from years of working with diverse companies using metrics to improve their software development processes. Come learn from our successes and be warned by our failures. This session covers what makes an effective Agile metric, the pitfalls in designing metrics, and the basic principles for using metrics appropriately. We cover many general principles, but dive deeply in the metrics needed for lean and agile software practices, using Kanban and Scrum as our representative methodologies. You’ll leave with a number of good metrics ...
Categories: Communities

Agile Metrics

TV Agile - Thu, 09/24/2015 - 15:57
This presentation discusses the good the bad and the ugly of Agile metrics: * What makes a good metric? * Why should you use metrics? * What are some examples of metrics? * Are there any majors to avoid? Video producer:
Categories: Blogs

Interactive mind map for meetings and retrospectives

TargetProcess - Edge of Chaos Blog - Thu, 09/24/2015 - 10:40

We wrote some time ago about our initiatives for visualizing data and project information for smarter and more effective decision making. Today we would like to share an online Ishikava (fishbone) diagram:

This is a kind of mind map that can help you better understand a problem by visualizing its causes. It can be also used in retrospectives and work meetings where a group of people can analyze different aspects of a process or a situation for a multi-perspective view of the problem and a well-thought-out solution.

We have made it interactive so that it is possible to track a brainstorming flow as a structured text list on the left and immediately get a visual diagram on the right. Also you can drill-down to a particular aspect by double-clicking it if you want to explore an aspect of a precedent separately.

The concept of the diagram was developed by Kaoru Ishikawa in 1968 to show the causes of a specific event ( We were also inspired by the “Rule of 5 why” (, an iterative interrogative technique used to understand the root cause of the problem or a defect.

Any feedback is welcome!

Categories: Companies

Knowledge Sharing

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