Skip to content

Feed aggregator

Agile Coach Camp, Melbourne, Australia, March 21 2015

Scrum Expert - Fri, 03/13/2015 - 15:17
Agile Coach Camp Melbourne is a one-day non-profit un-conference for Agile and Scrum project management coaches in Australia and New Zealand. It allows Agile coaches to get together in a collective learning experience. The agenda of Agile Coach Camp Melbourne follows the Open Space Technology format. Open space is a simple methodology for self-organizing conference tracks. It relies on participation by people who have a passion for the topics to be discussed. There is no preplanned list of topics, only time slots and a space in the main meeting room where ...
Categories: Communities

Agile needs coaching

Ben Linders - Fri, 03/13/2015 - 12:55
I see organizations who hire a bunch of coaches when they are transitioning to agile. Management assumes that since they've hired the best coaches that they can pay, the transition will go smoothly and quickly. In practice it often doesn't, and organizations are not getting the benefits that they expected from agile. Blaming agile and saying that it doesn't work doesn't solve the problem. When your agile transformation isn't going that smoothly, chances are big that there are problems with the approach that is used for doing coaching in your organization. Continue reading →
Categories: Blogs

Becoming a Radiating Team

Illustrated Agile - Len Lagestee - Thu, 03/12/2015 - 23:30

An agile team was recently asked by a manager to prepare and distribute a weekly status report. What is your reaction when you read this? For some, this may seem quite normal. For others, you may need more context behind the request before reacting.

If your reaction is anything like mine, you’re probably thinking something seems amiss. While I’m not saying status reports should never be produced, when an agile team is being asked for one we should probably ask why.

From my experience, the primary reason for a request for status is because the team is not radiating enough information back into the organization. The natural energy and cadence of a well-functioning agile team rarely requires a status report. If the team is being asked to produce a status report either there are lingering dysfunctions in the organization beyond the control of the team OR the objective of the team should be to begin to radiate enough information until the status report is no longer necessary.

Becoming a radiating team should require very little additional effort and there is a wide range of existing information an Agile team produces to satisfy the requestors need for status. In short, we have the antidote to status reports. Here’s how:

Radiate intention through a product backlog. The backlog declares unequivocally what the team deems important to build and the sequence in which they will build it. The backlog could also contain experiments the product owner would like to try to validate a hypothesis. Provide access to a read-only version of this in a shared location so all interested parties can review and discuss. The product owner can field any open questions or requests for change.

Radiate progress through a real-time task wall. The task wall indicates movement. With a prioritized backlog, we also know this movement is always working towards completing valuable work. If the task wall is stale (i.e. tasks remain in progress for days) people should get nervous. Put the task wall in a public place or if your task wall is virtual, allow read-only access to this as well. The details won’t matter to most people outside of the team but seeing movement and energy does.

Radiate commitment (or forecast) through a burn-down chart. Or a burn-up chart. This chart will radiate the teams ability to deliver a product increment and when the deployment will occur. For many leaders or stakeholders, this is all they need to know. Are we going to deliver when we said we would deliver?

Radiate blockers listed in an impediment list. Impediments solved within the team could stay within the team but organizational impediments and dysfunctions can be radiated to all who will listen. Removing big impediments is the primary responsibility of managers in an agile organization.

Radiate speed by displaying velocity. If a task wall represents movement, velocity means we are moving in the right direction and getting things done. I’m not advocating the publishing of velocity outside of team boundaries but I believe a confident, radiating agile team should be transparent enough to say we are getting faster or slower.

In summary, when asked to provide a status report, point the requestor to the product backlog (what we are working on for the foreseeable future), the task wall (real-time movement towards bringing the backlog to life), a burn-down chart (over or under-commitment towards releasing the product based on empirical data ), a list of impediments the team can’t resolve (informing leadership of organizational blockers keeping them from effectively delivering) and some indication of team agility or speed (is the team delivering value with speed and craftsmanship). Status requestors can then choose what satisfies their need for status and someone on the team can guild them to it.

If your team is not radiating enough information around progress and team dynamics, there’s a good chance a request for status will be in your future. Agree? Disagree? Feel free to share your thoughts in the comments below.

By the way, to help with radiating your team information, here is an example team health dashboard I previously published. You can receive version 2 of this dashboard (seen below with more features and metrics than the first version) by becoming an Illustrated Agile subscriber. Existing subscribers can find a link and password in the latest email from Illustrated Agile.

Agile Team He

Becoming a Catalyst - Scrum Master Edition

The post Becoming a Radiating Team appeared first on Illustrated Agile.

Categories: Blogs

Serially Iterating An Array, Asynchronously

Derick Bailey - new ThoughtStream - Thu, 03/12/2015 - 20:43

I recently found myself looking at an array of functions in JavaScript. I needed to iterate through this list, process each function in an asynchronous manner (providing a “done” callback method), and ensure that I did not move on to the next item in the list until the current one was completed. 

The answer I found was in recursion and shifting through the array (grabbing the first item out of the array on each pass).

It’s a little ugly, granted, but it works.

Breaking It Down

The first thing I’m doing is hiding the recursion inside of the parent function. This keeps the public API for the method clean.

At the bottom of the parent function, I’m kicking off the nested recursive function by making a call to it and passing in the original list of steps that need to be run.

The recursive function does a number of things, including an initial check for the recursion’s exit strategy. If there are no items left in the array, then exit the recursion by returning and calling the original “done” method that was passed in to the parent function.

If there are steps to process, grab the first one in the list. Then set up a “next” function, using a closure around the updated “steps” list and the other parameters that I need. This “next” function is responsible for the recursive method call, and it does this using a setImmediate call to ensure we avoid any call stack limitations. Note: If you’re using this in a browser, you’ll probably want setTimeout instead of setImmediate.

