XP2016 – Day 1 – XP at Scale – Elisabeth Hendrickson


Some notes from the opening Keynote at XP2016 from Elisabeth Hendrickson.

Some Principles at Pivotal:

  • Separate what & how
  • Sustainable Pace
  • Automate
  • Ensure fast feedback
  • Team Own Quality
  • Reflect, Adapt, Experiment

Pairing is really important. Do it as part of your recruitment.

Scaling problems are highlighted in the analogy “Tragedy of the Commons”

“Without intervention work rolls down hill!” Sometimes teams need to help and guidance.

Why isn’t XP practiced widely?

Some more Pivotal Principles…..

  • Use Conyway’s law to your advantage
  • Teams own things
  • Team that owns that thing tests that thing
  • Relentless feedback cycles
  • Increase Empathy
  • Collaborate, reduce Hand Offs

Empathy is our advantage….

“Don’t do it for me, do it WITH me”

If Field engineers encounter problems they are encouraged to pair with the team to get it resolved. Pair all the time with everyone!

Some new techniques Pivotal have applied……

  • Big team standup
  • Cross team retros
  • Allocations/Rotations
  • Cross Team Pairing
  • Regular Exploratory Testing

Some new roles at Pivotal…

  • Engineering Director / Leadership Liaison
  • Product Director
  • Product Manager

Closing comment…

Excellent Keynote!

I will be blogging throughout the conference. You can check out my previous post about Dan North’s workshop here

XP 2016 – Dan North – Software Faster


Today I attended Dan North’s @tastapod Workshop “Software Faster” at XP2016.

Here are a few things I learnt:

Learning #1

What is the goal of agile? Predictability

Learning #2

5 Steps in an Organisatonal Change journey:

  1. People Break
  2. Tools Break
  3. Governance Breaks
  4. Money Breaks
  5. Organisation Breaks

Typically alot of Agile Transformations focus on stages 1 and 2. They struggle to move to stages 3, 4 & 5. Often there is a conflict between people at each stage. In many cases stages 3, 4 & 5 are controlled by the “Frozen Middle”; Middle Management. Real breakthroughs only occur once issues are tackled at the later stages. Dans tip to change these stages is to “Use the system to change the system”

More: https://www.amazon.co.uk/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521

Learning #3

Marginal Gains will focus on optimising the existing system. For example if we focus on a 10% improvement we won’t rip up the rule book. For example, people might just starting working longer hours or doing over time. However if we focus on a 50% or higher improvement it will often make us think more fundamentally about our currently processes.

Learning #4

The point of Agile is not to create Software, it is a tool to deliver business capability.

Learning #5

The Goal of software is to:

“Minimise lead time to Business Impact.”

Lead time defined as:

“Having a need to having a need met”

It is easy to improve Lead time once or twice in isolation but it’s really hard to increase lead time “Sustainably”

When does the lead time clock start? As soon as you make a commitment to the person who requested it.

Can you measure lead time if you cannot measure business impact? No.

The big challenge is that measuring business impact is hard! Often teams use proxies such as Story Points rather than genuine impact: Number of users, Profit etc.

If you just focus on Lead Time it will lead to local optimisations.

More: https://dannorth.net/2013/07/05/are-we-nearly-there-yet/

Learning #6

Definition of a stakeholder: “People who’s lives you touch”

Learning #7

A good facilitation technique is to use the analogy of travelling between islands to explain the days agenda.

“Today we will start on Organisation Island, the swim across to Legacy Land, then drive to Core City and finish at the Planning Plateau.”

Learning #8

Three Ages Model can be used to explore where an organisation is:

Age 1 = Explore

Age 2 = Stabalise

Age 3 = Commoditisation

Often Organizations will misuse the ages. For example: try to commoditise testing by offshoring when it is an inherently exploratory activity.

More: https://www.slideshare.net/mobile/AdrianTreacy/dan-north-embracinguncertaintyv3

Leaning #9

PARC Model

More: https://www.amazon.co.uk/Modern-Firm-Organizational-Performance-Management/dp/0198293755

Learning #10

Apply “training from the back of the room” Encourage the attendees to teach each other. Example: In the next 3 minutes put together a pitch to explain what the PARC model is. At the end you will present this to another group”

