Skip to content

Feed aggregator

TDD and Asychronous Behavior

NetObjectives - Tue, 10/21/2014 - 15:39
Test-Driven Development posits that all behaviors in a system should be specified in tests. Sometimes this appears to be challenging either because the system has design flaws that make it hard to test, or because the technique needed to create the tests is not immediately clear. Sometimes it is a bit of both. At our blog Sustainable TDD, Amir Kolsky and I have outlined the techniques needed for...

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

Do we need a Tech Lead? - Tue, 10/21/2014 - 12:03

A common question I hear is, “Is the Tech Lead role necessary?” People argue against the role, claiming a team of well functioning developers can make decisions and prioritise what is important to work on. I completely agree with this position in an ideal world. Sadly the ideal world rarely exists.

Even when perfect conditions exist during which team members talk to each openly, discussing pros and cons before arriving at an agreed solution, it doesn’t take much to upset this delicate balance. Sometimes all it takes is for a new person joining the team, a person leaving or some stressful critical situation that drives the team into a state where arguing continues without end. My friend Roy Osherove calls this the “Chaos state.” I agree with him that a different style of leadership may be required, similar to the Situational Leadership Model.

Technical debates occur frequently in development teams. There is nothing worse than when the team reaches a frozen state of disagreement.

Tabs Spaces
Image take from Emacswiki

The Tech Lead has the responsibility to help the team move forwards. Sometimes that means using their authority. Sometimes it means working with the team to find a way forward. Facilitation and negotiation skills are invaluable assets to a Tech Lead. Understanding decision making models helps the Tech Lead decide when to step in, or when to step back. What is important is finding a way forward.

Tech Leads are also beneficial to people outside of the team, forming a single point of contact. Medium to large organisations start to hit communication barriers because there are too many relationships to effectively build and maintain. The Tech Lead role simplifies the communication path, although simultaneously adds a single point of failure. The balance between these two trade-offs should be carefully managed and monitored.

When played well, the Tech Lead provides countless other benefits, however the Tech Lead role does not have to played by a single person. I admire teams who say they don’t have a Tech Lead and software is still effectively delivered. They have successfully distributed the Tech Lead responsibilities or established processes to mitigate the need for the role. It does not necessarily mean the role itself is useless. The Tech Lead role is just that – just a role. Instead of focusing on whether or not the role should or should not exist, it is better to focus on ensuring all Tech Lead responsibilities are met.

If you liked this article exploring the Tech Lead role, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Categories: Blogs

Best Practices for a Culture of Continuous Improvement

TV Agile - Tue, 10/21/2014 - 09:14
Doing Kanban for the sake of doing it is unsexy and has usually rather low value. Introducing Kanban means working towards the vision of a culture of continuous improvement. Surprisingly, the cultural change does not happen magically after a change agent pushed the practices of Kanban into a company. The cultural change already starts by […]
Categories: Blogs

Fighting Prejudices Against Agile - Tue, 10/21/2014 - 08:35
Adopting new software development approaches like Agile and Scrum is always a challenge. There is a natural tendency for part of an organization to resist changing and some prejudices exist against Agile, mainly due to a lack of knowledge.
Categories: Communities

Time After Time

Agile Tools - Tue, 10/21/2014 - 08:07


Last year I led an effort to implement time tracking for our teams. A quick warning is probably in order here:

Never, ever, be the person who introduces time tracking at a company. You will be reviled before the gods and your name shall be stricken from the roles of the Agile. People will avoid you at parties, your kids will spurn you, and your pets will pee in your shoes. On the bright side, that Darth Vader helmet you have sitting in the closet will suddenly seem like a good thing to wear around the office.

So, now that we have that out of the way, back to our story. So I was leading this effort to introduce time tracking to all of the developers in our little corner of the company. The idea that had lead to this little misadventure was simple enough: if we used a time tracking tool we will get more detailed information about where time is being spent on projects than if we just make some educated guesses using excel spreadsheets (our existing mechanism). This will give us higher quality information and we will enable us to automatically handle things like capitalization easily.

That was the idea. If we ask people to report their time daily, they will give us a more accurate picture of the time that they are spending on the work. Simple enough. Our old system of excel spreadsheets made a lot of assumptions that probably weren’t true. For example:

  • Everyone works an 8 hour day
  • Everyone on a team works on a given project at the same time
  • Team membership doesn’t change during the sprint

If you use those rules then you can come up with some rough estimates for how many hours the team put into any given project on a sprint by sprint basis. You have to assume that any errors or mistakes will just be averaged out over time. That makes the time tracking very simple to do, but it makes the finance guys twitchy. They get anxious because you are making a lot of assumptions about things that we all know probably aren’t true. And they really don’t like that “It all kinda works out on average” bit either.