Once the “next” method is setup, the actual “step” is processed by calling it as a function. I pass in the “data” argument that I need, and provide a callback for it. The callback checks for an error, and forwards it if it finds one. If no errors happened, it calls the “next” function which invokes the recursive call to process the next item in the list.

The Important Part

The critical point in this code, which allowed me to ensure that I am only processing one step at a time, is the callback function that I passed in to the “step” function.


With this callback function, I’m allowing the step to run asynchronously. It doesn’t matter how long the step takes to complete its work. When it is done, the step calls the callback that I provided. Within this callback, the “next()” function call kicks off the processing of the next item in the list.

Could Be Improved

This code works. In fact, it works well. I’ve got it running as a very important part of my Migroose framework for MongoDB / MongooseJS Data Migrations. 

But I know this code could probably be improved… in several ways.

First off, the use of setImmediate means it is possible to enter an infinite loop and never exit. I avoided a call stack limitation problem with this, but introduced another potentially disastrous problem. 

Second, this code isn’t easy to read. I could improve this a little bit by using a more explicit queue construct on top of my array, but I know there are other ways in which I could improve readability and understandability. 

Then there’s the problem of array.shift() to get the next item. This is a destructive call, changing the contents of the array. If you’re using an array that needs to be maintained the way it is, you don’t want to use this method. In my case, the array is temporal – I built it just for this iteration / step execution call. So in my case, it’s ok for me to destroy this array as I’m processing it. I’m never going to use the array again. In any other circumstance, though, I would suggest keeping an index of where you’re at, and using the index to process the next item.

Lastly, there are probably some performance considerations and memory considerations for the closures and use of setImmediate, among other things. As yet, I have not run into performance or memory problems with this. However, the introduction of a closure always includes the possibility of a memory leak – and that possibility is multiplied by the number of iterations (length of my array, in this case). 

How Would You Do It?

I’m curious – what improvements would you make in this code?

What alternative methods would you have used, to process these tasks sequentially and asynchronously?

I’m sure there are a dozen libraries out there, that would take care of this for me. Sometimes it’s nice to not bother with a third party library, but I’d be interested in seeing how you would handle this.

So drop some comments in the box below!

Categories: Blogs

Agile Trends. Sao Paolo, Brazil, April 24-25 2015

Scrum Expert - Thu, 03/12/2015 - 18:47
Agile Trends is a two-day conference focused on Agile and Scrum that takes place in Sao Paolo in Brazil. All the talks are in Portuguese. In the agenda of Agile Trends you can find topics like “Lean Security”, “Customer & Product Discovery in Mobile”, “Scrum of Scrums: Scaling Agile Concepts in Distributed Contexts”, “Agile Tester 3.0″, “Global Agile UX”, “Evolutionary Software Architecture”,” Complexity is Dead: at Least for the End User”. Web site: Location for the Agile Trends conference: Hotel Maksoud Plaza, Alameda Campinas 150, 01404-900 – Sao Paulo/SP, Brazil
Categories: Communities

Agile and SAFe in Gov: Progress!

Agile Product Owner - Thu, 03/12/2015 - 17:42

Jason Bloomberg, a leading industry analyst who writes for Wired and Forbes, and who has interviewed us in the past, (see The Battle of the Agile Curmudgeons? Forbes on SAFe) has been covering  a subject to which we’re all paying very close attention: Agile in Government.

He recently wrote about advancements made with Agile approaches in one of the most problem-plagued agencies , the VA Administration. But this is as part of a much larger story, which is how scaled Agile is fast becoming a common approach across the entire US federal government. We are now seeing SAFe used in multiple agencies (Commerce, Justice, DHS, NGA, Navy, NASA, and a few more that we are aware of; not sure if it is in play at the VA). At least one or two case studies are in progress for eventual publication here.

This article is a good read for anyone involved with the Fed space, especially when it comes to understanding the political and bureaucratic wranglings that play into the government’s big technology decisions.

You can read his post here, and if you’re particularly interested in the VA’s Agile rollout, you can read more of the backstory here.

Stay SAFe!



Categories: Blogs

3 Steps To Design Systems For Tomorrow : From Resilient To Antifragile