Here is a group teaching each other:

More: https://www.amazon.co.uk/dp/0787996629/ref=cm_sw_r_cp_api_rshrxbDSR808Y

Learning #11

Value Stream Mapping Tips:

  • It’s easy
  • Get the real people who do the process involved
  • Don’t worry about rounding numbers
  • Make it viable

“Become less efficient to improve flow. Introduce sub optimisation.”

More: https://www.amazon.co.uk/dp/1935401009/ref=cm_sw_r_cp_api_6HhrxbNF4G6C6

Learning #12

Focus on reduction of Value at Risk(VAR) by working incrementally.

More: https://en.m.wikipedia.org/wiki/Value_at_risk

Learning #13

Dan finished the session playing a game called Taboo. Each person had to create a taboo card and then we played the game in groups.

This was an excellent way to reinforce the learning. Also another great example of “Training from the back of the room”

More: https://en.m.wikipedia.org/wiki/Taboo_(game)

Thanks Dan for a great day. Now onto post workshop drinks!

Pedestrian Crossings, Continuous Integration and Culture



You have just arrived into a new country, checked into your hotel and ready to head out exploring the area. Soon after leaving the hotel you will face your first challenge; the Pedestrian Crossing.

I’ve been lucky to visit a few different countries and not so lucky to experience some of the world’s wildest Pedestrian Crossings (Could make a great TV Show!). I live in the UK where Pedestrian Crossings are, at least to me, well signposted and generally observed both by pedestrians and drivers(with exceptions).Across the rest of Europe you’ll find experiences, in particular Italy. My strategy when i visit; Step out onto the pedestrian crossing, hope the driver notices you and stops, if he doesn’t get ready to run! Seems like i’m not alone! Other parts of the world such as India, Thailand, Vietnam introduce other examples of even riskier behaviour to cross the street.

Japan is one of the most fascinating countries i’ve visited. Incredible cities, beautiful countryside and very obedient pedestrians. Late one night, at around 3am, i was returning to my hotel. The roads were empty and not a vehicle in sight. Regardless to the apparent lack of danger, if the “Wait” sign was shown, pedestrians did not cross.


Pedestrian Crossings and Culture

As you travel the world you realise culture has a huge impact on pedestrian behaviour. An international research team did a study into the impact of Culture; Different risk thresholds in pedestrian road crossing behaviour: A comparison of French and Japanese approaches.

“The group set up observations posts at various crossings in the French city of Strasbourg and the Japanese city of Inuyama. The results were both clear and striking. At the legal crossing in Strasbourg, France, about 67 percent of pedestrians crossed against the red light. Only 7 percent of walkers in Inuyama did the same. At the unmarked crossing, the researchers measured how much time between cars a pedestrian needed before deciding to walk. In Strasbourg that time clocked in at 9 seconds, on average; in Inuyama, walkers felt free from risk at 16-second gaps.”

These findings match my anecdotal experience across Europe and in Japan.

Continuous Integration

After reflecting on a near death experience at one crossing in Bangkok recently, Continuous Integration came to mind. Continuous Integration is a practice now widely adopted across the industry. Join a development team and they will probably be using tools such as Jenkins, Bamboo and Team City to monitor the build process. All these tools use indicators very similar to a Pedestrian Crossing.

Lets take Jenkins for example:


Blue Ball = Everything appears Good.

Red Ball = Something went wrong.

These coloured indicators look simple but in the same way as pedestrian crossings, they influence behaviour in different ways.

Lets take the following two teams:

Team A

The build fails and a Red light is shown on the Jenkins dashboard. The team stops, identifies the source of the failure, perhaps by nudging the last person who checked in. The source of the problem is identified, rectified and build is run returning to normal.

Team B

The build fails and a Red light is shown on the Jenkins dashboard. The team ignores the failure, continues checking-in and the builds continue to fail. Later that day, a developer in the team identifies a compile issue locally, checks-in a fix. The build returns to normal.

How do you cross the street?

What actions we take based upon the build indicator is influenced  by a number of factors. I’ve seen teams confidence of build indicators eroded by false positives/negatives leading to ignorance of builds. However, the biggest factor in my experience is team culture.