So we decided to go down the path of detailed time tracking. Give up all hope ye who enter here. Detailed time tracking doesn’t assume much: every hour of the day must be accounted for. However there is one hidden assumption:

  • Everyone will bother to take the time to accurately report their time for every day.

And there’s the rub. Very few people actually report their time accurately. First, you have to understand that they are ticked off that they are even asked to enter time. Second, they are very likely already entering their time in other places, like agile project management tools, HR vacation tracking tools, contractor management tools, etc. A single person might have to enter their time in 4 different systems! All you have done is add one more tool to the list and it is definitely not welcome.

So how do they use it? They either book all 8 hours of their day to the project and copy and paste every day, or they take one example day and copy and paste that. You aren’t going to get the real data, because the people using the system don’t really want to give it to you. At the end of a long day, nobody wants to have to sit down and try and figure out how much of their day was wasted in all those godawful meetings. They just don’t.

Oh, I suppose you could try policing it better – good luck with that.

You might come away from this little diatribe with the impression that I dislike time tracking. That’s not true. I realize there is a legitimate need for it in our business. However implementing it is much tougher than I realized and it’s very easy to find that the benefits really aren’t that clear at the end of it all.

Filed under: Agile, Process Tagged: benefits, time tracking
Categories: Blogs

Der krumme Ski oder wie Scrum in die Hardware zurückkam

Scrum 4 You - Tue, 10/21/2014 - 07:45

Könnt ihr euch noch an diese geraden Ski-Bretter erinnern, die schier nicht mehr zu bewältigen waren, wenn sie eine gewisse Länge überstiegen? Nur mit viel Kraft und technischem Geschick kam man heil den Berg hinunter.

1870 wurde in Norwegen der Carving-Ski erfunden und obwohl er deutlich leichter zu lenken war, konnte er sich am Markt (zunächst) nicht durchsetzen. Anfang der 1990er hatte jemand die Idee, dass es doch lustiger wäre, auf nur einem Brett zu rutschen, und hat das Snowboard erfunden. Den Berg auf einem stylischen und wendig geschnittenen Board hinabzugleiten, hat viel mehr Spaß gebracht, als sich mit diesen langen Ungetümen von Skiern abzuquälen. Skifahren war plötzlich was für unicolore Langeweiler, Snowboarden was für die coolen Bunten. Die Ski-Industrie geriet unter Druck. Als Reaktion darauf wurde begonnen, Skier – ebenso wie Snowboards – an den Enden breiter und in der Mitte schmaler zu machen. Wiedergeboren war der Carving-Ski, der den Skisport neu belebte. Denn ein Carving-Ski ist leichter zu lenken, ist wendiger und macht mehr Spaß, auch ohne viel Kraft einsetzen zu müssen.

Ganz ähnlich befruchten sich die Entwicklungsprozesse in der traditionellen Fertigungsindustrie (Hardware) und in der digitalen Welt der Software-Industrie. Die ersten Erfahrungen mit agilen Methoden wurden in der Flugzeugindustrie bereits 1943 gemacht, als die Alliierten eine schnelle Antwort auf die deutsche ‘Wunderwaffe’ brauchten. Zu Beginn wurde Software genau wie Hardware nach dem Engineering-Ansatz entwickelt: Plan – Design – Implement – Test – Wasserfall. Das war erfahrungsgemäß unzuverlässig in der Planung, teuer und vor allem hat es lange gedauert, bis man Feedback zu Entscheidungen bekam. Daher ist die Software-Industrie auf Scrum und andere agile Methoden umgestiegen und hat begonnen, ihre Produkt in Inkrementen zu entwickeln. Feedback wurde so nach jedem Schritt eingeholt und am Ende gab es ein Produkt, das wirklich einen Mehrwert lieferte. Und mehr Spaß macht es auch noch, weil die Entwickler selbstbestimmter arbeiten und in besserer Qualität produzieren können.

Das hat die hardwareproduzierende Industrie, aus Branchen wie Medizintechnik und Automotive, neugierig gemacht. Durch immer kürzere Innovationszyklen im Markt stoßen sie mit klassischen Projektsteuerungsmethoden bei der Umsetzung an Grenzen. Dank moderner Prototyp-Technologien lassen sich Ideen immer schneller in greifbare Ergebnisse verwandeln, mit denen Erfahrungen gemacht werden können. Der Weg zur Nutzung von Scrum ist frei und wird immer freier.
Mit Scrum ist jetzt auch die Hardware-Industrie wendiger und es braucht weniger Krafteinsatz, um Projekte erfolgreich umzusetzten. Und wer weiß, vielleicht verabschieden sie sich ja auch vom unicoloren blue-collar und werden bunter  ;-)

