Skip to content

Feed aggregator

Migrating to Pivotal Tracker from a Third-Party Tool

Pivotal Tracker Blog - Fri, 07/17/2015 - 20:20

Welcome to everyone who recently started using Tracker! If you were using a different project management tool previously, you probably have tickets or stories you’d like to get into your Tracker projects. One convenient way to migrate them over to Tracker is to place them in a CSV file that’s compatible with Tracker’s import tool. Below, we’ve outlined five easy steps to accomplish that.

Step 1. If you haven’t already, first create a project in Pivotal Tracker, then check its Project Settings page (click the project menu gear icon located near the upper left, then Edit Settings from the dropdown) to make sure the point scale is the same as you’ve been using to estimate with in your current tool. Then, invite your team members to that project so they’ll be able to use the stories you’re about to import.

Point Scale

Step 2. Export your stories from your existing tool (preferably in CSV format). Afterwards, it’s best to open up the exported file in a spreadsheet application such as MS Excel or LibreOffice for easy manipulation of the content.

Step 3. The first row in the exported CSV file should be renamed to match the column headers Tracker is expecting. Here’s a listing of the most commonly used fields for importing into Tracker, along with their definitions and possible values/restrictions.

Field Content Possible values or restrictions Title The title of the story
  • 5,000-character limit
  • Required field
Labels Tags that you can associate to your stories
  • Separate multiple labels by comma.
Type The type of story
  • Feature, bug, chore, epic, release
Estimate The numerical point value you wish to assign to the story
  • Values must match the selected Point Scale for your project.
  • Epic and release types may not contain estimates.
  • Bug and chore types may contain estimates if the “Bugs and Chores May Be Given Points” setting has been enabled in the destination project’s settings.
Current State The state the story currently resides in
  • Unscheduled, unstarted, started, finished, delivered, accepted, rejected
Created at The date the story was created (e.g., “Nov 22, 2014” or “11/22/2014”)
  • If left blank, the created date will default to today’s date.
  • Future dates are not allowed.
Accepted at If a story is given a Current State of accepted, you can specify the date the story was originally accepted, (e.g, “Jan 15, 2015” or “01/15/2015”)
  • If left blank, the “accepted at” date will default to today’s date.
  • Do not assign an “accepted at” date for any other state other than accepted.
  • Future dates are not allowed.
Requested By The name of the user who requested/created the story
  • If left blank, the requester will default to be the user who performs the import within Tracker.
  • The names in the file would also need to match the names in their Tracker Profile exactly (i.e., if the Tracker profile contains “David Smith” and the CSV file contains “Dave Smith,” Tracker would treat Dave Smith as an uninvited user).
Description The content that will be used to describe the story
  • 20,000-character limit
Owned By The name(s) of the user(s) who own the story
  • You can assign up to three owners, but each must be comma separated.
  • Again, names in your CSV file must match the user’s name in Tracker exactly.
Comment Comments related to your story
  • 20,000-character limit
  • You can add as many comments as you like, but each must be separated into its own column.
  • You can specify an author and date by surrounding the member name/date in parentheses, following a space after the comment text (see screenshot).Date
Task To-do items related to your story.
  • 1,000-character limit
  • You can add as many tasks as you like, but each must be separated into its own column.
  • Each Task column must be paired with a Task Status column.
Task Status The status of your task
  • Completed, not completed
Deadline A deadline date that can be added to a story of type “release”
  • Only stories of type “release” may be assigned a deadline.
  • Future dates are allowed.


Here’s an example of what your CSV file might look like:

CSV Import File Example

Step 4. After you’ve built your CSV file with the fields Tracker is expecting, you’ll need to groom the file to prevent any possible conflicts. The following list covers the most important tips to ensure there will be no issues upon attempting the import.

  • File limit: You can only import 500 stories at a time into Tracker, so you’ll want to break up the file if it has more than 500 stories in it. Please be sure the first row in each file is the header row (containing the column headers/fields Tracker’s expecting).
  • Story order/priority: For stories with any state other than accepted, Tracker will order them in their respective panels to match their order in the file, so be sure to have them listed in priority order from highest to lowest.
  • Attachments: Attachments from your old stories will have to be uploaded manually to each story, as they cannot be imported via CSV, unfortunately.
  • Estimates: For the Estimate field, a value of “-1″ indicates an unestimated story. However, if an estimate of “-1″ is assigned, the state must be compatible (i.e., a feature story can’t be in the accepted state without a point estimate).
  • Estimates for bugs/chores: If you estimated bugs/chores in your previous tool, and also want them estimated in Tracker, you’ll need to enable the Bugs and Chores May Be Given Points setting from your Project Settings page (otherwise you’ll receive an error when importing a file that contains pointed bugs/chores).
  • Story IDs: Tracker can’t reuse your existing ticket/story IDs from your current tool, so don’t include an ID column/field in your import file. If you want to keep and reference them, you could use the comment field to contain the ID or a URL to the old stories.
  • Formatting: Please be sure that your file is saved in UTF-8 as well as comma-delimited (CSV) format.
  • Additional data: Your previous tool may contain additional data fields/columns that are not compatible with Tracker’s importable fields. If you wish to retain these points of data, you might consider adding them in the Description, Tasks, or Comments fields in your CSV import file.

Step 5. After you’ve created your CSV file and formatted it to be compatible with Tracker’s CSV Import tool, you can import the file by following the steps below:

  1. After loading the destination project in Tracker, click the project menu gear icon located near the upper left.
  2. Select Import CSV from the drop-down menu.
  3. Click the Choose File button and select the appropriate file.

CSV Import 1

CSV Import 2

For more on importing, check out this page.

If for any reason you encounter errors while importing and are unable to resolve them yourself, feel free to email our support team at (preferably with a copy of the problematic CSV file) so we can assist you in troubleshooting any issues.

Though this post focuses on CSV as a way to get data from other tools into Tracker, you might find using our API is preferable. It’s even worth doing an internet search on the name of your tool and Pivotal Tracker, to see if someone has already created a migration tool/script, and made their tool available via Github, for example.

Finally, instead of migrating your data over, you might be looking for an integration instead. You might find your current tool listed among our integrations. Some other tool vendors have created their own integrations with Tracker as well.

We greatly appreciate that you’ve chosen Tracker for your project management needs and hope that this guide has assisted you in transitioning!

Happy Tracking!

—The Tracker Team

The post Migrating to Pivotal Tracker from a Third-Party Tool appeared first on Pivotal Tracker.

Categories: Companies

Postscript on Throughput and Delivery Rate

Improving projects with xProcess - Fri, 07/17/2015 - 13:40
Most people use Throughput and Delivery Rate in Kanban systems as synonyms - including myself up to this point. I've changed my view however.

The canonical form of Little's Law in Kanban is as follows:
Delivery Rate = WiP / Lead Time    [ande] even though these days I more frequently express it this way:
Throughput = WiP / TiP Surely these two ways of writing the equation are entirely equivalent aren't they? Well maybe not.
Note: All these terms are defined in my Glossary Proposal (which has recently been updated to include the definition of Throughput). Feedback, comments and references to publications using the terms defined are welcomed and encouraged.Throughput is the term +Daniel Vacanti uses (among many others), particularly in his excellent new book Actionable Agile Metrics [vaca], and it got me thinking about one of the problems with using Delivery Rate: what about the items which are not delivered but are discarded? If there are a significant number of these Little's Law as expressed in the first equation will not apply, unless we exclude discarded items from calculations of the historical averages for WiP and TiP. All very well except the WiP limits - a crucial control for Kanban systems necessarily contain items that may be discarded in the future.

Without trying to solve this problem, but rather clarify the terminology we use to describe it, I think it is useful to have differing definitions for the 2 terms:
Delivery Rate is the rate at which work items exit the system in a "complete" state (i.e. just delivered items)Throughput is the rate at which work items exit the system whether discarded (this includes those which move back in the process to a state prior to the system under consideration) or completed (i.e. both delivered and discarded items)Let me know if you find this distinction useful. Your feedback is essential in honing the Glossary Proposal to one that everyone finds helpful and acceptable.

  • [ande] Anderson, David J. Kanban, Blue Hole Press. (2010)
  • [vaca] Vacanti, Daniel S. "Actionable Agile Metrics for Predictability: An Introduction". LeanPub. (2015)
Categories: Companies

Geneva SonarQube Conference – Sept. 23 & 24.

Sonar - Fri, 07/17/2015 - 10:13

We are very happy to announce the first SonarQube European User Conference! This two-day free event will take place in Geneva on September 23rd and 24th, right in the heart of the city at Côté Cour Côté Jardin – Rue de la Chapelle 8, 1207 Geneva.

Following the success of the conferences in the US and Paris earlier this year, the Geneva conference targets a broader and more international audience. It will provide a forum for users to meet, network, and share experiences and best practices around the SonarQube platform. Attendees will also be able to learn directly from the SonarSource Team about the platform roadmap and vision, as well as what was accomplished with 4.x and what is being accomplished with the 5.x series.