In the example of Team A, they are clearly influenced by their CI tool and a culture to investigate problems quickly and implement solutions. However in the example of Team B, their culture is to ignore the build failure potentially with the view that it will be resolved at a later date.

So what is your teams behaviour towards your Continuous Integration tool?

Are you like the Japanese? Do you stop when the build goes Red?


Are you like the French who in most cases ignore the warning signs?

In a perfect world we’d all agree that if the pedestrian light says stop, we would all agree thats the best action to take. However, i’m sure we have all crossed the road, ignoring the sign.

Maybe it’s the same for build indicators, if the build is Red, maybe its OK to ignore……….sometimes?

Ignorance is bliss

Ignoring builds might be ok in some cases but the danger comes when we grow a team culture that blindly ignores the warning signs. The occasional ignored failed build can often develop into a culture where build failures are always ignored. This culture might yield some good results but it’s likely to result in some near misses, like this gentleman:

How to have successful conversations


Successful conversations are central to agile teams. As it states in the Agile manifesto:

“Individuals and interactions over processes and tools”

With this emphasis it is no surprise that many of the agile approaches adopted by teams today focus on enabling successful conversations:

User Stories –  “3 C’s – Card, Conversation, Confirmation.” Ron Jeffries

Behaviour Driven Development(BDD) “The single most important part of BDD is the conversation.” Liz Keogh

Three Amigos –  “Conversations between the team to gain a shared understanding.”

Conversations are hard!


The problem is good, valuable conversations are incredibly hard to have. Most of the teams i’ve worked with have found it difficult to have successful conversations. In some ways i think thats why so many teams “Doing BDD” jump straight to the tooling. It’s so much easier to write some feature files on your own rather than actually have a conversation.

We all spend most of our lives dodging difficult conversations in not only our work life but at home with family and friends.

The biggest problem i think with conversations is that they are often emotionally complex. Unfortunately, conversations with the most emotional complexity are the really important ones.

Many teams often choose to ignore this emotion and this is where the problems start. It could be the Product Owner who brings an idea to the team but the team clearly doesn’t think its a good idea. However, because of the passion from the Product Owner, the team struggle to have an open and honest conversation. Instead, we move further along the journey and problems get compounded.

In Crucial Conversations by Joseph Grenny he talks about the impact of not having these conversations:

“If you don’t talk it out, you will act it out”

This has clear alignment to the software we build. If we avoid the crucial conversations, it reflects in the software we build. Maybe the team didn’t believe in the idea, so they built sub standard software because their heart just isn’t in it. Or maybe the team don’t fully understand the idea, but don’t want to appear stupid so avoid having the conversation.

So how can we improve our conversations?

Good conversations don’t start happening over night. Some of the techniques, mentioned at the start of this post can provide a framework to enable better conversations such as the “Given, When, Then” commonly used in BDD. However, we need to dig deeper to be successful with our conversations.

Fundamental to successful conversations is creating a safe environment. So often our conversations are influenced by our work culture. I talked at Agile Testing Days 2015 about the HIPPO (Highest Paid Persons Opinion) In many organisations its not safe to have conversations that challenge the opinion of a senior person. Creating a safe environment where teams can be honest is fundamental.

Improving our communication approach can also improve our chances of success. In The Chimp Paradox by Prof Steve Peters he talks about “The Square of Communication”


In the centre of the square is the “Right person”. I’m sure we’ve all been in the situation with lengthy calls to customer service centres where we are passed around between different agents hoping to find the “Right person” Its the same in our teams. To ensure success we need to have the right person(s) in the conversation. Luckily the agile approach promotes getting the right people into the conversations. Rather than having conversations in silo’s we are encouraged to break down barriers, something that the Three Amigos technique supports.

Finally being more humble in our conversations can help. In Humble Inquiry by Edgar Schein we are challenged to “Ask rather than tell” So often our conversations revolve around “Telling” It could be the Product Owner Telling them what he wants or the team Telling the Product Owner it’s too complex. By shifting to asking “Can you build this?” or asking “Can we make it less complex?” it builds better relationships that lead to more successful conversations.

I hope this post helps you to reflect on the communication within your own teams and that the resources i’ve suggested will help you have more successful conversations.

My next thought, is “How do you measure the success of a conversation?” Maybe something for a future post.