Related posts:

  1. Brief an einen jungen Projektmanager
  2. Der Wille zur Lieferung Von Franz Zauner / WZ Online
  3. Agile Hardwareentwicklung mit Scrum

Categories: Blogs

Neo4j: Modelling sub types

Mark Needham - Tue, 10/21/2014 - 01:08

A question which sometimes comes up when discussing graph data modelling is how you go about modelling sub/super types.

In my experience there are two reasons why we might want to do this:

  • To ensure that certain properties exist on bits of data
  • To write drill down queries based on those types

At the moment the former isn’t built into Neo4j and you’d only be able to achieve it by wiring up some code in a pre commit hook of a transaction event handler so we’ll focus on the latter.

The typical example used for showing how to design sub types is the animal kingdom and I managed to find a data set from Louiseville, Kentucky’s Animal Services which we can use.

In this case the sub types are used to represent the type of animal, breed group and breed. We then also have ‘real data’ in terms of actual dogs under the care of animal services.

We effectively end up with two graphs in one – a model and a meta model:

2014 10 20 22 32 31

The cypher query to create this graph looks like this:

LOAD CSV WITH HEADERS FROM "file:/Users/markneedham/projects/neo4j-subtypes/data/dogs.csv" AS line
MERGE (animalType:AnimalType {name: "Dog"})
MERGE (breedGroup:BreedGroup {name: line.BreedGroup})
MERGE (breed:Breed {name: line.PrimaryBreed})
MERGE (animal:Animal {id: line.TagIdentity, primaryColour: line.PrimaryColour, size: line.Size})
MERGE (animalType)<-[:PARENT]-(breedGroup)
MERGE (breedGroup)<-[:PARENT]-(breed)
MERGE (breed)<-[:PARENT]-(animal)

We could then write a simple query to find out how many dogs we have:

MATCH (animalType:AnimalType)<-[:PARENT*]-(animal)
RETURN animalType, COUNT(*) AS animals
==> +--------------------------------+
==> | animalType           | animals |
==> +--------------------------------+
==> | Node[89]{name:"Dog"} | 131     |
==> +--------------------------------+
==> 1 row

Or we could write a slightly more complex query to find the number of animals at each level of our type hierarchy:

MATCH path = (animalType:AnimalType)<-[:PARENT]-(breedGroup)<-[:PARENT*]-(animal)
RETURN [node IN nodes(path) |][..-1] AS breed, COUNT(*) AS animals
==> +-----------------------------------------------------+
==> | breed                                     | animals |
==> +-----------------------------------------------------+
==> | ["Dog","SETTER/RETRIEVE","LABRADOR RETR"] | 15      |
==> | ["Dog","SETTER/RETRIEVE","GOLDEN RETR"]   | 13      |
==> | ["Dog","POODLE","POODLE MIN"]             | 10      |
==> | ["Dog","TERRIER","MIN PINSCHER"]          | 9       |
==> | ["Dog","SHEPHERD","WELSH CORGI CAR"]      | 6       |
==> +-----------------------------------------------------+
==> 5 rows

We might then decide to add an exercise sub graph which indicates how much exercise each type of dog requires:

MATCH (breedGroup:BreedGroup)
MERGE (exercise:Exercise {type: "2 hours hard exercise"})
MERGE (exercise)<-[:REQUIRES_EXERCISE]-(breedGroup);
MATCH (breedGroup:BreedGroup)
MERGE (exercise:Exercise {type: "1 hour gentle exercise"})
MERGE (exercise)<-[:REQUIRES_EXERCISE]-(breedGroup);

We could then query that to find out which dogs need to come out for 2 hours of hard exercise:

MATCH (exercise:Exercise {type: "2 hours hard exercise"})<-[:REQUIRES_EXERCISE]-()<-[:PARENT*]-(dog)
WHERE NOT (dog)<-[:PARENT]-()
==> +-----------------------------------------------------------+
==> | dog                                                       |
==> +-----------------------------------------------------------+
==> | Node[541]{id:"664427",primaryColour:"BLACK",size:"SMALL"} |
==> | Node[542]{id:"543787",primaryColour:"BLACK",size:"SMALL"} |
==> | Node[543]{id:"584021",primaryColour:"BLACK",size:"SMALL"} |
==> | Node[544]{id:"584022",primaryColour:"BLACK",size:"SMALL"} |
==> | Node[545]{id:"664430",primaryColour:"BLACK",size:"SMALL"} |
==> | Node[546]{id:"535176",primaryColour:"BLACK",size:"SMALL"} |
==> | Node[567]{id:"613557",primaryColour:"WHITE",size:"SMALL"} |
==> | Node[568]{id:"531376",primaryColour:"WHITE",size:"SMALL"} |
==> | Node[569]{id:"613567",primaryColour:"WHITE",size:"SMALL"} |
==> | Node[570]{id:"531379",primaryColour:"WHITE",size:"SMALL"} |
==> +-----------------------------------------------------------+
==> 10 rows