Agile Thinks and Things - Oana Juncu - Thu, 03/12/2015 - 14:53
Since I have embraced Agility as a state of mind and as a passionate profession , I was aiming to support organisations to gain resilience : In business development and economics today , robustness is no longer the point. Robustness means freeze due to incapability to adapt to changing reality.  0 energy . Business Death .  Then Agile , as support for the innovative entreprise profile brought the resiliency feature in.  Sustainability helps installing long term performance. And lately - even if it's not that new, it took time to the concept to grow in my blond mind - I started to focus on the Antifragile systems , that create value from variation . And figure out a pattern close to Dave Snowden's Cynefin model . Let's go through the 3 steps of creating a surprising new-new system
Step 1 : Resilience : the elastic systems 
Life is resilient . Life is build on a fractal model that allows the whole to survive, while the parts are organised in a pod-like pattern , free and self-sustainable. Target Agile organisations are like living organisms :

  • Have a strong commun purpose : keeping the entreprise alive . This may mean many thinks and are specific to each organisation, and it has a bottom line : delight customer that will give the living organism of the entreprise the air to breathe. 
  • Are fractal : teams are working in a self-organising eco-systems with high degree of independence, that very much alike to ensure sustainability.
  • Make distributed decisions : every "fractal element" ( let's call them "teams" ) can decide of everything that is impacting their work and/or the higher purpose of the enterprise . Imagine your immunity system that has to ask permission to the cortex to "take action" at any virus attack. You might be dead in less that 30 seconds. 
  • Work in networks : every "fractal element" is connected to others in all ways that are meaningful to create a sustainable , whole. 

When a resilient system receives a perturbation input ,  it reacts in an elastic way - takes the energy then comes back to the initial form.

Some fantastic ideas about fractal systems : Ron Englash - The fractals at the heart of African Design
Step 2 : Antifragile : the growing system From Don Reinersten's keynote at
Scrum Gathering Berlin 2014I'm afraid I don't have many Antifragile examples at hand, the best reference I can give are those mentioned by Don Reinersten from finance contracts that are based on antifragility : they benefit from market volatility . Antifragile organizations  improve when the level of unknown goes high , a dreamed pattern for adapting organisations that will:

  • Create value from variability : more variability is injected in the system , more valuable it is . Like the intelligence of the crowds: more people with different opinions, interests, skills you bring together to contribute to a given topic, more surprising and creative the result.
  • Love errors : every error is an opportunity for the organisation ( system) to learn and create new pattern of behavior to reinforce the value of the system . More you kick the system , better it becomes. 
  • Grow by unpredictability : systems  have more upsides than downsides from random events , as Nassim Taleb puts it .  Each organisation that has the capacity to learn from randomness and errors has a high potential of anti fragility. 

Step 3 : Innovation benefits from chaos 
Antifragile learns form errors and create value from random events . Isn't it a dreamed pattern for innovative organisations that have high learning capabilities , the dreamed model for the enterprise of tomorrow?
So actually to design the organisation at the edge of Innovation , that will successfully interact with other systems, mainly the customer ecosystem , it will need to become the resilient anti fragile organisation that :

  • works in independent self-organised units who are responsible end self-empower 
  • works in network to be sensitive  at the edge, where random signals and events arrive
  • are empowered by errors because the opportunity to learn creates higher value than the potential loss induced by the error.
  • embrace variability by giving each member of the organisation the occasion to contribute 

Going through these steps , a new pattern popped -up . What about joining Cynefin and the Robust-Resilient-Antifragile concepts together.  Something like this :

The Antifragility Cynefin
Other ReferencesAntifragilty - A concept that we dramatically needed ( in French )  

Categories: Blogs

Agile Is About Risk Mitigation

Leading Agile - Mike Cottmeyer - Thu, 03/12/2015 - 14:25

I believe Agile is about Risk Mitigation. I believe Agile teams always aim to deliver value by continuously reducing risk.

Process frameworks like Waterfall introduce and maintain a high level of risk over the lifecycle of a project. Work is typically focused on completing requirements and design first, before any development and testing can happen. Value is not attained for many months. During that time, it’s often not clear whether we’re making clear and measurable progress. Nor is it certain that we are delivering the right value.

Agile principles on the other hand, work to deliver value by reducing risk. That’s accomplished through continuous delivery as requirements are discovered. Agile exposes and provides the opportunity to recognize and mitigate risk early. Risk mitigation is achieved through: cross-functional teams, sustainable and predictable delivery pace, continuous feedback, and good engineering practices. Transparency at all levels of an enterprise is also key. Agile tries to answer questions to determine risk in the following areas, which I will discuss in more detail in a future post:

  • Business : Do we know the scope? Is there a market? Can we deliver it for an appropriate cost?
  • Technical: Is it a new technology? Does our Architecture support it? Does our team have the skills
  • Feedback (verification & validation): Can we get effective feedback to highlight when we should address the risks?
  • Organizational: Do we have what we need (people, equipment, other) to deliver the product?
  • Dependency: What outside events need to take place to deliver the project?  Do I have a plan to manage dependencies?

Yes, Agile is about delivering value. Yes, Agile is about all sorts of cool engineering techniques. I believe that value and technical prowess only serve the greater purpose of Agile: To continuously mitigate and reduce risk.

Why else would you adopt Agile?

The post Agile Is About Risk Mitigation appeared first on LeadingAgile.

Categories: Blogs

The speed of a caravan in the desert

Sonar - Thu, 03/12/2015 - 12:22

“What is the speed of a caravan in the desert?” Language Team Technical Lead Evgeny Mandrikov posed that question recently to illustrate a point about developer tools. The answer to the caravan question is that it moves at the speed of the slowest camel. He was using the metaphor to illustrate a point about developer tools: a developer can only work at the speed of her slowest tool.

This is one reason developers want – and smart managers buy – machines with fast processors. We like them not just because we’re gear-head (chip-head?) geeks, but because they get us closer to the ability to work at the speed of thought. But what about the other tools? What about the quality tools?

For the same reason developers want fast processors, fast IDE’s and fast compilers, we also want fast quality tools. Forget the semicolon at the end of a line of Java code and most IDE’s will immediately light it up in red. That fast quality feedback lets you code quickly and efficiently, without agonizing over trivial details.

Similarly, fast feedback on code quality lets you mark features “done and dusted”, and move on. That’s why SonarSource offers three different options for pre-commit analysis. That’s also why we advocate (and practice!) Continuous Inspection. Looking at code quality once a month or once a week or just before a release is waaay too late.

Because developers want to work at the speed of thought, not the speed of corporate bureaucracy. And smart managers want that too.

Categories: Open Source

Selbstorganisierte Teams müssen lernen dürfen

Scrum 4 You - Thu, 03/12/2015 - 08:35

Machmal frage ich mich, ob wir vor lauter Tools und Techniken – von der Timer-Uhr für Meetings bis zu Tipps für die richtigen Umgebungsbedingungen – die Quintessenz unseres Jobs als ScrumMaster übersehen. Natürlich, das höchste Ziel des ScrumMasters ist es letztendlich, die Produktivität zu erhöhen. Es geht dabei aber nicht darum, die Teams mit Tools zu überschütten, sondern sie auf dem Weg zur Selbstorganisation zu begleiten. Es geht darum, die Kraft des Teams freizusetzen.

Scrum als Methode hat vor allem ein Ziel: Die Entscheidungen dorthin zu bringen, wo das Wissen vorhanden ist – also beim Team. Darüber hinaus ist eines der Prinzipien: learn fast and fail fast. Zu Deutsch: Mach das, was du für richtig hältst, finde eine Möglichkeit, schnell eine Ergebnis zu erhalten und dann lerne aus deinen Fehlern. So sehr wir diese Werte als ScrumMaster vertreten mögen, manchmal vergisst man dabei, was es konkret heißt.

Auch ScrumMaster müssen lernen

In einer meiner letzten Retrospektiven als ScrumMaster habe ich um Feedback gebeten. Es ging mir darum, mich selbst und meine Arbeit als ScrumMaster zu verbessern. Am prägnantesten sind mir zwei Kommentare in Erinnerung geblieben: „Entspann dich, wir müssen mehrere Stories parallel fertigstellen, die Abhängigkeiten sind einfach zu groß“ und „Lächle mal wieder“. Der Hintergrund dieser Geschichte war, dass ich mein Team immer wieder motivierte, einzelne Stories abzuschließen, statt viele Stories auf einmal zu eröffnen und parallel zu bearbeiten. Ich wusste ja, dass die Leistung bei parallelen Tätigkeiten abnimmt (siehe Synchronitis).

Und plötzlich hat es Klick gemacht. Seien wir doch mal ehrlich: Ich arbeite in einem multidisziplinären Team, ich bin nur oberflächlich in das tägliche Doing involviert und last but not least bin ich nicht die Stelle, an der die meisten Informationen zentriert sind. Sprich, ich weiß einfach nicht am besten, was das Team braucht. Das Team selbst weiß es und wenn es auch einmal falsch liegen sollte, dann muss ich darauf vertrauen, dass es lernt und es beim nächsten Mal besser macht. Das Elementare ist dabei aber nicht, jeden Fehler zu vermeiden, sondern die Möglichkeit zum Lernen zu etablieren. Schafft er das nicht, wird ein ScrumMaster immer wieder das Gefühl haben, am Ende die Kohlen aus dem Feuer holen zu müssen. Das mag dem Ego schmeicheln, funktioniert aber sicher nicht als Basis für die Selbstorganisation eines Teams.

Zeit zum Nichthandeln

Was ich von da an machte, war von außen betrachtet genau so simpel, wie es innerlich schwierig war. Ich hielt mich raus. Ich ging zum Management und sagte: „Ich kann nicht sagen, wie wir den nächsten Sprint abschließen werden. Kann sein, dass unsere Leute eine schlechtere Performance ablegen und daraus lernen. Langfristig betrachtet sollen sie sich selbst organisieren und dazu müssen sie aus ihren Fehlern lernen. Kann aber auch sein, dass sie eine wahnsinnig gute Performance hinlegen und ich mich geirrt habe. Dann habe ich sie in den letzten Monaten zu sehr darauf getrimmt, fokussiert an einer Sache zu arbeiten. Fakt ist, wir wollen selbstorganisierte Teams, also müssen wir ihnen auch den Platz fürs Lernen einräumen.“

Ja, aus dem Feedback hatte ich definitiv gelernt, dem Team Raum zu lassen, um sich zu entfalten. Ich muss ihnen den Freiraum verschaffen, möglicherweise Fehler zu machen und eventuell muss ich in meiner Rolle als ScrumMaster auch den Kopf dafür hinhalten. Denn am Ende des Tages ist und bleibt es meine Aufgabe, die Produktivität zu erhöhen und ich werde danach vom Management beurteilt. Aber ich habe vor allem auch das Management informiert und über meine Beweggründe auf dem Laufenden gehalten, denn das Management muss wissen, woran es ist. Darüber hinaus habe ich dem Team zeitweise meine Hilfe angeboten und mit einzelnen Teammitgliedern über den Stand der Dinge geredet. Was gebraucht wurde, habe ich organisiert. In anderen Punkten hat mir das Team gesagt, dass es sein Bestes tun werde, um das Commitment zu halten. Mehr kann ich mir nicht wünschen.

Der Effekt

In den letzten Tagen vor Sprintende bemerkte ich, dass eine große Anzahl an Stories noch offen war, dass aber auch kaum mehr Tasks bei diesen Stories vorhanden waren. Die Ruhe, die mich und das Team umgab, war Neu. Die Teammitglieder hetzten nicht, sondern arbeiteten konzentriert und Sie committeten eine Vielzahl von Stories (aus meiner Sicht zu viele). Der Druck war hoch, aber alle blieben ruhig. Zum ersten Mal hatte ich das Gefühl, dass es ihr Sprint war, weil sie für ihre Fehler und Erfolge gerade stehen durften und es nicht für jemand anderen taten.

In diesem Sinne: Lassen Sie als ScrumMaster Ihrem Team die Luft zum Atmen. Es fällt schwer, die Dinge aus der Hand zu geben, aber echte Selbstorganisation braucht Raum für Fehler, um sich entfalten zu können. Und was Sie nicht vergessen sollten: Halten Sie das Management am Laufenden – schließlich ist Transparenz einer der Grundwerte von Scrum.

Categories: Blogs

3 Reasons IT Ops Uses Lean Flow (Kanban for DevOps part 2 of 3)

In this three-part series on Kanban for DevOps, Dominica DeGrandis, Director of Training and Coaching at LeanKit, explains three key reasons why IT Ops teams and those implementing a DevOps value chain use a lean flow approach to product development. If you’re just jumping in, here’s a link to part one; otherwise, read on for […]

The post 3 Reasons IT Ops Uses Lean Flow (Kanban for DevOps part 2 of 3) appeared first on Blog | LeanKit.

Categories: Companies

Python/Neo4j: Finding interesting computer sciency people to follow on Twitter

Mark Needham - Wed, 03/11/2015 - 23:13

At the beginning of this year I moved from Neo4j’s field team to dev team and since the code we write there is much lower level than I’m used to I thought I should find some people to follow on twitter whom I can learn from.

My technique for finding some of those people was to pick a person from the Neo4j kernel team who’s very good at systems programming and uses twitter which led me to Mr Chris Vest.

I thought that the people Chris interacts with on twitter are likely to be interested in this type of programming so I manually traversed out to those people and had a look who they interacted with and put them all into a list.

This approach has worked well and I’ve picked up lots of reading material from following these people. It does feel like something that could be automated though and we’ll using Python and Neo4j as our tool kit.

We need to find a library to connect to the Twitter API. There are a few to choose from but tweepy seems simple enough so I started using that.

The first thing we need to so is fill in our Twitter API auth details. Since the application is just for me I’m not going to bother with setting up OAuth – instead I’ll just create an application on and grab the appropriate tokens:

2015 03 11 01 18 47

Once we’ve done that we can navigate to that app and get a consumer key, consumer secret, access token and access token secret. They all reside on the ‘Keys and Access Tokens’ tab:

2015 03 11 01 20 17 2015 03 11 01 20 30

Now that we’ve got ourself all auth’d up let’s write some code that starts from Chris and goes out and finds his latest tweets and the people he’s interacted with in them. We’ll write the appropriate information out to a CSV file so that we can import it into Neo4j later on:

import tweepy
import csv
from collections import Counter, deque
auth = tweepy.OAuthHandler(consumer_key, consumer_secret)
auth.set_access_token(access_token, access_token_secret)
api = tweepy.API(auth, wait_on_rate_limit = True, wait_on_rate_limit_notify = True)
counter = Counter()
users_to_process = deque()
def extract_tweet(tweet):
    user_mentions = ",".join([user["screen_name"].encode("utf-8")
                             for user in tweet.entities["user_mentions"]])
    urls = ",".join([url["expanded_url"]
                     for url in tweet.entities["urls"]])
    return [tweet.user.screen_name.encode("utf-8"),
starting_user = "chvest"
with open("tweets.csv", "a") as tweets:
    writer = csv.writer(tweets, delimiter=",", escapechar="\\", doublequote = False)
    for tweet in tweepy.Cursor(api.user_timeline, id=starting_user).items(50):
        for user in tweet.entities["user_mentions"]:
            if not len(users_to_process) > USERS_TO_PROCESS:
                counter[user["screen_name"]] += 1

As well as printing out Chris’ tweets I’m also capturing other users who he’s had interacted and putting them in a queue that we’ll drain later on. We’re limiting the number of other users that we’ll process to 50 for now but it’s easy to change.

If we print out the first few lines of ‘tweets.csv’ this is what we’d see:

$ head -n 5 tweets.csv
chvest,575403105174552576,@AlTobey I often use for small one-off graph diagrams.,AlTobey,
chvest,575337346687766528,RT @theburningmonk: this is why you need composition over inheritance... :s #CompositionOverInheritance,theburningmonk,
chvest,575269402083459072,@chvest except…? “Each library implementation should therefore be identical with respect to the public API”,chvest,

We’re capturing the user, tweetId, the tweet itself, any users mentioned in the tweet and any URLs shared in the tweet.

Next we want to get some of the tweets of the people Chris has interacted with

# Grab the code from here too -
import tweepy
import csv
from collections import Counter, deque
auth = tweepy.OAuthHandler(consumer_key, consumer_secret)
auth.set_access_token(access_token, access_token_secret)
api = tweepy.API(auth, wait_on_rate_limit = True, wait_on_rate_limit_notify = True)
counter = Counter()
users_to_process = deque()
def extract_tweet(tweet):
    user_mentions = ",".join([user["screen_name"].encode("utf-8")
                             for user in tweet.entities["user_mentions"]])
    urls = ",".join([url["expanded_url"]
                     for url in tweet.entities["urls"]])
    return [tweet.user.screen_name.encode("utf-8"),
starting_user = "chvest"
with open("tweets.csv", "a") as tweets:
    writer = csv.writer(tweets, delimiter=",", escapechar="\\", doublequote = False)
    for tweet in tweepy.Cursor(api.user_timeline, id=starting_user).items(50):
        for user in tweet.entities["user_mentions"]:
            if not len(users_to_process) > USERS_TO_PROCESS:
                counter[user["screen_name"]] += 1
    users_processed = set([starting_user])
    while True:
        if len(users_processed) >= USERS_TO_PROCESS:
            if len(users_to_process) > 0:
                next_user = users_to_process.popleft()
                print next_user
                if next_user in users_processed:
                    "-- user already processed"
                    "-- processing user"
                    for tweet in tweepy.Cursor(api.user_timeline, id=next_user).items(10):
                        for user_mentioned in tweet.entities["user_mentions"]:
                            if not len(users_processed) > 50:
                                counter[user_mentioned["screen_name"]] += 1

Finally let’s take a quick look at the users who show up most frequently:

>>> for user_name, count in counter.most_common(20):
        print user_name, count
neo4j 13
devnexus 12
AlTobey 11
bitprophet 11
hazelcast 10
chvest 9
shipilev 9
AntoineGrondin 8
gvsmirnov 8
GatlingTool 8
lagergren 7
tomsontom 6
dorkitude 5
noctarius2k 5
DanHeidinga 5
chris_mahan 5
coda 4
mccv 4
gAmUssA 4
jmhodges 4

A few of the people on that list are in my list which is a good start. We can explore the data set better once it’s in Neo4j though so let’s write some Cypher import statements to create our own mini Twitter graph:

// add people
LOAD CSV WITH HEADERS FROM "file:///Users/markneedham/projects/neo4j-twitter/tweets.csv" AS row
MERGE (p:Person {userName: row.userName});
LOAD CSV WITH HEADERS FROM "file:///Users/markneedham/projects/neo4j-twitter/tweets.csv" AS row
WITH SPLIT(row.usersMentioned, ",") AS users
UNWIND users AS user
MERGE (p:Person {userName: user});
// add tweets
LOAD CSV WITH HEADERS FROM "file:///Users/markneedham/projects/neo4j-twitter/tweets.csv" AS row
MERGE (t:Tweet {id: row.tweetId})
ON CREATE SET t.contents = row.contents;
// add urls
LOAD CSV WITH HEADERS FROM "file:///Users/markneedham/projects/neo4j-twitter/tweets.csv" AS row
WITH SPLIT(row.urls, ",") AS urls
UNWIND urls AS url
MERGE (:URL {value: url});
// add links
LOAD CSV WITH HEADERS FROM "file:///Users/markneedham/projects/neo4j-twitter/tweets.csv" AS row
MATCH (p:Person {userName: row.userName})
MATCH (t:Tweet {id: row.tweetId})
MERGE (p)-[:TWEETED]->(t);
LOAD CSV WITH HEADERS FROM "file:///Users/markneedham/projects/neo4j-twitter/tweets.csv" AS row
WITH SPLIT(row.usersMentioned, ",") AS users, row
UNWIND users AS user
MATCH (p:Person {userName: user})
MATCH (t:Tweet {id: row.tweetId})
LOAD CSV WITH HEADERS FROM "file:///Users/markneedham/projects/neo4j-twitter/tweets.csv" AS row
WITH SPLIT(row.urls, ",") AS urls, row
UNWIND urls AS url
MATCH (u:URL {value: url})
MATCH (t:Tweet {id: row.tweetId})

We can put all those commands in a file and execute them using neo4j-shell:

$ ./neo4j-community-2.2.0-RC01/bin/neo4j-shell --file import.cql

Now let’s write some queries against the graph:

// Find the tweets where Chris mentioned himself
MATCH path = (n:Person {userName: "chvest"})-[:TWEETED]->()<-[:MENTIONED_IN]-(n)

Graph  5

// Find the most popular links shared in the network
RETURN u.value, COUNT(*) AS times
| u.value                                                                                 | times |
| ""                                                              | 4     |
| ""                                                        | 4     |
| ""                                                            | 3     |
| ""                                                                | 3     |
| ""                                                   | 3     |
| ""                      | 3     |
| ""                  | 2     |
| "" | 2     |
| ""                                                                | 2     |
| ""                                                                | 2     |
10 rows

The first link is for a programming language meetup in Copenhagen, the second for a Java conference in Hanovier and the third an announcement about the latest version of Java Mission Control. So far so good!

A next step in this area would be to run the links through Prismatic’s interest graph so we can model topics in our graph as well. For now let’s have a look at the interactions between Chris and others in the graph:

// Find the people who Chris interacts with most often
MATCH path = (n:Person {userName: "chvest"})-[:TWEETED]->()<-[:MENTIONED_IN]-(other)
RETURN other.userName, COUNT(*) AS times
| other.userName | times |
| "gvsmirnov"    | 7     |
| "shipilev"     | 5     |
| "nitsanw"      | 4     |
| "DanHeidinga"  | 3     |
| "AlTobey"      | 3     |
5 rows

Let’s generalise that to find interactions between any pair of people:

// Find the people who interact most often
MATCH (n:Person)-[:TWEETED]->()<-[:MENTIONED_IN]-(other)
WHERE n <> other
RETURN n.userName, other.userName, COUNT(*) AS times
| n.userName    | other.userName   | times |
| "fbogsany"    | "AntoineGrondin" | 8     |
| "chvest"      | "gvsmirnov"      | 7     |
| "chris_mahan" | "bitprophet"     | 6     |
| "maxdemarzi"  | "neo4j"          | 6     |
| "chvest"      | "shipilev"       | 5     |
5 rows

Let’s combine a couple of these together to come up with a score for each person:

MATCH (n:Person)
// number of mentions
WITH n, COUNT(mention) AS mentions
// number of links shared by someone else
WITH n, mentions, COUNT(link) AS links
RETURN n.userName, mentions + links AS score, mentions, links
| n.userName    | score | mentions | links |
| "chvest"      | 17    | 10       | 7     |
| "hazelcast"   | 16    | 10       | 6     |
| "neo4j"       | 15    | 13       | 2     |
| "noctarius2k" | 14    | 4        | 10    |
| "devnexus"    | 12    | 12       | 0     |
| "polyglotsdk" | 11    | 2        | 9     |
| "shipilev"    | 11    | 10       | 1     |
| "AlTobey"     | 11    | 10       | 1     |
| "bitprophet"  | 10    | 9        | 1     |
| "GatlingTool" | 10    | 8        | 2     |
10 rows

Amusingly Chris is top of his own network but we also see three accounts which aren’t people, but rather products – neo4j, hazelcast and GatlingTool. The rest are legit though

That’s as far as I’ve got but to make this more useful I think we need to introduce follower/friend links as well as importing more data.

In the mean time I’ve got a bunch of links to go and read!

Categories: Blogs

Is DevOps a People Problem AND a Technical Problem?

Agile Management Blog - VersionOne - Wed, 03/11/2015 - 20:43

weinberg secrets of consultingOver the past few years, I’ve become more familiar with the works of Jerry Weinberg.  One of his best is a book called Secrets of Consulting, which I highly recommend to all those who give advice for a living.  Among the many rules and secrets that he shares, there are two that stand out time and again:

  1. There’s always a problem.  If they’re bringing a consultant in, there’s a problem to solve, even if they don’t really know what that problem is.
  2. It’s always a people problem.  Even in the most highly technical of scenarios, at the end of the day there’s a people issue at the root of it.

Now I don’t want to be one to quibble, but I believe that DevOps is that unusual scenario where getting good at it is both a technical and people problem.  Let’s take a look at what that really means.

nasa-control-roomThe Technical Problem

When we look at the practices that are so important for DevOps, we see a lot of technical solutions.  These practices enable DevOps to run smoothly and efficiently and make a huge difference in the success of an IT organization.  Many of them require a high level of technical sophistication as well as discipline, to achieve.

What are they?   Most of these practices are well understood as the foundation of DevOps. Items like Continuous integration have been around a very long time, and require a CI server as well as the concurrent automated Unit and Acceptance Tests to make Continuous Integration worthwhile.  This also requires a tight integration with the version control system, so that everything can be under version control.  All artifacts of delivery need versioning to truly be successful and, dare I say it, safe in a Continuous Delivery environment, which is of course the logical conclusion of a DevOps approach.

But wait, there’s more

So yes, there are technical practices that are required to truly “do” DevOps.  But in order to do those practices, we need people.  Bringing operations into the Team Room requires a new_shimmermindset and a willingness to change that can be very difficult to engender.  I’m not just referring to the difficult things like learning to automate and *choosing* to automate all Acceptance Tests, but also simple things like remembering to include monitoring items in all of your stories.

This is a big shift in thinking.  Development teams are used to finishing something, handing off to operations, and moving on to the next thing.  They don’t want to be bothered with something in production unless there is a bug, which they will often see as an inconvenience.  Building a culture that goes beyond deployment, but treats development and operations as a single, holistic entity takes a lot of support and willingness on the part of everyone.

Sometimes it’s just about language.  We need to start asking different, or more, questions during our analysis of stories.  Instead of asking if a particular test should be automated, familyTherapyask instead “how will we automate this one?” Including automated deployment and monitoring in our definition of done, or at least in the tasks we identify, will take us very far in the culture of DevOps.  This brings the whole cross-functional team into a world where the success or failure of a story doesn’t stop at the Sprint end.  Getting our team members to all take that to heart, and looking for the operational aspects of a story is hard, and requires patience and nurturing.  For that matter, so is getting the team into the mindset that automating tests is not optional, but required to ride this ride.   This also takes patience and nurturing.

Darn it, Jerry Weinberg is right again!  It really is a People Problem!

Categories: Companies

The Meaning of Kanban From the Inside


Kanban from the inside! What does that mean?

Perhaps it's about practicing Kanban and it is written by a practitioner? And that would be true!

Perhaps it's about understanding Kanban and its community of followers from a community insider? And that would be true too!

Or perhaps it is about something deeper, something truly "from the inside", from inside the author? Kanban from the heart? Kanban from the soul? Kanban expressed by a deeply spiritual person with a strong sense of self and a deeply held set of values?

read more

Categories: Companies

Why Do Most Businesses Fail?

Leading Agile - Mike Cottmeyer - Wed, 03/11/2015 - 14:01

After watching a one minute video of Mark Cuban talking about why most businesses fail, I had a brief but enjoyable conversation with a colleague online.

Friend: So if you try hard and are born smart you always win?

Me: No, if there is a lack of brains or effort, a company will fail.

Friend: But what of the system? I imagine many people at Blockbuster were smart and tried really hard. It’s kind of easy when you’re Mark Cuban to decide that your success is down to being smart and trying hard. Effort itself is pretty worthless if applied to the wrong thing. Likewise intelligence. Seems like an oversimplification at best to me. I did like the bit about giving customers what they want though.

Me: Interesting. You’re hearing him say that you’ll be successful IF. I’m hearing him say that you’ll fail IF. If there is a lack of brains or effort, a company will fail. Maybe not today; maybe not tomorrow; but they will fail in time. All the more reason to collectively work harder than competitors and surround yourself with smart people. Blockbuster was successful for a long time. I think they failed because they didn’t evolve with their market and competitors like Amazon and Netflix gave customers what they wanted.

I wish the conversation had gone longer.  It made me go back and watch the video a few more times and really listen to what he said and to consider if I misunderstood.  Even though we watched the same video, we came away with somewhat polar understandings.

So, why do you think most businesses fail?

The post Why Do Most Businesses Fail? appeared first on LeadingAgile.

Categories: Blogs

Two great Agile sessions coming up!

Agile Scotland - Wed, 03/11/2015 - 10:38
The guys are the BCS have been busy!  If you're into the technical side of software development then go have a look.  Top notch speakers.
- Nat Pryce - Weds 1st April -  FREE, EVENING EVENT
- Kevlin Henney - Agile Architecture course Thursday 4th June - DAY COURSE
Categories: Communities

Dive deep into Product Management, Product Ownership and Creating Great Products

Scrum Breakfast - Wed, 03/11/2015 - 07:30

I have become really excited about the potential of bringing an excited, passionate group of experts into room to work on challenges and problems that inspire them! So I am really excited about the Product Owner Camp in Switzerland!
Product Owner Camp in Switzerland (#POcampCH) is an Open Space conference inspired by the successful Agile Coach Camp in Kandersteg and Scrum Coaching Retreat in London. Unlike its role models, #POcampCH focuses on product creation: "Product Management meets Product Ownership: How do we create great products together?"
Thursday kicks off with an optional master class, "How to Get Quickly from Idea to Minimal Viable Product?" led by Karen Greaves, Samantha Laing, and Steve Holyer. Social activities are planned Thursday and Friday evening for attendees to interact, learn, and get to know each other.
Friday and Saturday, all day, involve all participants to conduct a series of parallel sessions addressing current topics around product creation and development in a Scrum/Agile/XP/Lean/Kanban context. As an Open Space "Unconference" event, the participants define the program. This is an exceptional opportunity for Agile leaders to collaborate and learn from each other. Saturday afternoon is a wrap-up of the POcampCH that involves attendees retrospecting on the event and looking toward the future.Target audienceThe Product Owner Camp in Switzerland is for practitioners involved in product creation, from the idea to the realization. Product Managers, Product Owners, Designers, Developers, ScrumMasters, Agile Coaches, Testers, Entrepreneurs, Innovators and Managers. Not on the list? No worries! If you create new products, POcampCH is for you!
As a Scrum Alliance sponsored event, you can earn Category A SEUs toward your Certified Scrum Professional.
Prices start at CHF 299 / person in double occupancy (yes, this includes your hotel costs!) or CHF 368 for single occupancy.
Dates: June 11 (18:00) to June 13, 2015 (17:00). Optional all-day Master Class on June 11. For more information, registration, and to find out who else is coming, see!

Categories: Blogs

Pulse Pricing Updates

A little madness - Wed, 03/11/2015 - 05:45

To all Pulse customers, existing and potential, a bit of news: we’ve applied some long-overdue changes to pricing. Well, not changes so much as clarification! Since the initial release of Pulse we’ve always favoured an up-front pricing policy. We loathe hidden pricing designed to lure you into a lengthy, pushy sales process. So our sales front page has always included pricing information.

However, the pricing on the page didn’t show the full reality. We had three tiers of pricing for 1, 5 and 15 agents, then the option of license 10 packs on top. In practice customers often asked a few questions:

  1. Can we get a more specific number of agents, e.g. 10?
  2. Can Pulse handle large numbers of agents, well beyond 15?
  3. Do discounts apply as the number of agents continues to grow?

In all cases the answer has been yes. We aim for flexibility, and have allowed anyone that asked to purchase a smaller number of agents at a time. Pulse can certainly handle many more than 15 agents: some customers have hundreds in production and we’ve always offered discounts for high numbers.

Thus it is about time we reflected reality in our published prices. From now on there are no defined agent pack sizes: you start with a single agent license for US$900, then add as many additional agents as you need. Agents are priced on a sliding scale so they become progressively cheaper as your installation grows. You can see this clearly on our updated sales page.

What does this mean for existing customers? As a matter of policy: no existing customer will lose out. If you have a deal better than the new published pricing, that deal remains. This may mean you can get more agents free, or a discounted renewal price next time around. For reference: the original single agent license is now US$50 cheaper, and this will translate to a US$25 discount for our existing Pulse Standard License holders. The pricing for 5, 15 and 25 agents remains identical, so many customers will see no change. Larger licenses will be dealt with individually as they come up for renewal.

We think this new pricing better reflects our aim to be both up front and flexible. If you have any questions, please contact sales.

Categories: Companies

New Video: Kanban in One Minute – Do It Right

Learn more about our Scrum and Agile training sessions on

Another short video for your viewing pleasure!  Kanban in One Minute – Do It Right by Michael Badali.

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!
Categories: Blogs

Preparing People for Organizational Change

Illustrated Agile - Len Lagestee - Tue, 03/10/2015 - 20:00

Organizational change will always be an endless journey and this journey will always be personal and unique. This post from a couple years ago mapped out a possible path people may navigate through an Agile change journey and just how unique this experience can be.

Many organizations expect a “point a” to “point b” route when introducing change into their system. Introduce a specific change framework or select the latest “methodology of the day,” hire a fleet of coaches and consultants and in no time at all we will arrive safely at our destination of cultural and productive bliss.

But things get messy. A plan rarely survives real-life. The straight line never stays very straight. This environment of change, uncertainty, and ambiguity is often unsettling to many (including myself at times).

So, how can you prepare people for this winding road of change? Can we prepare them at all? While you will never be able to calm every nerve or address every concern, can we help people become more comfortable with the discomfort of change?

As a participant, leader, and coach, I have been involved in introducing change to many large companies and when I sense I am around someone who is nervous or anxious about the road ahead, I have a couple of topics I bring up in my conversations with them.

Shifting to an active voice as if I would be talking directly to someone, here are some of the things I bring up:

Enter with eyes wide open. Understand and accept this will not be easy and there may be days that don’t go very well. Days when nothing seems to be working and you would like to rip every task card off the wall. Days when you just don’t get it and want to fall back on existing habits and processes. This is all normal and a good sign you are human like the rest of us. While this will be exciting, I can guarantee there will be periods of confusion, questioning, fun, camaraderie, extreme productivity, and stalled efforts…perhaps all in the same day.

Soak it all in. Pull from a variety of sources and learn about well-functioning organizations and collaborative methodologies. Learn about Lean Thinking, Kanban, Scrum, and The Lean Startup. Discover elements of the change being introduced and study those as well. Begin to understand the roles and processes we are introducing and more importantly, why we are doing them. Learn about companies doing some of the things we are trying to implement. For example, find out how Facebook does automated testing and how 37signals delivers products as fast as they do.

Experiment. Treat everyday as a set of experiments. Take what you have learned, studied, and experienced in the past, mix things together, and create new experiences. Change is what you make it. What I have learned is I have enjoyed change the most when I made it an adventure.

Start to wander. Venture into other teams and other areas of the organization introducing their own change and see what is working for them or hear what they are struggling with. Often change is started in small waves of pilots. Not sure how the pilots are progressing? Talk to someone actively engaged on one and hear their story. Show up at a daily stand-up meeting and see how team interaction will be working in the future. Curious about the new Scrum Master role? Meet with one them over coffee and see how it’s done.

Going backwards. Or sideways. Or diagonal. Embrace the fact that this journey is uniquely yours. Just because someone else seems to have “gotten it” and you haven’t is ok. Frustration is natural but keep moving and stay engaged. The enemy to any movement is a lack of energy or an increase in apathy.

Please note, this post does not suggest an approach for calming the nerves during an organizational re-structuring when people are let go or removed from their job. It is not easy (or possible?) to prepare people for this type of change.

Becoming a Catalyst - Scrum Master Edition

The post Preparing People for Organizational Change appeared first on Illustrated Agile.

Categories: Blogs

Knowledge Sharing

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