The program will highlight some of the exciting topics we’ve talked about these past weeks, like the Water Leak paradigm, the new SonarQube GitHub Plugin, the collaboration with Microsoft to integrate with the .NET ALM Suite, and the coverage of the security and vulnerability markets. We plan to make the conference as exciting as these recent topics and even more so!

There will also be more informal sessions, such as presentations and feedback from customers and partners on large scale implementations of SonarQube, and hands-on workshops on technical aspects such as platform monitoring, custom rules development…

We hope you will be able to make it, and are looking forward to meeting you there! To register, please click here.

Categories: Open Source

Product Manager, Product Owner, or Business Analyst?

Johanna Rothman - Thu, 07/16/2015 - 19:44

Do you have a title such as product manager, product owner, or business analyst?

We hear  these titles all the time. What does each do?

Here is how I have seen successful agile projects and programs use people in these positions. Note that I am discussing agile projects and programs.

The product manager creates the roadmap. She has the product vision over the entire life of the product. Typically, what’s In the roadmap are larger than epics—they are themes or feature sets. 

Product management means thinking strategically about the product. You might require several projects or programs to achieve what the product manager wants as a strategic vision.

Product owners (PO) work with agile teams to translate the strategic vision into Minimum Viable Products. The PO decides when the team(s) have done enough to release. See the release frequency image to understand the cost and value of releasing.

The business analyst may do any of these things. In my experience, I have seen business analysts focus on “what does this requirement/feature/story really mean to the team and/or the product?” I have seen fewer BAs do the strategic visioning of the product over its lifetime. I have seen BAs work with POs when the PO was not available enough for the team. I have seen BAs do great work breaking stories into smaller components of value, not architectural components.

Your team might have different names for these positions. Each team needs the strategic lifetime-of-the-product view; the tactical view for the next iteration or so and the knowledge of how to re-rank the backlog; and the ability to translate stories into small valuable chunks. 

Can one person do each of these things? It depends on the person. I have found it difficult to move quickly from the tactical to strategic and back again (or vice versa). Maybe you know how. For me, that is a form of multitasking. 

The more important questions are: do you have the roles you need, at the time you need them on your team? If you are one of these people, do you know how to perform these roles? If you are outside the organization in some way, do you know what you need to do, to perform these roles?

If you don’t know what to do to help your team, consider participating in Product Owner for Agencies training. Marcus Blankenship and I will help you learn what to do, and coach you in real time as to how to do it best for your team. I hope to see you there.

Categories: Blogs

Little's Inequality

Improving projects with xProcess - Thu, 07/16/2015 - 17:32
The interesting thing about Little's Law, in spite of its very general applicability, and in certain cases mathematical certainty, there are many cases when it simply does not hold true. In those cases it's not so much Little's Law as Little's Inequality. Could the fact that specific instances of data do not follow Little's Law actually give us useful information about our Kanban and Scrum systems and point to the right kind of interventions to manage and improve their flow? That's what this blog is about.

Flow Metrics for a Kanban System over time
(WiP, TiP, DR, Delivery Bias, Net Flow)