In this query we ensured that we only returned dogs rather than breeds by checking that there was no incoming PARENT relationship. Alternatively we could have filtered on the Animal label…

MATCH (exercise:Exercise {type: "2 hours hard exercise"})<-[:REQUIRES_EXERCISE]-()<-[:PARENT*]-(dog:Animal)

or if we wanted to only take the dogs out for exercise perhaps we’d have Dog label on the appropriate nodes.

People are often curious why labels don’t have super/sub types between them but I tend to use labels for simple categorisation – anything more complicated and we may as well use the built in power of the graph model!

The code is on github should you wish to play with it.

Categories: Blogs

Breaking Gantt Webinar Follow-up Questions

BigVisible Solutions :: An Agile Company - Mon, 10/20/2014 - 22:29

If you missed our latest webinar, Breaking Gantt – Project Reporting in Agile Transition by Dave Prior check it out now. Following the presentation we received an overwhelming amount of questions, we were able to get to some of them before time ran out. The rest can be found below. Have more questions? Let us […]

The post Breaking Gantt Webinar Follow-up Questions appeared first on BigVisible Solutions.

Categories: Companies

Python: Converting a date string to timestamp

Mark Needham - Mon, 10/20/2014 - 17:53

I’ve been playing around with Python over the last few days while cleaning up a data set and one thing I wanted to do was translate date strings into a timestamp.

I started with a date in this format:

date_text = "13SEP2014"

So the first step is to translate that into a Python date – the strftime section of the documentation is useful for figuring out which format code is needed:

import datetime
date_text = "13SEP2014"
date = datetime.datetime.strptime(date_text, "%d%b%Y")
$ python
2014-09-13 00:00:00

The next step was to translate that to a UNIX timestamp. I thought there might be a method or property on the Date object that I could access but I couldn’t find one and so ended up using calendar to do the transformation:

import datetime
import calendar
date_text = "13SEP2014"
date = datetime.datetime.strptime(date_text, "%d%b%Y")
$ python
2014-09-13 00:00:00

It’s not too tricky so hopefully I shall remember next time.

Categories: Blogs

Are Prejudices Stopping your Agile Efforts?

Scrum Expert - Mon, 10/20/2014 - 17:40
Adopting new software development approaches like Agile and Scrum is always a challenge. There is a natural tendency for part of an organization to resist changing and some prejudices exist against Agile, mainly due to a lack of knowledge. This article discusses these misconceptions and provides some tips on how to overcome these prejudices to get Agile adoption on track in your organization. Author: Kevin Dunne, QASymphony, Adopting Agile may be the next big thing for your team, but adopting new practices always presents challenges for any organization. We all know ...
Categories: Communities

Waarom Agile?

Ben Linders - Mon, 10/20/2014 - 17:16
Agile werken kan je helpen om organisatiedoelen te bereiken. Agile tot een doel verheffen werkt meestal niet, het doel is om resultaten te bereiken, niet om agile te worden. Het is belangrijk om goed te weten waarom je de agility van je organisatie wilt vergroten en wat je met een agile werkwijze verwacht te bereiken. Continue reading →
Categories: Blogs

Agile Brazil, Florianópolis, Brazil, November 5–7 2014

Scrum Expert - Mon, 10/20/2014 - 08:44
Agile Brazil is a three-day conference that is the largest event about Agile and Scrum in Brazil. It features keynotes and practical presentations with local and international Agile experts. Talks are both in Portuguese and English. In the agenda of Agile Brazil you can find topics like “Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work”, “Pragmatic, Not Dogmatic TDD: Rethinking How We Test”, “Mental Models in High Performing Agile Teams”, “Extreme Pair Programming”, “Visual Regression Testing with PhantomCSS”, “UX Design for Startups”. Web site: Location for the 2014 ...
Categories: Communities

Brauchen wir noch Daily Standups?

Scrum 4 You - Mon, 10/20/2014 - 07:45

Durch Zufall bin ich vor Kurzem auf den Service gestoßen. Als ich mir anschaute, was dort geboten wird, habe ich sofort an die “Daily“-E-Mail bei gedacht. Wir schrieben dort am Ende des Tages an den Teamleiter eine kurze E-Mail mit den Dingen, die wir heute getan hatten. So wusste er, was der Stand der Dinge war. Leider wurde das oft vergessen, weil es keinen automatischen Reminder gab. Die “Dailys” wurden immer länger und das Reporting wurde zur Last. Die Idee selbst fand ich jedoch immer gut. In meinem Unternehmen nutzen wir Confluence, ein Wiki von Atlassian, in dem wir ein “Logbuch” haben. In dieses Logbuch schreiben wir unsere Aktivitäten des Tages hinein. Daher gefällt mir vielleicht auch die die Idee von iDoneThis so gut. Denn nun bekomme ich am Ende des Tages eine E-Mail und kann eintragen, was ich getan habe. Diese E-Mail wird einfach per Reply beantwortet. Am nächsten Morgen schickt mir iDoneThis eine E-Mail mit allen Aktivitäten des Teams.

So weit so gut – doch dann bin ich über die Kundengeschichten von iDoneThis gestolpert. Ganz besonders fasziniert hat mich die Geschichte von Bufferapp. Ich kenne Buffer als User und es gibt im Netz mittlerweile viele interessante Stories über diese kleine Firma. Die Story, die iDoneThis über Buffer erzählt, ist für einen Scrummie verblüffend: Sie sagen, dass Buffer die Daily Standups durch iDoneThis ersetzt hätte (den ganzen Text findet ihr hier):

“As a remote team, Buffer needed a better way to stay on the same page. Previously, everyone would get on a daily group Skype call in which each person would take three minutes to talk about what they did, how their co-workers could help, and their improvements. With the team growing larger, the standup process wasn’t scaling over Skype, as they began to have to deal with Skype malfunctions, different timezones, and ever-increasing meeting lengths. Holding traditional standups over video chat also meant that “if you jump in and talk about something that somebody just said, you’re basically interrupting their three minutes. So what we would actually do is not ask that many questions.” They tried email, but it became a hassle as email threads got longer and longer, and each new message bumped the thread in everyone’s inbox and created another alert. Buffer turned to iDoneThis. It’s a way to understand what teammates are working on, and every time I read people’s iDoneThis, I feel connected with the team. With iDoneThis, rather than having to spend an hour in a meeting, you only have to read your email. We send an email to your team every evening asking, “What’d you get done today?” Just reply. The next day, we send a single email digest to everyone on the team with the contents of what might otherwise take a lengthly and tiresome meeting. Leo remarks, “It allows us to track performance, which easily gets lost in a chat room or an in-person standup. If new people come on board, they can look through and see what has been worked on. And of course, it’s amazing to keep in sync with everyone, working as a remote team. iDoneThis is invaluable to us and has changed our productivity for the better.”

Unser Logbuch hat gegenüber dieser Lösung einen Nachteil: Ich muss nachschauen, was jeder getan hat. Hier bekomme ich automatisch einen Überblick. Kann diese Lösung das Daily Standup ersetzen? Ich bin mir nicht sicher – mit meinen Kolleginnen in Baden-Baden treffe ich mich jeden Morgen zum Daily Scrum per Google HangOut (Skype war einfach nicht verlässlich genug) und es ist großartig. Diese 15 Minuten sind für uns sehr wichtig. Was wir nicht haben, ist ein Board. Aber wir brauchen es auch nicht, denn es geht bei unseren Dailys nicht ums Reporting, sondern einzig um die Zusammenarbeit. Wir stellen bei unserer Arbeit bereits fest, dass das Nicht-Zusammensein schnell Fremdheit erzeugt. Mir immer wieder in Erinnerung zu rufen, wo die anderen gerade sind – selbst mit unserem Einsatzplaner LaLinea (ein selbst geschriebenes Einsatztool) verliert man schnell den Überblick. Vielleicht kann da ein Tool wie iDoneThis helfen. Probiert es für Euch doch mal aus. Lasst uns wissen, ob es hilft.

Related posts:

  1. The 10 things I use most:
  2. Impact of collocation on team effectiveness – Study
  3. Boris is in Belo Horizonte and Recife, Brazil

Categories: Blogs

Superman Syndrome

Agile Tools - Mon, 10/20/2014 - 06:49


There you are, in your tenth meeting of the day. You haven’t even had lunch, just one meeting after another. You’d skip the meetings, but you are required and half the meetings are yours anyway. You finish the day without having accomplished one single thing (except a bunch of meetings). Your todo list has only grown longer and the only time remaining is after hours (because nobody can schedule a meeting then). If this is you, then you might have superman syndrome.