In 1961 John Little published his proof of this general queuing theory equation [litt]:
L=λW L is the average number of items in the queue, λ is the average arrival rate, and W the average wait timeSince that time Little's Law has found numerous applications in the study of general flow systems from telecommunications to manufacturing, including in Kanban systems. Because throughput or delivery rate is the more significant attribute for management of such systems (and on average it is approximately equal to arrival rate), it is often expressed as follows:
Delivery Rate = WiP / TiP The overline indicates the arithmetic mean, WiP is the number of items in the system, and TiP the "time in process" from entering to leaving the system under consideration. See this Glossary for further explanation of the meaning of TiP, versus Lead Time or Cycle Time (and why I don't use Cycle Time!).However when we look at data from actual Kanban systems, where the averages are over relatively short periods (say a week or a month), or where average arrival rate does not equal average delivery rate, it is Little's Inequality that applies, not his Law. Juggling the terms above we can express it in this way:
Delivery Rate  ( WiP / TiP )  0    ("Little's Inequality")This is because if the system itself is trending in some way (technically the system is not stationary), or if the scope of the averages is not so wide that every item that entered has left the system - usually both these conditions are true for the periods we wish to analyse - then Little's Law does not apply exactly.

That might seem to imply Little's Law is not useful to us. However the degree to which the law is not true is very relevant and does give us important management information:
Delivery Rate  ( WiP / TiP ) < 0    More work is being taken on than is being deliveredDelivery Rate  ( WiP / TiP ) = 0    The system is balancedDelivery Rate  ( WiP / TiP ) > 0    More is being delivered than new work being taken onThis looks like actionable data for managing flow in Kanban Systems - a number that shows bias in the system towards (or away from) delivering. Let's look at the set of graphs in the figure above that demonstrate this. The data set is from +Troy Magennis's SimResources website and uses his data, spreadsheet and some of the graphs he provides to assist with his forecasting models[mage]. You can find more about Troy's work at and also download these spreadsheets to explore what your data reveals about your Kanban or Scrum systems.

Firstly the figure shows graphs of the 3 main variables in Little's Law; WiP, TiP and Delivery Rate, The next graph is a plot of Little's Inequality - labelled Delivery Bias, showing whether it is greater or less than zero at any point in time. Note that the formula above is normalised relative to the overall average delivery rate for the whole dataset (AvDR) so that the range (in this case between -1 and +1) is comparable with other datasets. The final graph in the set shows Net Flow, the difference between items completed and started - it is one of the metrics included in Troy's spreadsheet and it again provides a view of how balanced the system is.

As expected the graphs show a strong correlation between Net Flow and Little's Inequality for most of the range. Clearly if we're starting more than we're finishing we should expect both the inequality and the Net Flow to be negative. What's interesting is where they don't correspond, and why. Look at weeks 2015-11 and 2015-12. Why in week 11 are we finishing more than starting and yet we still have a negative value for Little's Inequality? The clue is in the TiP for these weeks. In week 11 the average TiP is much lower than in week 12. Perhaps this indicates the items closed that week were smaller in size - or maybe they were "expedited" at the expense of other items in progress. When the items that had been in process longer are closed the following week, Little's Inequality indicates more strongly that balance is being restored.
Little's Inequality as expressed above focuses on Delivery Rate, hence the label Delivery Bias. It could be re-expressed to focus on Time In Process as follows:TiP  WiP / Delivery Rate      This metric might be labelled Time in Process Bias. We want TiP values to be as low as possible, but a negative value of this metric is likely to indicate an issue to address, since it would indicate that the TiP of the work in progress is likely to be longer than the items recently delivered.
The time an item stays in the process is also the focus of a new metric from +Daniel Vacanti recently published in his Actionable Agile Metrics [vaca] (see also He also looks at the degree to which a given system follows an ideal flow through a metric he calls "Flow Debt" (roughly translated as delivering more quickly now at the cost of slower times later). Dan prefers the term Cycle Time to Time In Process and so defines Flow Debt as the difference between the "Approximate Average Cycle Time" (AACT) as observed on a Cumulative Flow Diagram and the "Average Cycle Time" (ACT). Comparing these 2 items gives an idea of whether Flow Debt  is being created or not. Flow Debt is accumulating when AACT>ACT. You can calculate AACT by looking at the time since the cumulative arrivals into the system equalled the current cumulative deliveries. ACT is calculated from the arithmetic mean of the actual times for delivered items in the period. Again the degree to which these quantities do not match indicates the degree to which the system is out of balance.
All these metrics - Little's Inequality (or Delivery Bias), Net Flow and Flow Debt - provide insight into the behaviour of Kanban systems based on the degree to which the system follows Little's Law over the period of study. Further experimentation and experience will show the best ways to use them in concert and the best ways to visualise the flow characteristics of the systems and how to intervene to improve them.
If you have data which you would like to analyse using these metrics do let me know. I'm happy to share spreadsheets and advice with anyone who contacts me. Equally check out Troy Magennis's and Dan Vacanti's web sites referenced above for more tools and insights.
  • [litt] Little, J. D. C. "A Proof of the Queuing Formula: L = λW," Operations Research, 9, (3) 383-387. (1961) 
  • [mage] Magennis, T. "Forecasting and Simulating Software Development Projects: Effective Modeling of Kanban & Scrum Projects using Monte-carlo Simulation", (2011)
  • [vaca] Vacanti, Daniel S. "Actionable Agile Metrics for Predictability: An Introduction". LeanPub. (2015)
Categories: Companies

Minimal Action Energy Principle in User Interface Design

TargetProcess - Edge of Chaos Blog - Thu, 07/16/2015 - 17:07

In physics there is an interesting fundamental principle: a system moves from one state to another using the minimal path, i.e. a path that demands the minimum energy.


When I read this, I immediately think about user interface design. Can we apply this principle to UI? It seems yes, since it is quite fundamental. I have never heard of attempts to use energy to evaluate efficiency of UI. This is the first try.

Let’s say, we have several interfaces that can transfer a user from state A to state B. Which one is the best? The Minimal Action Energy Principle in User Interface states:

From all available interfaces that transfer a user from state A to state B we should select the one with the minimum action energy.

So what is energy? That is a very tricky question, even in physics. But humans are more simple, so we can define all processes where we loose energy: clicking, taping, scrolling, looking/thinking, moving the mouse cursor, waiting, typing, asking for help, screaming, etc. A more complex thing is to unify these actions and have the same units for them to come up with a single energy number. After that we can compare energy of user interfaces and find the one with the minimal energy required to complete some action.

We can start with a simple model that will be good enough for the tests. We should introduce a unit to measure User Interface Action Energy. It can be yellow frogs, but let’s call it Action Units (au). All actions can be expressed via this unit:

1 click / tap = 1 au
1 scroll movement / wheel rotation = 2 au
1 second of thinking / looking = 3 au (thinking is hard)
1 second of cursor movement = 1 au
1 second of waiting = 0.5 au
1 second of typing = 2 au
1 second of asking for help = we fucked up

If I missed some interaction patterns let me know. Now we have a model to measure User Interface Action Energy. Note that energy is not equal to time. It means the user can actually spend more time with a system, but apply less energy to complete the tasks.

Let’s calculate User Interface Action Energy for a simple login action:

login_energy Looking at the form: 1
Click the email input field: 1
Recall your email: 1
Type the email: 3
Press Tab: 0.5
Recall the password: 2
Type the password: 3
Press Tab: 0.5
Realize it doesn’t highlight the login button: 6
Click the login button: 1
Wait 20 seconds to log in: 10
Total: 29 au

This decomposition makes it clear where we have energy leaks! Let’t fix it to spend less energy:

Looking at the form: 1
Click the email input field: 1 (This field should have the focus by default).
Recall your email: 1
Type the email: 3 (autocompletion can save some au)
Press Tab: 0.5
Recall the password: 2
Type the password: 3
Press Tab: 0.5
Realize it doesn’t highlight the login button: 6 (Tab navigation should work and highlight the button. Note that confusion causes a significant increase in the energy required to complete the scenario).
Push Enter to log in: 0.5
Wait 20 seconds to actually log in: 10 (Warm-up the application to reduce this time to 6 seconds that equals to 3 au)
Total: 13.5 au

This design is two times more efficient since it takes two times less energy to complete the task. Can we do even better? Yes, implement the Login scenario using the Facebook auto-fill button. This solution eliminates thinking completely.

1_login_500px_mini Looking at the form: 1
Click the Facebook button: 1
Wait: 3
Total 5 au

The absolute nirvana of UI is zero energy. You do nothing and authenticate. Is it possible? Yes, but it will compromise security. Is it possible to do that securely? For example, you navigate to an application, the device takes your picture, recognizes your live face (the photo should not work) and logs you in. You do nothing, but still wait for some seconds most likely. So total the Action Energy will be around 2 au.

Time != Energy

Usability testing is not new and clicks counting is not new. Usually we just measure the time to complete a task, observe bottlenecks and try to fix them. However, time should not be the ultimate measure of a user interface. Most likely, thinking is the most energy-heavy activity, so the best thing a designer can do is to remove thinking from the user interface as much as possible. Steve Krug was right. Some extra clicks might be OK if they reduce thinking about UI.

Moreover, a usability test doesn’t give you a breakthrough. You can find some leaks, confusions, etc., but to radically improve a solution you should think hard. When testing a basic login form you will not find a solution with the Facebook button. This solution evolves from other activities, like brainstorming, taking a shower, walking, etc.

The designer’s job is to think. The user’s job is to use the tool with ease.

Ideally, the designer should create several solutions, select the ones with a lower action energy and test them with real users to find the solution with the minimum action energy.


I think we can automate action energy measurements. Now we have quite advanced equipment to measure the eye movement, the heart rate, clicks, cursor movements, etc. In theory it is possible to create a software that will calculate User Interface Action Energy for every scenario automatically during live usability tests.

For remote usability tests where we have a limited access to a real person’s data we can measure action energy with a good approximation. Still it will be a more objective metric than just empirical observation.

  1. Estimate UI efficiency with User Interface Action Energy, not time or some empirical observations.
  2. Action energy includes all processes where the user looses energy like clicking, taping, scrolling, looking/thinking, moving the mouse cursor, waiting, typing, asking for help, screaming, etc.
  3. Create several solutions and test the most promising ones to calculate Action Energy. Find the solution with the minimal UIAE and it will be the most efficient one.
  4. Confusion, thinking and dead end routes are the main causes of energy leaks in UI.
Categories: Companies

New Video: Myths of Scrum – A Public Retrospective

Learn more about our Scrum and Agile training sessions on

Although subtle, having a public retrospective can do terrible damage to a Scrum team.  In this video I explain what I mean by “public”, why it is so bad, and what you should do instead.  This is part of a video series on the Myths of Scrum that is meant to respond to some of the most common mis-information (myths) about Scrum and Scrum practices.  I will follow-up this video in several weeks with a written article complimentary to this video.  Feel free to let me know in the comments if you have any topics that you would like me to cover in my video series!

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!

The post New Video: Myths of Scrum – A Public Retrospective appeared first on Agile Advice.

Categories: Blogs

Early Bird Ends 31 July for Agile on the Beach Conference

Scrum Expert - Thu, 07/16/2015 - 16:12
Early Bird ticket will end 31st July for the for Agile on the Beach conference that will take place in Falmouth, UK, September 3-4 2015. Early Bird Tickets are on sale for the conference and can be secured via eventbrite, capacity is currently at 90%. This year we are moving to a bigger venue. The Performance Centre is still based on Tremough Campus at the Penryn. This venue allows us to comfortably host all 350 attending. We will be having our pre-conference pasty and a drink gathering at the Performance ...
Categories: Communities

The One Thing You Must Do this Morning to Achieve Your Goals

Agile Management Blog - VersionOne - Thu, 07/16/2015 - 14:30









We all have goals, yet many of us don’t meet them. Sometimes this is disappointing, but more often than not the bar just kind of moves down, time passes, and we become complacent.


Because it is pretty tough to stay focused for long periods of time on “Big Hairy Audacious Goals”.

So what can you do to meet your goals?

Just like it doesn’t work to wait till the end of a release to power through the requirements in a traditional waterfall, it doesn’t work to wait till the end of the day to power through your tasks. Instead of powering out of the day, focus on powering into your morning.

I once heard a CEO tell his company a story to motivate them. It was January and the year was just kicking off. He said “If we want to meet our annual goals, we have to meet our quarterly goals. If we want to meet our quarterly goals, then we have to meet our monthly goals. In order to meet our monthly goals we have to meet our weekly goals, and to meet our weekly goals we have to win each day.” He said to forget everything else and just win the day. He then went on to explain the origin of the mantra.

If you follow college football, you may be familiar with the Oregon Duck’s mantra “Win the Day.” Most football coaches at whatever level preach about just focusing on the next game and not looking past it. When Chip Kelly began coaching at Oregon, he began preaching for players to just “win the day” because he believed the team needed to strive to win at every sprint, study session and scrimmage in order to win the next game.

This story and mantra resonated with my agile roots. Agile is rooted in focusing on the day to achieve the end goal. Agile’s foundation is built around not over planning to meet the final goal, but taking each day as it comes and responding accordingly. Stand-ups are all about teams winning the day.

Truthfully, as inspiring as this story was, I had come to forget about it till the other day when I was working out at the gym and listening to a podcast in which an author was discussing their book The Miracle Morning. The book is about six practices people can do every morning to be more productive, successful and happy. During the interview, the author started talking about the “how to win the day” mantra and how, if you want to win the day, you have to win the morning.

This snapped me out of my workout. On the surface, it would seem that the author just took something successful and took it one level down, but to me it was brilliant and once again aligned to my agile roots.

At work we are so often bombarded by firefighting that we fail to focus on our original goals or tasks. Agile, of course, employs story cards and stand-ups to combat these and other distractions. Most teams hold their stand-ups in the morning to kick the day off right.

Despite all of this, I had never thought about these practices being designed to help us win the morning so that we would win the day and ultimately win the end goal, but that is what they do. So, now I want to think about other things our teams can do first thing in the morning to ensure that we win the day – because to win the day, you have to win the morning.

Categories: Companies

Failure Modes of an Agile Transformation: Congruency

Rally Agile Blog - Thu, 07/16/2015 - 14:00

To this point, I’ve covered topics around failure in leadership and failure in workflow. It’s now time to dig a bit deeper into the question, “How does your organization “show up?” That is, “What’s the overall sense of how people take ownership for their behavior in the transformation?” What healthy alignments emerge among the teams? When a leader chooses to ignore the importance of behaviors and relationships, I refer to this as a failure in congruency.

What do I mean by congruency? To take a geometric perspective, envision polygons that have similarities in the number of sides; their angles also align with one another. In this, they are congruent. They can turn or flip or rotate and remain congruent. In fact, they need not be in the same location to have this attribute of congruency.

 (photo: Flickr CC)

In our human world, congruency evidences itself through changes in behaviors across the team. Congruent team members move away from a “yes/no” “black/white” “us/them” mentality. Congruent teams abide by norms in which pathological (yes I said pathological) behaviors are not acceptable, because relationships matter. The pathologies of blaming or placating are replaced with an emphasis on equal stature and equal voice. In environments of congruency, each member is heard, understood, and valued.  

Of the 12 failure modes in Agile transformation, consider failures 7, 8, and 9 as failures in congruency.

7. Lack of a Transformation Product Manager

Imagine your transformation as a product. The product you create is not one that is “in” your business; that is, it is not software or a service you would sell. Rather, this product is one that works “on” your business. As such, it requires the discipline we’d ascribe to product development. You need to identify a “Transformation Product Manager” to be your scout leader in delivering a high-quality transformation. Have this person work in a tight relationship with the executive owner of the transformation. Together, they define the disciplined exploration and execution to deliver a world-class transformation. And, together, they are the models of congruency among all players in the transformation. They define the value of our various team polygons: different but equal.

Using language from Virginia Satir, think of congruent teams as “family” systems in which the whole matters. As you move through the bumps of your Agile transformation, your Transformation Product Owner helps the teams be attentive to the incongruent behaviors that can eat away at the sense of “us” and “among”. What behaviors are creating distrust or lack of safety in your transformation? If you walk around your teams and notice tendencies toward blaming, placating, distracting, or being overly focused on process and structure , you are smack in the middle of incongruency. Ignore these harmful behaviors at your own risk.

All the process in the world is not going to move your Agile transformation into a healthy, sustainable state.

In a healthy world of Agile transformation, an intention around congruency emphasizes, “How can we better behave as a whole system to bring about the best results?” Here’s a start: ensure your Transformation Product Manager has the vision and empathy to recognize the destructive, incongruent behaviors. Next, ensure there is a non-negotiable value of trust — not just within a team, but across teams. Incongruency will evidence itself through “us/them” behaviors. Remove confusion about what we mean by product ownership. Incongruent Product Owners focus on “what’s in it for me” (WIIFM). There is a protectionist attitude about their particular backlog and the teams that work on them. Blaming becomes their primary communication mode.

 (photo: Flickr CC)

Congruent transformations breed new types of Product Owners, who let go of this pathology around defending their product and product teams. Instead, they engage in conversations like, “Given the value that this product brings and its projected cost and value, what’s best for the overall portfolio?”

Investing in a congruent transformation opens critical dialogue around:

  • How the transformation impacts behaviors as well as processes and structures
  • Clarity of transformation goals in teams and across teams
  • The health of teams where behaviors such as blaming and placating, or a focus primarily on process and hierarchy are recognized as detrimental to the transformation
  • Intentional decisions about consistency of behavior not just standards and practices around process and metrics
  • Supporting the benefits of congruency over enforced enforced behaviors
8. Failure to Create Fast Feedback

 (photo: Flickr CC)

Did you know that Sir Isaac Newton never had an apple fall on his head? He was, however, the father of the fundamental law of cause and effect. Little did he know the impact his physics would have on software development in the 21st century. Through the Industrial Age into the Age of Information, we’ve been clinging to cause and effect in how we build our organizations and how we expect them to work. {Link: Frederick Taylor} and [Link: Henry Ford] took advantage of this principle too. At its core, the assembly line uses cause and effect to create sequential, predictable, repeatable processes. Feedback loops on quality were less important or non-existent compared to how many items came off the line at any given point.

But where are we now? The nature of our knowledge work is inconsistent with the predictable, sequential work Newton helped foster. Yes, gravity still exists in a congruent world (well, at least in mine it does) but there’s much more going on. This is particularly true in an Agile transformation.

The forms we take, the behaviors we bring, the knowledge we carry all impact how we can stay in congruency. And that means we need to embrace regular learning as a core practice in our work.

How would you know that your Agile transformation remains largely informed by Newtonian physics? Think about these behaviors:

  • Clinging to a strict sense of predictability for when feature work will be completed
  • One centralized organization deciding all standards and rules for every team at the start of the transformation
  • Large-batch delivery of feature sets
  • Holding onto the belief that precision in analysis can resolve all risks in product delivery
  • Lack of experiments to test cause-and-effect assumptions about time, effort, and value
  • Blaming between business and development about delivery predictions and actual dates to support projected value
  • Blaming between development and testing about defects long after the features have been built

And finally, my favorite indicator of incongruent behavior:

  • Failure to get feedback through retrospectives, or the retrospectives that do occur perpetuate cause-and-effect fallacies and pathological behaviors (blaming, placating, etc.)

Fast feedback is the unspoken hero of congruency. We seek feedback on:

  • Guesses
  • Value
  • Behavior
  • Risk
  • Culture
  • Agile practices

In sum, healthy Agile transformations crave fast feedback on every aspect of how our the transformation is progressing. For this to occur, ensure you deliver feedback both ad-hoc and on a cadence, the latter being more formal and facilitated. The ad-hoc feedback reduces the waste of waiting for direction on very transactional decisions; the cadenced retrospectives ensure regular inspect-and-adapt sessions across the organization.

9. Short-changing Collaboration and Facilitation

We humans forming teams are constantly playing with the balance of how to be a team member and now to remain an individual. How can I speak up, be valued, and not have fear of recrimination while at the same time working toward the good of everyone? This is where some sense of congruency can help.

Recall that our congruent polygons are not identical. Rather, they hold similar characteristics such that you could recognize them as belonging to the same “polygon tribe.”

Can you say this about your teams? A few things occur when we inadequately support team interactions through facilitation and collaboration: we lose a sense of trust. Our teams end up fighting the gravitational pull of artificial harmony, low standards, and inattention to results, all due to a fundamental absence of trust. (See Patrick Lencioni’s The Five Dysfunctions of a Team to dig more into this pyramid of incongruent behaviors.)

Think about this: using Virginia Satir’s language, if we invite behaviors that gnaw away at the core fiber of a team, people move into modes of behaving that do not bring out their greatest insights. When this occurs, our dynamic is self-destructive. Why? Because we are only as smart as the least vocal person in a team.

How do we hold our insights dear and precious and necessary? We must seek a core team belief that collaboration makes us greater. And to collaborate, we recognize the value of objective facilitation. The work of the facilitator guides a team of individuals to decisions that integrate diverse perspectives in order to converge on actionable decisions. Good facilitators devote themselves to bringing out the best in the team. They do so by addressing incongruent behaviors and creating divergence and convergence processes, to safely buoy the team to sustainable decisions.

 (photo: Flickr CC)

Be clear with yourself and your teams. Collaboration does not mean groupthink, despite what people may infer. Rather, we are explicit and intentional about when to bring voices together for the greater good of the team. These voices can disagree. And we need them all so that we uncover risks, opportunities, puzzles, and surprises. Armed with this knowledge, teams can bring this caution into their commitment and move forward with their work.

Jean Tabaka
Categories: Companies

Helping others deal with conflict

Growing Agile - Thu, 07/16/2015 - 13:56
One of the sessions I attended at Agile 2014 by Tricia […]
Categories: Companies

5 Tips for Accelerated Learning - Thu, 07/16/2015 - 10:19

I spent all of last year in Berlin, where I focused on learning the German language. After years learning different programming languages like Java, C#, Javascript and Ruby (not to mention all the tools, frameworks and libraries) and several years training and teaching I figured I could “eat my own dog food” and apply what I learnt about learning to a real language.

Enter to Learn stone signStone sign: Enter to Learn. Image take from flikr under the Creative Commons licence.

Since that year, I talked to numerous people impressed that I can speak fluent German after living in Berlin. They often ask me, how did I found my experience. This post is a good summary of what I found myself repeating. Firstly, if you really, really want to learn German, Berlin is probably not the best place since there are so many foreigners living there and the level of spoken English is ridiculously high. You can easily fall into hanging out with the English-speaking crowd, enjoy the city, and fail to pick up more than rudimentary German.

Although I have very specific tips for learning the German language, this is more focused on what helped me learn the most that I think applies to any subject.

1. Find different teachers

At the start of the year, I spent the first three months doing an immersive language course at the Goethe Institute. Over the two classes, I experienced four different teachers, each with their own style and emphasis on what is important to learn. Although I wished that I had spent less time with one of the teachers, I found their point of view was sometimes useful. Each teacher focused on different aspects and it made my learning all that richer.

Over the rest of the year, I found other avenues to teach me, guide me and give the feedback I needed to grow. If I had stuck with a single teacher, I would have missed out on a number of other valuable perspectives.

2. Have a goal, and keep focused on it

Unlike many European people, I was never bilingual as a child. Moving to England from Australia, I came to appreciate how useful a second language was by meeting many other bilingual people. Although I learned Japanese in school, I believe it is more important to have the ability to use it.As they say:

Use it, or lose it.

A whole year to learn a language was a once in a lifetime opportunity and my goal was to be fluent by the end of the year. I had a whole bunch of other personal reasons to learn German, but figured many things came into alignment and I would make the most of this opportunity.

I reminded myself throughout the year about my goal, and why it was important to me, and it helped me keep focus on the learning. It helped me in particular when the going got tough, and it will get tough!

3. Celebrate progress

After a year passed by, I met with some of my colleagues again who were impressed that I could now speak with them fluently in their native tongue. Although it’s easy to celebrate that final result, there were many times along the way that I wanted to give up because it was hard, and I felt frustrated that I felt like I wasn’t learning as fast I wanted to.

I was sharing a flat with a German, who knew that I was wanting to speak fluent German. Although he could speak English very well, he spoke only to me in German even if it would have been easier for him to communicate in English. I remember coming home one day, exasperatedly asking, “Can we just speak in English?!” His answer, “Nein!” (No, in German).

Although there were bad days, there were also good days and I made sure to sit back and acknowledge these small milestones, such as watching my first film in German with subtitles (and understanding most of it), completing my first German novel, and going to the Town Hall to register myself without speaking a word of English!

Each small step moves you towards your final goal, and celebrating progress will help you overcome the learning hurdles you experience along the way.

4. Vary your learning activities

One problem with a long-term learning goal, is that you will get bored and distracted. At the start of my year, I was naturally doing a lot of grammatical textbook exercises which was useful for the classroom. However I couldn’t see myself continuing to do just these exercises for the rest of the year. I wanted other ways to learn but would help me keep engaged. Therefore I combined learning German with other activities that I enjoyed, such as meeting with people (the German Stammtisch the language school organised was a good one), watching movies and reading books I liked in German (thanks library!), meeting with a tandem partner, and listening to the radio.

A friend gave me the book, “111 Orte in Berlin, die man gesehen haben muss” which roughly translates to, “111 must see places in Berlin.” The book has two pages for each place, one with a short description and the other with a picture and was perfect for dipping in and out. I could read about a place I wanted to visit, and because I lived in Berlin, could go and see what it was talking about. At the same time, it helped me deepen my vocabulary and help me experience the unique experiences Berlin had of offer.

Later in the year, I spent some time traveling around in Germany, where I did a number of tours in German. Each of these experiences kept the learning alive for me and I never grew bored about “learning German” because I was doing it at the same time as I was doing other activities I was enjoying.

5. Accept you’ll never be perfect

Early on in my career, I discovered the idea of the Beginner’s Mind (Shoshin). For me, part of this accepts that I do not, and cannot know everything and that means there are new things to learn. In learning German, I found that my vocabulary will never be as rich as it is in English because there are situations I have never found myself in.

A good example of this was talking to a friend of mine when we first worked in a German-speaking office. She told me this story:

Although I studied German at school and was very fluent, I was shocked the first time that I was running a project kickoff for a German-speaking client. Not only was I learning new German words for the domain (transportation) but I was also learning new German words for technology terms I had taken for granted.

Our experiences shape who we are, and we cannot possibly be experts at everything, and that’s perfectly fine. I found it was more productive to focus on getting better than worrying about how close to mastery I was.


After years of coaching, teaching and training technology, I have many techniques that I consider useful as learning strategies. I found last year was a great opportunity to try applying some of them to a completely different skill and see how far I could go. Happily, it seemed to have worked.

I hope you found this article useful and that you will find these tips above useful. In summary, try to:

  1. Find different teachers
  2. Have a goal, and keep focused on it
  3. Celebrate progress
  4. Vary your learning activities
  5. Accept you’ll never be perfect

What other learning strategies do you find work for you?

Categories: Blogs

Neo4j: The football transfers graph

Mark Needham - Thu, 07/16/2015 - 08:40

Given we’re still in pre season transfer madness as far as European football is concerned I thought it’d be interesting to put together a football transfers graph to see whether there are any interesting insights to be had.

It took me a while to find an appropriate source but I eventually came across which contains transfers going back at least as far as the start of the Premier League in 1992.

I wrote a quick Python script to create a CSV file of all the transfers. This is what the file looks like:

$ head -n 10 data/transfers.csv
Martin Keown,Everton,29,Arsenal FC,11,"2,10 Mill. £",1992-1993
John Jensen,Bröndby IF,206,Arsenal FC,11,"1,12 Mill. £",1992-1993
Alan Miller,Birmingham,337,Arsenal FC,11,,1992-1993
Jim Will,Sheffield Utd.,350,Arsenal FC,11,,1992-1993
David Rocastle,Arsenal FC,11,Leeds,399,"1,68 Mill. £",1992-1993
Perry Groves,Arsenal FC,11,Southampton FC,180,595 Th. £,1992-1993
Ty Gooden,Arsenal FC,11,Wycombe Wand.,2805,?,1992-1993
Geraint Williams,Derby,22,Ipswich Town,677,525 Th. £,1992-1993
Jason Winters,Chelsea U21,9250,Ipswich Town,677,?,1992-1993

I’m going to create the following graph and then we’ll write some queries which explore chains of transfers involving players and clubs.

2015 07 15 07 28 11

I wrote a few import scripts using Neo4j’s LOAD CSV command, having set up the appropriate indexes first:

create index on :Team(id);
create index on :Season(name);
create index on :Transfer(description);
create index on :Player(name);
// teams
load csv with headers from "file:///Users/markneedham/projects/football-transfers/data/teams.csv" as row
merge (team:Team {id: toint(row.team_id)})
on create set =;
// seasons
load csv with headers from "file:///Users/markneedham/projects/football-transfers/data/transfers.csv" as row
merge (season:Season {name: row.season})
ON CREATE SET season.starts =  toint(split(, "-")[0]);
// players
load csv with headers from "file:///Users/markneedham/projects/football-transfers/data/transfers.csv" as row
merge (player:Player {name: row.player});
// transfers
load csv with headers from "file:///Users/markneedham/projects/football-transfers/data/transfers.csv" as row
match (from:Team {id: toint(row.from_team_id)})
match (to:Team {id: toint(row.to_team_id)})
match (season:Season {name: row.season})
match (player:Player {name: row.player})
merge (transfer:Transfer {description: row.player + " from " + + " to " +})
merge (transfer)-[:FROM_TEAM]->(from)
merge (transfer)-[:TO_TEAM]->(to)
merge (transfer)-[:IN_SEASON]->(season)
merge (transfer)-[:PLAYER]->(player);
// connect transfers
match (season)<-[:IN_SEASON]-(transfer:Transfer)-[:PLAYER]->(player)
WITH player, season, transfer
ORDER BY, season.starts
WITH player, COLLECT({s: season, t: transfer}) AS transfers
UNWIND range(0, length(transfers)-2) AS idx
WITH player, transfers[idx] AS t1, transfers[idx +1] AS t2
WITH player, t1.t AS t1, t2.t AS t2
MERGE (t1)-[:NEXT]->(t2);

All the files and scripts are on this gist if you want to play around with the data. The only thing you’ll need to change is the file path on each of the ‘LOAD CSV’ lines.

The ‘connect transfers’ query is a bit more complicated than the others – in that one we’re first ordering the transfers in ascending order grouped by player and then creating a linked list of a player’s transfers.

Now that we’ve got the data loaded let’s find out which player was transferred the most:

match path = (:Transfer)-[:NEXT*0..]->(transfer:Transfer)
where NOT (transfer)-[:NEXT]->()
RETURN path 
Graph  22

Which other players have moved teams frequently?

match path = (first:Transfer)-[:NEXT*0..]->(transfer:Transfer),
where NOT ((transfer)-[:NEXT]->()) AND NOT ((first)<-[:NEXT]-())
RETURN, LENGTH(path) AS numberOfTransfers 
ORDER BY numberOfTransfers DESC
==> +--------------------------------------+
==> |      | numberOfTransfers |
==> +--------------------------------------+
==> | "Craig Bellamy"  | 7                 |
==> | "David Unsworth" | 6                 |
==> | "Andrew Cole"    | 6                 |
==> | "Peter Crouch"   | 6                 |
==> | "Les Ferdinand"  | 5                 |
==> | "Kevin Phillips" | 5                 |
==> | "Mark Hughes"    | 5                 |
==> | "Tommy Wright"   | 4                 |
==> | "Carl Tiler"     | 4                 |
==> | "Don Hutchison"  | 4                 |
==> +--------------------------------------+
==> 10 rows

What are the most frequent combinations of clubs involved in transfers?

match (from)<-[:FROM_TEAM]-(t:Transfer)-[:TO_TEAM]->(to), (t)-[:PLAYER]->(p)
RETURN,, COUNT(*) AS times, COLLECT( AS players
==> +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> |           |               | times | players                                                                                                                                                                                                    |
==> +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> | "West Ham United"   | "Queens Park Rangers" | 13    | ["Keith Rowland","Iain Dowie","Tim Breacker","Ludek Miklosko","Bertie Brayley","Terrell Forbes","Steve Lomas","Hogan Ephraim","Nigel Quashie","Danny Gabbidon","Kieron Dyer","Robert Green","Gary O'Neil"] |
==> | "Tottenham Hotspur" | "Portsmouth FC"       | 12    | ["Paul Walsh","Andy Turner","Rory Allen","Justin Edinburgh","Tim Sherwood","Teddy Sheringham","Noé Pamarot","Pedro Mendes","Sean Davis","Jermain Defoe","Younès Kaboul","Kevin-Prince Boateng"]            |
==> | "Liverpool FC"      | "West Ham United"     | 12    | ["Julian Dicks","David Burrows","Mike Marsh","Don Hutchison","Neil Ruddock","Titi Camara","Rob Jones","Rigobert Song","Craig Bellamy","Joe Cole","Andy Carroll","Stewart Downing"]                         |
==> | "Manchester United" | "Everton FC"          | 9     | ["Andrey Kanchelskis","John O'Kane","Jesper Blomqvist","Phil Neville","Tim Howard","Louis Saha","Darron Gibson","Sam Byrne","Tom Cleverley"]                                                               |
==> | "Newcastle United"  | "West Ham United"     | 9     | ["Paul Kitson","Shaka Hislop","Stuart Pearce","Wayne Quinn","Lee Bowyer","Kieron Dyer","Scott Parker","Nolberto Solano","Kevin Nolan"]                                                                     |
==> | "Blackburn Rovers"  | "Leicester City"      | 9     | ["Steve Agnew","Tim Flowers","Callum Davidson","John Curtis","Keith Gillespie","Craig Hignett","Nils-Eric Johansson","Bruno Berner","Paul Gallagher"]                                                      |
==> | "Chelsea FC"        | "Southampton FC"      | 8     | ["Ken Monkou","Kerry Dixon","Neil Shipperley","Mark Hughes","Paul Hughes","Graeme Le Saux","Jack Cork","Ryan Bertrand"]                                                                                    |
==> | "Birmingham City"   | "Coventry City"       | 8     | ["David Rennie","John Gayle","Liam Daish","Gary Breen","Stern John","Julian Gray","Lee Carsley","Gary McSheffrey"]                                                                                         |
==> | "Southampton FC"    | "Fulham FC"           | 8     | ["Micky Adams","Kevin Moore","Terry Hurlock","Maik Taylor","Alan Neilson","Luís Boa Morte","Antti Niemi","Chris Baird"]                                                                                    |
==> | "Portsmouth FC"     | "Stoke City"          | 8     | ["Kevin Harper","Lewis Buxton","Anthony Pulis","Vincent Péricard","Asmir Begovic","Marc Wilson","Elliot Wheeler","Alex Grant"]                                                                             |
==> +------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> 10 rows

Are there ever situations where players get transferred in both directions?

match (from)<-[:FROM_TEAM]-(t:Transfer)-[:TO_TEAM]->(to), (t)-[:PLAYER]->(player)
where id(from) < id(to)
WITH from, to, COUNT(*) AS times, COLLECT( AS players
match (to)<-[:FROM_TEAM]-(t:Transfer)-[:TO_TEAM]->(from), (t)-[:PLAYER]->(player)
RETURN,, times, COUNT(*) as otherWayTimes, players, COLLECT( AS otherWayPlayers
ORDER BY times + otherWayTimes DESC
==> +-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> |           |               | times | otherWayTimes | players                                                                                                                                                                                                    | otherWayPlayers                                                                                                                                                                    |
==> +-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
==> | "Tottenham Hotspur" | "Portsmouth FC"       | 12    | 5             | ["Paul Walsh","Andy Turner","Rory Allen","Justin Edinburgh","Tim Sherwood","Teddy Sheringham","Noé Pamarot","Pedro Mendes","Sean Davis","Jermain Defoe","Younès Kaboul","Kevin-Prince Boateng"]            | ["Jermain Defoe","Niko Kranjcar","Younès Kaboul","Peter Crouch","Darren Anderton"]                                                                                                 |
==> | "West Ham United"   | "Liverpool FC"        | 4     | 12            | ["Julian Dicks","Daniel Sjölund","Yossi Benayoun","Javier Mascherano"]                                                                                                                                     | ["Stewart Downing","Andy Carroll","Joe Cole","Craig Bellamy","Rigobert Song","Titi Camara","Rob Jones","Neil Ruddock","Don Hutchison","Julian Dicks","Mike Marsh","David Burrows"] |
==> | "West Ham United"   | "Queens Park Rangers" | 13    | 2             | ["Keith Rowland","Iain Dowie","Tim Breacker","Ludek Miklosko","Bertie Brayley","Terrell Forbes","Steve Lomas","Hogan Ephraim","Nigel Quashie","Danny Gabbidon","Kieron Dyer","Robert Green","Gary O'Neil"] | ["Andy Impey","Trevor Sinclair"]                                                                                                                                                   |
==> | "West Ham United"   | "Tottenham Hotspur"   | 5     | 8             | ["Jermain Defoe","Frédéric Kanouté","Michael Carrick","Jimmy Walker","Scott Parker"]                                                                                                                       | ["Sergiy Rebrov","Mauricio Taricco","Calum Davenport","Les Ferdinand","Matthew Etherington","Bobby Zamora","Ilie Dumitrescu","Mark Robson"]                                        |
==> | "West Ham United"   | "Portsmouth FC"       | 8     | 5             | ["Martin Allen","Adrian Whitbread","Marc Keller","Svetoslav Todorov","Hayden Foxe","Shaka Hislop","Sébastien Schemmel","Hayden Mullins"]                                                                   | ["Stephen Henderson","Teddy Sheringham","Shaka Hislop","Marc Keller","Lee Chapman"]                                                                                                |
==> | "Newcastle United"  | "West Ham United"     | 9     | 3             | ["Paul Kitson","Shaka Hislop","Stuart Pearce","Wayne Quinn","Lee Bowyer","Kieron Dyer","Scott Parker","Nolberto Solano","Kevin Nolan"]                                                                     | ["Demba Ba","Lee Bowyer","David Terrier"]                                                                                                                                          |
==> | "Birmingham City"   | "Coventry City"       | 8     | 4             | ["David Rennie","John Gayle","Liam Daish","Gary Breen","Stern John","Julian Gray","Lee Carsley","Gary McSheffrey"]                                                                                         | ["Scott Dann","David Burrows","Peter Ndlovu","David Smith"]                                                                                                                        |
==> | "Manchester City"   | "Portsmouth FC"       | 8     | 4             | ["Paul Walsh","Carl Griffiths","Fitzroy Simpson","Eyal Berkovic","David James","Andrew Cole","Sylvain Distin","Tal Ben Haim"]                                                                              | ["Benjani","Gerry Creaney","Kit Symons","Paul Walsh"]                                                                                                                              |
==> | "Blackburn Rovers"  | "Southampton FC"      | 5     | 6             | ["David Speedie","Stuart Ripley","James Beattie","Kevin Davies","Zak Jones"]                                                                                                                               | ["Zak Jones","Egil Östenstad","Kevin Davies","Alan Shearer","Jeff Kenna","Tim Flowers"]                                                                                            |
==> | "AFC Bournemouth"   | "West Ham United"     | 3     | 8             | ["Keith Rowland","Paul Mitchell","Scott Mean"]                                                                                                                                                             | ["Steve Jones","Matt Holland","Mohammed Berthé","Scott Mean","Paul Mitchell","Jamie Victory","Mark Watson","Stephen Purches"]                                                      |
==> +-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Any players who go back to the same club they were at previously?

match (player:Player)<-[:PLAYER]-(t1:Transfer)-[:FROM_TEAM]->(from)<-[:TO_TEAM]-(t2:Transfer)-[:FROM_TEAM]->(to),
      (t2)-[:PLAYER]->(player), (t1)-[:TO_TEAM]->(to)
WHERE ID(to) < ID(from)
WITH player, COLLECT([, " ⥄ ",]) AS teams
       REDUCE(acc = [], item in teams | acc  + REDUCE(acc2 = "", i in item | acc2 + i)) AS thereAndBack
==> +-------------------------------------------------------------------------------------+
==> |       | thereAndBack                                                    |
==> +-------------------------------------------------------------------------------------+
==> | "Mark Stein"      | ["Stoke City ⥄ Chelsea FC","Ipswich Town ⥄ Chelsea FC"]         |
==> | "Peter Beagrie"   | ["Bradford City ⥄ Everton FC","Bradford City ⥄ Wigan Athletic"] |
==> | "Richard Dryden"  | ["Southampton FC ⥄ Stoke City","Southampton FC ⥄ Swindon Town"] |
==> | "Robbie Elliott"  | ["Bolton Wanderers ⥄ Newcastle United"]                         |
==> | "Elliot Grandin"  | ["Blackpool FC ⥄ Crystal Palace"]                               |
==> | "Robert Fleck"    | ["Chelsea FC ⥄ Norwich City"]                                   |
==> | "Paul Walsh"      | ["Portsmouth FC ⥄ Manchester City"]                             |
==> | "Rick Holden"     | ["Manchester City ⥄ Oldham Athletic"]                           |
==> | "Gary McAllister" | ["Liverpool FC ⥄ Coventry City"]                                |
==> | "Lee Bowyer"      | ["West Ham United ⥄ Newcastle United"]                          |
==> +-------------------------------------------------------------------------------------+

That’s all I’ve got for now – if you can think of any other interesting avenues to explore let me know and I’ll take a look.

Categories: Blogs

Enterprise Services Planning Management Summit

A new conference! A new format! A new movement! London 28 September

The Enterprise Services Planning Management Summit is designed for managers in all types of professional services to come together and share their challenges managing modern 21st Century business in a complex world of disruptive change and ever shifting customer demands and expectations.

read more

Categories: Companies

Team Kanban Practitioner

Lean Kanban University is introducing a new entry level Kanban class for Team Kanban together with a certification and professional credential, TKP, Team Kanban Practitioner. This new class becomes the entry level on the "alternative path to agility" and reflects the market reality that most Kanban starts shallow and at the team level.

read more

Categories: Companies

Kanban - the alternative path to agility

The Kanban Method was conceived as an alternative path to agility - as a means to improve responsiveness and adaptability without any significant revolution or reorganization in your way or working or political structure of your business. Lean Kanban University has recently introduced a series of training classes developed and evolved from older, tried and tested curriculum to ease adoption of Kanban and communicate the full scope and scale of what is possible when you fully embrace Kanban as a way to manage your modern professional services business.

read more

Categories: Companies

Pitfall of Scrum: Problem-Solving in the Daily Scrum

Learn more about our Scrum and Agile training sessions on

The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised. Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested. The ScrumMaster facilitates this meeting to keep it on track. The Daily Scrum is timeboxed to a maximum of 15 minutes, but often should be even less. With a good physical task board, a Daily Scrum can often be done in less than a minute simply by each team member pointing at the pieces of work they are working on.

From the Scrum Guide:

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

In other words, don’t have those discussions during the Daily Scrum! The Daily Scrum is essential to creating transparency and implementing the Scrum value of Openness. The three questions of the Daily Scrum are effectively:

  1. What did I do since the last time we checked in as a team?
  2. What am I planning to do before the next check in time?
  3. What impediments, if any, are preventing us from getting our work done?

Each member of the team takes a turn and answers those three questions. This doesn’t have to be completely stilted, but it should be Focused (another value of Scrum) and efficient so that the need for other meetings is minimized. Accomplishing this takes some practice. The ScrumMaster helps the team to keep the timebox, but at first, a team might have challenges with this.

Struggling with the Daily Scrum

There are a some common reasons that a team might struggle with wanting to problem solve in the Daily Scrum:

  • One team member doesn’t know what to do next and it devolves into re-planning right there and then. A quick suggestion or two is probably fine, but it is a very steep slippery slope. A team can easily get into the habit of always doing this! The ScrumMaster needs to be vigilant about recommending that the discussion be taken up after the Daily Scrum is concluded in order to avoid this pitfall. This suggestion will be common when a team is first starting out.
  • One person mentions an impediment that someone else knows how to solve… and a third person has a different idea of solving it. In this situation it is much better for interested team members to just simply indicate “I have an idea for that,” and let the Daily Scrum continue. Then after the Daily Scrum those people have a quick discussion. This avoids wasting the time of everyone on the team with something that is only interesting to a few.
  • An individual doesn’t seem to have anything to report and other team members try to elicit more information. This should really be something that the ScrumMaster or the team’s coach should take up with the individual. It may be that there is an impediment that the person is uncomfortable sharing openly with the whole team. There is a subtle pitfall that may be revealed here: that the team does not have the safety to self-organize.
  • Disagreement about what to do next. This type of problem is the hardest to deal with because many people will feel that disagreements need to be resolved before any action can be taken. A good ScrumMaster will actually encourage competing ideas to be attempted. Learn by doing instead of by argument and analysis. This is the fundamental shift in culture that Scrum is attempting to put in place: an empirical approach to work rather than a defined approach.

Just beware: yet another pitfall (although not common) is to decide that the Daily Scrum shouldn’t be daily because it is taking so long. Unfortunately, making this change will often just make the meetings even longer until they devolve back into weekly status meetings reporting to the team lead!!! Remember that it’s not Scrum anymore if your team doesn’t meet together daily.

Ultimately, if a team is struggling with the Daily Scrum in any way, this is a valid topic for discussion in the Sprint Retrospective.

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.

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!

The post Pitfall of Scrum: Problem-Solving in the Daily Scrum appeared first on Agile Advice.

Categories: Blogs

You Asked, the Agile Aficionados Answered

Rally Agile Blog - Wed, 07/15/2015 - 14:00

Getting onboard with Agile methods across your organization is no small task. To do it well requires knowledge, culture change, and practice — lots of practice — at all levels.

Rally is fortunate to have some of the most experienced practitioners in the industry. Their broad experience working onsite with customers and their deep knowledge of Agile practices, organizational culture, and human behavior only excites in them a deeper curiosity and eagerness to learn. As you can imagine, this makes them great advice-givers and storytellers!

Recently we assembled a few of these Agile aficionados (Agile Coach Tamara Nation, Transformation Consultant Eric Willeke, and Services Product Manager Ronica Roth) to respond to some of your toughest Agile questions with their advice and stories. You can listen to the whole terrific webcast of their conversation here, but below we share a few things we learned from their chat.

You Can’t Innovate Until You Can Execute

ERIC: A lot of the language I'm hearing with executives and business partners around the IT industry is all about, “We need to innovate more. We need to do more of this, more of that.” I fear that people are losing sight of the need to actually be able to implement those ideas and operate the businesses effectively once those innovations are brought to market. A lot of the focus I help organizations drive early in their transformation is to stabilize your implementation capability. Stabilize that execution organization that's able to build those new ideas, able to bring them to market. Then use that as the base from which to start to launch innovation and start to disrupt the markets you're in, and move the business in the places you want to go.

TAMARA: I see a similar trend, especially when I'm working with really large organizations that have organizationally institutionalized impediments. You know those silos that we're always talking about? I feel like I've been in a lot of conversations recently where IT and development folks are pointing the fingers at “the business” … when, really, we need to be able to deliver predictably. We need to be able to deliver quality products.

Agile Ops: Upfront Architecture or Emergent Design?

ERIC: At least in my mind, the real purpose of architecture is to ensure that an organization is in a position to take care of future opportunities, be ready to seize those and have the technical infrastructure, the technical platforms to put the company where it needs to be in the future.

One of the things that architects need to be good at is the capability to see around the corners, to anticipate that beyond the current need, beyond what we're building now, what are we going to be faced with on this platform, and in this environment, and in this market in the future?

Sometimes that means overinvesting in flexibility early in a platform. Sometimes that means closing a platform so that you can milk every last penny out of it at the lowest operational cost. But first and foremost, it's to help take those needs and convey them into the organization in a form that allows you to articulate the trade-offs and steer the decisions that need to be made by the teams moment to moment.

The flipside of that, and this is where the emergent architecture aspect and emergent design aspect comes from, is most architecture groups can't move at the speed of development.

Once you achieve that execution engine, once you have a development organization that can push out high quality software week after week, quarter after quarter, nobody can predictably say, "Here's what design you need." We want to ensure that the development organization always has a direction that they can go that they know they can implement at full speed and not cause things to break, not go off the rails and cause huge operational costs or poor flexibility or challenges down the line. That is the tension and the balance that we're looking at when we talk about the intersection of intentional architecture and emergent design.

A lot of the ideas around service-oriented architecture and now the DevOps microservices mindset are really taking balance and pushing it to the extreme where it's in smaller and smaller groups that have both skill sets and both mindsets and decentralizing that decision-making around architecture. It's a continuum, but it's also a very careful balancing of those two forces of predicting the future and moving at full speed today.

TAMARA: I think the other thing I look for, Eric, is, can we start to build a group of people who can make good architectural decisions? I 100 percent agree with that paradigm. It's really systems thinking. How can we set up an environment where our teams can be successful? What are the guardrails? What are the performance ‘ilities’? What are the things that this system needs to be able to do and how can I create architects of the future, for instance? How do we have that architectural skill set in each of our Agile teams?

ERIC: I like what you said there, Tamara, because it really indicates that we all think that we're past the day of fire-and-forget architectures. It's no longer at a point where you can define "the architecture" and then move on with life. The people need to be embedded. They need to be engaged throughout the development process and probably into the operations stage of any major platform. It's not an up-front activity by any means anymore.

How Big Room Planning Pays for Itself

RONICA: I know you guys have seen the release planning or big room planning where we bring everyone in a delivery group or release train together to plan a quarter's worth of work. What are some experiences you guys have had recently where that event has had a radical impact on a group's ability to execute, or what resistance have you seen?

TAMARA: I think the number one piece of resistance I see is about, "Well, I can't afford it, we're too busy. People need to keep working, so I can't possibly get everyone together to do this big planning exercise." This first time is scary because the upfront investment looks big. The downstream benefit's harder to see until you've actually executed the event.

ERIC: The same thing for me. Cost, cost, and cost are always the first, second, and third complaints. Generally it's travel costs, followed by the cost of the time of the people, and then the cost of distraction and planning are the three types of costs that I hear people concerned about.

TAMARA: Have I ever seen a time where bringing everyone together and talking about our work and our priorities didn't yield a significant either cost savings or we were able to see a risk and mitigate it earlier in the process? I can think of one example with a particular Salesforce implementation. That's a lot of configuration, those types of implementations. They realized, "Oh, we're configuring the exact wrong module. [laughs] We'll never use that one, so why waste our time doing that?" That was $100K savings from a real quick conversation. I saw it happen in front of me. I don't think you could even monetize the value from bringing those people together.

ERIC: I don't think I've ever seen one where there wasn't at least one directly attributable learning or discovery that didn't pay for the cost of the event in terms of travel and logistics and everything else. That doesn't even include the real outcome of the big-room planning, which is to create an organization and a group that's ready to deliver that plan. Like the classic saying that "planning is invaluable, the plan itself useless." These groups come together and the people that are excluded, in my experience, you can noticeably see over the next 10 to 12 weeks that they're at a distinct disadvantage in their ability to contribute compared to the people that were in the room.

Planning and Continuous Delivery Are Not Mutually Exclusive

RONICA: Why a release train and a continuous delivery model? If we're doing continuous delivery, why do this by quarterly plan, that look-ahead?

TAMARA: The whole planning event is designed around, What should we be working on? What's the next right thing to do, and what do we need to know to get that done?

ERIC: Yeah. A lot of us, I think, recently, have been reading Patrick Lencioni's new book, The Advantage. In all of his language about organizational help, he really drives those four principles all back to clarity and providing intense clarity among the organization about, What are the goals and how are we going to accomplish them? Beyond what that book offers, the big room plan, to me, is such an amazing opportunity to get a much larger group than you normally would be able to enrolled into the same clarity of intent that at least we're all operating off the same view of reality. We believe we're all moving to the same direction. Sharing that clarity and sharing that alignment is so powerful for the day-to-day execution that needs to follow starting, generally, the day after planning, like the Monday after planning.

TAMARA: The continuous delivery is an important part of that. Things are moving quickly, the pace and people's expectations on our ability to deliver new things, respond to changes, and fix defects. I was listening to a story from one our colleagues in China about how he submitted a defect through Twitter — the Chinese equivalent of Twitter. He got a response within four hours that they'd received the defect, and he got a notification 10 hours later that it was fixed. I thought, "Wow." Once things are identified, we know that's a priority and respond quickly, that's what continuous delivery's all about.

ERIC: it's so critical for people to remember that, yes, there are still enterprises that are in an annual delivery cycle and maybe a twice-a-year delivery cycle. Something like SAFe and the midrange planning helps them get down to a 10-week cycle. But I think it's gotten to the point where we all assume, of course you're going to deliver faster than that if you can and it makes sense for your business. We forget to say, "No, there's nothing that limits you to deliver once a quarter. There's nothing in SAFe or any of the other larger scaling models that say you can only deliver in your planning boundaries." I know multiple companies that have gotten down to where they can essentially deliver on-demand whenever they have something worth delivering. They do that within the construct of SAFe. They do that as part of their normal sprint planning, is to say, "Yeah, I can create this feature, and this feature will be done. We'll get them through this cycle, and let's go and share those next Thursday, before the end of the sprint."

Agile Metrics: What to Measure, What to Ignore

RONICA: Of course, there are two sides to metrics. One is, How do we measure success of the Agile adoption? Then, of course, there is, What are the good Agile metrics that help us know whether our projects or programs or delivery groups are being successful? What metrics might you suggest avoiding? Talk to me about some of your favorite measures.

TAMARA: I think about cycle time and lead time as the most important metric, because it's going to touch all parts of your business. If you have a really good understanding of how long something takes from the time somebody has an idea or submits a defect, to when you can get that idea into production, that's going to help you uncover all of the different areas where you have bottlenecks, where there are transparency issues inside of your organization.

Interestingly enough, I don't know if Eric's at this place, in terms of Agile adoption metrics, I talk about that a lot less, because I feel like Agile's really's crossed the chasm. I'm a little less concerned about their adoption and more on whether there's real, tangible business impacts we're having.

ERIC: Yeah, I've actually taken, maybe, even a step further beyond that and I'm at the point of saying, "I actively discourage centers of excellence and transformation coalitions from having percent-of-adoption type metrics." I find if you start to look at something like the percent of teams that have adopted Scrum or something like that, you actually drive worse behaviors in the organization once you hit a certain tipping point. Because the push is to get people to where you can give them the stamp of Scrum approval or the stamp of, "This team is Agile," rather than focusing on the improvement journey or the business impact that's so much more valuable.

The first-order metric I'm usually looking at is lead time, from an execution perspective: what's the impact? Is it reflected in the share prices? Is it reflected in the large business programs that are using Agile techniques to show more capability and more market presence than the ones who aren't? Then work back to, "What are the factors that drive it?" I think sustainable shortest lead time is a huge, almost number-one goal to get that feature delivery and then cycle from idea identification, opportunity identification, all the way through to business implementation and revenue recognition and can you shrink that time.

That gives you the ability to respond to the market faster. That gives you the ability to learn faster. Then once you get inside of that, almost every metric I use is situational. Is it indicative of a specific impediment or bottleneck that we're trying to resolve in an organization? If so, let's wrap some evidence around it and find the right metric that illustrates what we're trying to do and brings the impact of the problems to some sort of visibility, work to resolve it. Then keep capturing the data.

TAMARA: I feel that there is an addiction to metrics inside of organizations, particularly technologies companies where they feel like, "We're sitting on all this data. We should be able to have really great metrics." I feel like I see so many executives really locked into their red, yellow, green dashboards and that's what they're using to sense and understand where their business's such a temptation to fall back into, "I want the cold, hard facts. I want the numbers," when we all know that metrics can be shaded in either direction.

ERIC: I had a senior leader who has, roughly, 35 teams under his purview. A month or two ago he actually came out to Rally and visited our steering. But while he was in town he actually hung out with two of his development teams that were located in another office. He just took the teams to lunch. None of the management in the middle was present. There was probably a two- or three-layer power gap. He just went to lunch and he came away with a very different understanding and perspective over what some of the relationship challenges were among different parts of the organization. None of that ever finds its way up through the reports or the PowerPoint decks or the executive status boards or anything else that you're going to run into.

Listen to the whole conversation, and sign up for our August webinar, “Next Level Agile,” with Rally VP of Products Ryan Polk.

Categories: Companies

Python: UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xe2 in position 0: ordinal not in range(128)

Mark Needham - Wed, 07/15/2015 - 08:20

I was recently doing some text scrubbing and had difficulty working out how to remove the ‘†’ character from strings.

e.g. I had a string like this:

>>> u'foo †'
u'foo \u2020'

I wanted to get rid of the ‘†’ character and then strip any trailing spaces so I’d end up with the string ‘foo’. I tried to do this in one call to ‘replace':

>>> u'foo †'.replace(" †", "")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 1: ordinal not in range(128)

It took me a while to work out that “† ” was being treated as ASCII rather than UTF-8. Let’s fix that:

>>> u'foo †'.replace(u' †', "")

I think the following call to unicode, which I’ve written about before, is equivalent:

>>> u'foo †'.replace(unicode(' †', "utf-8"), "")

Now back to the scrubbing!

Categories: Blogs

Does This Fizz Good?

FSGD (pronounced Fizz Good) is a thinking tool that LeanKit created to shape how we plan our work to get things done and provide value to our customers faster. FSGD is an acronym comprised of four equal parts: Frequent, Small, Good, and Decoupled. We think of it as simply a concise restatement of Lean principles, […]

The post Does This Fizz Good? appeared first on Blog | LeanKit.

Categories: Companies

Knowledge Sharing

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