It’s pretty common in software development. The nicest people get sucked into it (no, really, they’re too damn nice). You are competent, eager to please, and really can’t say no. It’s a great ego boost – you are needed! Well, I’ve got some bad news: you’ve got Superman Syndrome.

That’s right, you got it bad. Now sit down. This is where we get to play product owner. Product owner of your life. Write down that list of all thing things you have to do. Go ahead, put it in priority order. That’s right, it’s not easy. Product ownership is a bitch. Good, now cancel all your meetings. I know it hurts. Do it anyway. Send some polite excuse about being behind in your work (because it’s true) and you’ll catch up with them later (maybe never).

Now take that one thing at the top of the list (it is just one thing, right?) and get to work. Here’s the new rule, you don’t get to work on anything else until that thing is done. Take comfort in the fact that you are working on the most important thing that you could be working on. No one can fault you for that. You see what we are doing is limiting your work in progress (WIP). Limiting the amount of work you take on is like kryptonite to Superman Syndrome.

While we’re at it, let’s just turn outlook off. Yeah, completely off. You have a WIP limit here too: twice a day. Once before lunch and once before you go home. That’s it. That’s all.

While we are having so much fun setting WIP limits, we might as well put a WIP limit on your meetings. That’s right, nobody can reasonably expect you to do your job AND attend every single meeting: so don’t. Set a reasonable limit (no more than 2 hours of meetings/day). That way you are available if the issue is REALLY important, but otherwise, they’ll have to just get along without you. Again, polite apologies all around.

Try that on for a while and see how that works for you. Come back and chat with me when you think you are ready to change your WIP limits.

Now to take my own advice…wish me luck.

Yours truly, Superman
Filed under: Agile, Coaching Tagged: Coaching, meetings, superman, time management, WIP, work in progress
Categories: Blogs

LeanStartup : Customer Development Is Customer Coaching

Agile Thinks and Things - Oana Juncu - Sun, 10/19/2014 - 13:05
One of the most important activities as a Lean Startup entrepreneur is building the right interviews that will help building the "right product", as the Pretotyping Manifesto tells us.  My latest experience as  a Lean Startup mentor was with Business School class students.  With me in the mentoring team ( and in the photo) were Florian Champagne , Sébastien Orifici, who holds the innovation course, and Frank Debane , whom I thank to have invited me to join the team. The intense experience of helping about 10 projects structure the good questions for customers interviews,  revealed how similar  customer development and coaching are.  The highest value in Customer Development comes from asking good questions . The highest value of a coaching session does from asking "powerful questions". Do you see a pattern here? Entrepreneurs Are Asked To Be ... Customer Coaches Entrepreneurs learn from the Lean Startup approach that the first think they need to do is to challenge their vision. They are asked to stay humble and not impose their solution over customers that , hmmm, may not want that at all. They are asked to listen to market's voice and adapt their solution instead of trying to influence customers behavior.  The top 3 recommandations in true Customer development approach are :
  1. Don't rely of vanity metrics : number of likes , followers , visits on your product idea page is no sign of commitment 
  2. Be aware of false positives : don't count your family and friends in the measure of your success 
  3. Customers are experts of the problem  : if you want to build a successful solution, listen to real problem of customers instead of your ideas of the problem. 
So let's summarize what is the recommended entrepreneur's behaviour : 
  • Listen and observe, don't push your assumptions 
  • Customer is expert of the problem, they will find the most adapted solution 
Coaching experts will tell that  "listen and don't provide solutions" is the right attitude of a coach. Coaching is not about providing answers, coaching is about helping clients come out with answers that they are the only one to have , as the problem is theirs. So you see it ? Bright entrepreneur skilled in customer development are ... customer coaches.
Interview Questions are Powerful Questions The Lean "Gemba Walk" turned in "Get Out Of The Building" activity in Lean Startup ( as Lean Startup Machine initially defined it ) . Briefly it invites entrepreneurs to get into the "customer arena" and proceed to customer face-to-face interviews instead of running fancy marketing customer study analysis from company's ivory tower. To have effective feed-back , there is a key condition : prepare the customer interviews and ask the right questions right.  What are the patterns of good customer interviews questions ? Here is a quick hint :
  • Don't ask closed questions ( that will get a Yes/No answer). Closed questions are the main source of false positive and you won't get much of the binary choice.
  • Ask "Why", "How", "What" questions to avoid closed questions. Don't hesitate to repeat them . 
  • Invite to storytelling: ask customers to tell  their experience in the domain you're interviewing about 
  • Be interested about their problem ,  customers talk, you listen . 

For those people that are familiar with coaching the interviewing pattern should ring a bell. Because what is asked from entrepreneurs to build a solid delighted customer base is to have a customer and market ... coaching attitude .
Emerging Marketing Approach
Traditional Marketing may teach us that the key to success is to create a need. Today's world of frugality that has a tendency to run away from consuming behavior is probably not aligned anymore on this vision.Marketing of tomorrow that will bring make entrepreneurs successful might shift from "owning the market" to "coaching the market".And "create the need" will definitively shift to "make customer realise they have a need that they were not truly aware about". A completely different story.

Related Posts
Test Driven Business Featuring Your Lean Startup Products
Entrepreneurs , What Is Your Unfair Advantage 
Lean Startup For Services 

Categories: Blogs

Simplicity of Measure

Agile Tools - Sun, 10/19/2014 - 07:01


I got a fitbit bracelet the other day. It’s a pretty nifty gadget. It tracks the number of steps that I take in a day, as well as measuring movement while I’m asleep. I’ve been very impressed with the number of things that you can derive from a simple measure of the frequency of movement. You get number of steps, activity level, calories burned, sleep periods, and a few other metrics. All of that from one simple measure of how often my hand moves.  Admittedly, some of those measures are inferred based on some simple assumptions like how many calories that the average person burns in a fixed period of time. However there is nothing wrong with that, The measure doesn’t have to be 100% accurate in order for it to be useful to me. I can see the trends and understand if my calories burned is changing for the better or for the worse without having the exact number of calories that I burn in an hour. An approximation is certainly sufficient.

It’s really quite impressive that you can derive so much from a single metric. It made me wonder about the metrics that we keep on Agile teams. Whether it’s velocity or throughput, there are metrics that we use for a lot of different purposes. We use velocity to tell us how much work the team can take on per sprint. We derive duration using velocity. I like the notion of having a small set of metrics like velocity that we can use for a variety of measures.

Filed under: Agile, Tools Tagged: fitbit, measure, Metrics, Tools
Categories: Blogs

Neo4j: LOAD CSV – The sneaky null character

Mark Needham - Sat, 10/18/2014 - 12:49

I spent some time earlier in the week trying to import a CSV file extracted from Hadoop into Neo4j using Cypher’s LOAD CSV command and initially struggled due to some rogue characters.

The CSV file looked like this:

$ cat foo.csv

I wrote the following LOAD CSV query to extract some of the fields and compare others:

load csv with headers from "file:/Users/markneedham/Downloads/foo.csv" AS line
RETURN,, = "2"
==> +--------------------------------------+
==> | | | = "2" |
==> +--------------------------------------+
==> | <null>   | "2"     | false          |
==> +--------------------------------------+
==> 1 row

I had expect to see a “1” in the first column and a ‘true’ in the third column, neither of which happened.

I initially didn’t have a text editor with hexcode mode available so I tried checking the length of the entry in the ‘bar’ field:

load csv with headers from "file:/Users/markneedham/Downloads/foo.csv" AS line
RETURN,, = "2", length(
==> +---------------------------------------------------------+
==> | | | = "2" | length( |
==> +---------------------------------------------------------+
==> | <null>   | "2"     | false          | 2                |
==> +---------------------------------------------------------+
==> 1 row

The length of that value is 2 when we’d expect it to be 1 given it’s a single character.

I tried trimming the field to see if that made any difference…

load csv with headers from "file:/Users/markneedham/Downloads/foo.csv" AS line
RETURN, trim(, trim( = "2", length(
==> +---------------------------------------------------------------------+
==> | | trim( | trim( = "2" | length( |
==> +---------------------------------------------------------------------+
==> | <null>   | "2"            | true                 | 2                |
==> +---------------------------------------------------------------------+
==> 1 row

…and it did! I thought there was probably a trailing whitespace character after the “2” which trim had removed and that ‘foo’ column in the header row had the same issue.

I was able to see that this was the case by extracting the JSON dump of the query via the Neo4j browser:


It turns out there were null characters scattered around the file so I needed to pre process the file to get rid of them:

$ tr < foo.csv -d '\000' > bar.csv

Now if we process bar.csv it’s a much smoother process:

load csv with headers from "file:/Users/markneedham/Downloads/bar.csv" AS line
RETURN,, = "2", length(
==> +---------------------------------------------------------+
==> | | | = "2" | length( |
==> +---------------------------------------------------------+
==> | "1"      | "2"      | true           | 1                |
==> +---------------------------------------------------------+
==> 1 row

Note to self: don’t expect data to be clean, inspect it first!

Categories: Blogs

Make Resolving Impediments a Habit

Agile Tools - Sat, 10/18/2014 - 08:43


I’ve talked a lot about the rigors of finding and resolving impediments for a team. There is one thing that I have left out: the people part. I learned this lesson at a conference that I was co-hosting. I had been in charge of setting up the food for the event. Getting the caterer, arranging for meals, that sort of thing. As you might imagine, it’s a pretty tough job to satisfy the dietary requirements for a very large group of people. I learned of whole categories of food allergies and needs that I had never even imagined existed! There was a little bit of every imaginable combination. Everything from your standard gluten free diet all the way to lacto-ovo-pesca-leguma-veganitarians (OK, I made that last one up).

We did the best we could to satisfy the needs of most folks and pretty much called it good. About halfway through the conference, someone mentioned that there was no food that fit in their dietary needs. I expressed my sympathies and referred them to the grocery store around the corner. I really didn’t give it another thought. A few minutes later, I heard the same complaint made by the same person, but this time the reply was, “I’ll get you something, I’ll be right back” And that person ran off to the store themselves. Wow!

I was humbled. The difference between my reaction and theirs was the difference between someone who could empathize and take action to resolve the impediment, and someone who couldn’t. The lesson I learned that day was that in order to help people with their impediments, it takes empathy. You have to feel their need, and be receptive to doing anything to help them out. I think I had missed that before. That willingness to serve the needs of others is really important. All the strategies in the world for resolving impediments won’t help anyone if you don’t care.

Filed under: Agile, impediment Tagged: Impediments, leadership
Categories: Blogs

R: Linear models with the lm function, NA values and Collinearity

Mark Needham - Sat, 10/18/2014 - 08:35

In my continued playing around with R I’ve sometimes noticed ‘NA’ values in the linear regression models I created but hadn’t really thought about what that meant.

On the advice of Peter Huber I recently started working my way through Coursera’s Regression Models which has a whole slide explaining its meaning:

2014 10 17 06 21 07

So in this case ‘z’ doesn’t help us in predicting Fertility since it doesn’t give us any more information that we can’t already get from ‘Agriculture’ and ‘Education’.

Although in this case we know why ‘z’ doesn’t have a coefficient sometimes it may not be clear which other variable the NA one is highly correlated with.

Multicollinearity (also collinearity) is a statistical phenomenon in which two or more predictor variables in a multiple regression model are highly correlated, meaning that one can be linearly predicted from the others with a non-trivial degree of accuracy.

In that situation we can make use of the alias function to explain the collinearity as suggested in this StackOverflow post:

library(datasets); data(swiss); require(stats); require(graphics)
z <- swiss$Agriculture + swiss$Education
fit = lm(Fertility ~ . + z, data = swiss)
> alias(fit)
Model :
Fertility ~ Agriculture + Examination + Education + Catholic + 
    Infant.Mortality + z
Complete :
  (Intercept) Agriculture Examination Education Catholic Infant.Mortality
z 0           1           0           1         0        0

In this case we can see that ‘z’ is highly correlated with both Agriculture and Education which makes sense given its the sum of those two variables.

When we notice that there’s an NA coefficient in our model we can choose to exclude that variable and the model will still have the same coefficients as before:

> require(dplyr)
> summary(lm(Fertility ~ . + z, data = swiss))$coefficients
                   Estimate  Std. Error   t value     Pr(>|t|)
(Intercept)      66.9151817 10.70603759  6.250229 1.906051e-07
Agriculture      -0.1721140  0.07030392 -2.448142 1.872715e-02
Examination      -0.2580082  0.25387820 -1.016268 3.154617e-01
Education        -0.8709401  0.18302860 -4.758492 2.430605e-05
Catholic          0.1041153  0.03525785  2.952969 5.190079e-03
Infant.Mortality  1.0770481  0.38171965  2.821568 7.335715e-03
> summary(lm(Fertility ~ ., data = swiss))$coefficients
                   Estimate  Std. Error   t value     Pr(>|t|)
(Intercept)      66.9151817 10.70603759  6.250229 1.906051e-07
Agriculture      -0.1721140  0.07030392 -2.448142 1.872715e-02
Examination      -0.2580082  0.25387820 -1.016268 3.154617e-01
Education        -0.8709401  0.18302860 -4.758492 2.430605e-05
Catholic          0.1041153  0.03525785  2.952969 5.190079e-03
Infant.Mortality  1.0770481  0.38171965  2.821568 7.335715e-03

If we call alias now we won’t see any output:

> alias(lm(Fertility ~ ., data = swiss))
Model :
Fertility ~ Agriculture + Examination + Education + Catholic + 
Categories: Blogs

Knowledge Sharing

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