Author Archives: admin

Open Space Paris 2013 on Incentivisation and Performance Management

Open space session on Incentivisation and performance management (last open space session at Paris 25/9/2013)


Delivered within a week of having it, I suspect I won’t be the last….


Convener – Phil Thompson – embedded Agile support at Kuoni


List of Participants – and a big thanks to all of you for making this an engaging session – although some people’s handwriting has left their names a little open to interpretation:

Vincent Lassalle

Helene de Sant Front

Irwin Marmorat

Ruxawdra Banici

Martin Teljeby

Paul Whelan

Leon Cosmin Lupu

Steff Lang

Alan Shelmose

Adam Polczyk

Arne Ahlander

Maunicia de Caster Nanannete

Christopher Hogden

Peter Downer


The discussion started around objectives. There was some consensus that these should not link directly to reward, and if there is any element of reward then the team should be involved in its allocation / distribution.

Where the objectives come from was raised, should they come from the team, from the individual, from a line manager? and we agreed that it depends on the work and the company – although the closer it got to the person was preferred. Sensible comment was that the objectives should be the job description contextualised for the immediate future. One good point was that the objectives could be linked to retrospectives and by making the objectives very short then when looking back you can build up a record of achievement.  

There was discussion about what the point of the objectives were, surely the only realistic objective would be to deliver working software as a sustainable quality, which is great for a team (as long as the project has a MVP small enough) but the individual element was raised – how can you ensure that all individuals are contributing. It was felt that it would be unlikely for someone to be poor / lazy without the other team members / mgmt being aware (this might not the be case in a dysfunctional team). The daily scrum should identify those members not pulling their weight and there needs to be some opportunity to raise these issues (maybe retrospective) but some formalised 360 feedback sessions would be beneficial.  There was acceptance that performance against a defined objective makes HR’s job easier to manage people out of the organisation.

There was a wider debate about motivation in general, making note of the many references already made about Dan Pink’s work. There was also some good points made about giving objectives being seen as disempowerment – because the individual is being told what to do, can they opt out of the objective?


Actions – no real take away actions but there appeared to be agreement on the following points:


·         Objectives should be personal to the individual and relate to the same drivers of motivation, being empowered, being good at it, and wanting to be part of something.

·         Objectives work best when assessed by the team and have a short timeline

·         Objectives should be about learning and development not about reward

·         The best objective is to be part of a team that delivers VALUE, which is usually related to delivering working scalable software.


Maybe I’ll see you all in New Orleans …




Phil Thompson
Lead Agile Practitioner
Kuoni Global Travel Services

skype: Philthompson01

Phone: +447940 495987



This message has been scanned for malware by Websense.

Making Scrum Stick

  1. Convener: Sabine Canditt
  2. List of participants:
Mirna Milic (
Iris Weverling (
Carlos Fonseca (
Stefania Marinelli (
and others
  1. Discussion and recommendations
A Scrum team stops doing retrospectives – this is one of the symptoms that might indicate that Scrum, although “properly” introduced with training, coaching and everything, does not stick. In this section, we started by collecting symptoms of degrading Scrum. Then we picked the most common symptom and did an analysis of possible underlying reasons. While discovering more reasons, we also derived new ideas of how the problems could be avoided from the start.
This summary gives you some ideas related to a specific symptom, but also shows how going into an analysis can provide additional solutions that might be more suitable for the specific context.
Common symptoms of degrading Scrum (numbers indicate how many participants know this symptom):
  • Team does not “do Scrum” without the ScrumMaster – 10
  • Actions are not taken after retrospectives – 9
  • Split responisbilities within Scrum teams (developers – testers) – 6
  • “team members” that actually don’t work for the team don’t contribute to Daily Scrum – 5
  • Scrum gets boring – 5
  • Frustration in the team – 2
  • No more retrospectives – 2
  • Lack of upper management commitment – 2
Here are the possible reasons for the symptom “Team does not “do Scrum” without the ScrumMaster:
  • No one else takes the initiative
  • Daily is seen as reporting to ScrumMaster
  • Team members don’t like to communicate and don’t like meetings
  • Team members see the Daily as a waste of their time
  • Use a physical board
  • Change facilitator every Sprint?
  • Choose a good time, watch the duration
  • Combine with existing breaks (coffee…)
  • PO attends Daily Scrum
  • Provide interesting information from outside the team
  • Give the participants the freedom to “opt out” (see Open Space keynote)
  • Make it a topic for the next retro
  • Collaboration games
Kind regards

Sabine Canditt
Agile Trainerin & Coach, CST, CSC
Systemic Business Coach
Allianz Deutschland AG
D-IT-BVG 2-E1 Software-Engineering, Testen und agile Methoden 
Dieselstraße 6 | 85774 Unterföhring

Phone: +49-89-3800-11484
Mobil:   +49-1525-3040652
Fax:     +49-89-3800-811484


Why Sprint Zero Doesn’t Exist

Convener: Iain McKenna

List of Participants: Andrew Lefrancq, Gergana Georgieva, Stephen O’Malley, Martin Tecjeby, Dave Edwards, Steven Olds, Paul Exley, Paul Whelan, Klaus Lindemann

Discussion:  There is a need to do some work before the first Sprint starts.  This includes defining the vision and goals, putting together a development team, creating an initial Product Backlog, refining the initial Product Backlog to understand enough work for the first Sprint – which also informs starting state architecture and design.  This work should be accomplished in the shortest time possible so that the team can start to get feedback on real software.  As this work in itself does not deliver a potentially shippable product increment, this can not be a Sprint as one of the fundamental rules of Scrum is that each Sprint produces a potentially shippable increment of the product.  Calling this pre-sprinting activity a Sprint is not just a matter of language as it sets a precedent early on with people that Sprints do not have to deliver potentially shippable increments of the product. There were also some examples given of teams using multiple Sprint Zeroes (0.1, 0.2… up to 0.14) and how this just perpetuated Big Up Front Design which everyone agreed was a bad thing.


The discussion also covered Product Backlog Refinement in order to ensure common understanding and then diverged onto release planning and how that can be done simply and quickly using velocity and the Product Backlog but also the need to revise the release plan at the end of every Sprint.


Recommendations: Activities that are done in order to get ready for the first Sprint should not be called Sprint Zero.  They can be called anything other than a Sprint but people should be clear about what they need to achieve before they can start sprinting.








Work Place Revolution, Intergenerational Engagement Using Scrum and Open Space

Convener:  Suzanne Daigle


List of Participants:

·         Helene de Saint Front –

·         Vincent Lasalle –

·         Georgana Georgieva –

·         Stefano Lucantoni –


Discussion Highlights :


In the US, Massive number of baby boomers who are heading towards retirement but who may not be retiring (in the US, about 78 Milllion); Almost an equal number of Millennials  (ages 21 to 34)  coming into the workforce with a much smaller number of Gen X (ages 35 to 48); Similar trends in other countries though not all. In 7 years in the US, Millennials will represent 51% of the workforce. Massive transitions ahead and we are unprepared.


Some companies (i.e. Microsoft are seriously looking at this). Many misunderstanding between the two generations: Baby Boomers and Millennials.  For example, parents and leaders will often say:  “Why do you spend so much time on Facebook?” Leaders are mostly baby boomers, they don’t understand the way the younger generation thinks and works.  Often managers will say they are not “management potential”. People will seek to hire others who are like them.


The world has changed. Job security does not exist, unlikely that young people today will have a pension at retirement age. Rather than doing jobs that don’t use their talents and skills or because there are not enough jobs, many young people staying in school, doing internships. In France, internships are quite segregated; work is more project base so the opportunities to interact with a broader side of the business are diminished.


The Financial Crisis of 2008 is forcing a workplace revolution, companies need to operate differently; need to look at networks and flatter organizations. If companies are to succeed, they need to attract the talent doing some of the things that Google is doing, providing discretionary time to be involved in creative projects that provide meaning at work.


Scary now to look at mainstream companies, to see the clash in the 2 generations (Baby Boomers and Millennials). We are losing a lot of knowledge by not interacting with each other directly NOW. It’s important that the 2 generations learn from each other; we need to explore new ways of doing things.


Typical conversations:


Father “What do you want to do with your life?  That’s not a job that will provide security over the long term. “

Son:  “Want meaning and purpose. There is no security and most likely there won’t be retirement when I grow old.”


New companies are reinventing work; younger people more adaptive to change and the environment. They are used to change.


We need strategies to bring the two generations together. Millennials want to provide their perspectives on the strategy. Hard to do when there are 12 layers of management.  We never get to talk to those making the decisions.  For people who have been doing their work the same way for a long time, it is difficult for them to see it differently. They also look to hire people who like them.


We can expect a big crash ahead. At some point the number of Millennials will shift the pyramid with leadership now sitting at the top.


Ironic that baby boomers created the globalized world but they don’t have the tools to manage and lead it.


We don’t have the space to integrate our different points of view.  When baby boomers come into positions of power, they then project their own view of the world. In the future, these books will be totally rewritten. If the dialogue does not begin to happen, chances are we will also not be interacting with our grand-children because this will not have happened between us now.


It is normal that people become more tired and more conservative when they are older; they are typically less open, more risk averse.  There are still ways to remain creative.


We are seeing anthropological shifts; it is not possible for older people to maintain control as they have done in the past. The young people have many more ways to approach problems and seek out opportunities.


In the past, you achieved control through knowledge. Now that knowledge is available to everyone.


Unfortunately young people don’t have all the knowledge and wisdom. Right now because of the hierarchy and lack of interaction, we are losing theoretical and even specialized technical knowledge. This is not being shared. It will create major problems in the future.


Other issues is that Millennials will have less children.  In some countries, poorer countries,  the opposite is happening; people have many more children. It has been shown that with greater wealth, couples have few children.  Many from other countries are becoming highly educated also. More competition for jobs.


The Youth use the Law of 2 Feet a lot. Don’t stay in jobs that don’t have purpose or meaning.  Need for more critical thinking.  Through the lack of dialogue and collaboration, we are also losing the values that our parents had.   In young people, there is a sense of entitlement. We want things to happen right away. If the values are there, Youth is willing to work hard. At the same time, there is a feeling of being rushed. There is so much that is broken, so much to be done.


Question:  How do you make our organizations value having these conversations…together? We need to “force” these conversations to happen.
















How to get a team from well-performing to high-performing

Convener: Irmgard Sabet-Wasinger

Discussion & Ideas:
  • The book about the 5 dysfunctions of a team was recommended
  • The book DRIVE by Dan Pink was recommended
  • Challenge the team as PO
  • As a last resort, maybe change the team’s composition
  • Get a coach
  • Ask the team “what does it take to be awesome” in the retrospective
  • Let the team figure out what “high performing” means for them and then see where they currently are
  • Keep an improvement backlog in the team room
  • Find out about motivation - does the team know the purpose? does it know what the users do with “their” software? What would they get out of it if their performance improved?
  • Celebrate important milestones! Remind the team of all the great things they achieved in the last 6 months.
  • Use figures like the “happiness index” (or others where we did not go into more details…)
And don’t use the word “performance” when discussing this with the teams… ;-)


Fwd: Scrum into ISO for “Software that pleasantly surprises”

Scrum into ISO 9001 for “Software that pleasantly surprises”

Hans Verrijcken (Coteng NV)

Thanks to
Everyone participating

As a software company we are ISO 9001:2008 certified for
“Software that pleasantly surprises”
The Challenges we face(d) :
- ISO is not really tailored to software certification
- The focus for Scrum and ISO is seriously different
What we did to satisfy the “proof of evidence” requirements” : Next to all current standard development techniques (including of course Subversioning, Continuous Integration with monitoring of code-metrics, build-history etc. etc), we are mapping the scrum values, logic and guidelines into the ISO 9001 requirements.

Not really “going by the book”…
but integrating both worlds…
sometimes you just need to look at the world from a different perspective…
- Instead of the traditionally hierarchical, ISO required, organisation chart, we put the customer in a central place in our organisational chart.
- we radically changed many of the classical roles to become SCRUM roles
- Used the Scrum values into our resulting Value Chain and job descriptions
- focus on customer satisfaction and getting above the conformity level (the exiting, surprise, wow-area)asset.JPG

Additional ideas that were brought in during the Open Space

- Observations (complaints / non-conformities) logged and reported as a partial alternative for “bugging” the customer too often with surveys
- reporting of number of issues that enter in the backlog
- For every release, add at least 1 element of happy surprised for the customer (annotate in the backlog)
- Check alternative and/or competitive software for new ideas
- The nature of and the internal testing during the sprints is guaranteeing the 45% conformity.
- If you need to have logged bugs to show you handled them (adaptive and corrective measures)


How to have the courage to fail when failure means…The End of the World!?

At our open space we had the lovely Torguy Andersson, Doug Scherbarth, Lloyd Mitchell, Kristi Nigulas, Tom Howelett, Adrian Potter, Vincent Lassalle, Suzanne Dougile, John Chadwell, Enrico Braganje, Ranouf Abrougui, Dav Tsal Sela, Stefano Lucantoni and many more butterflies and bees who came and settled around the edges, who I am sorry I did not manage to capture the names of.

"I have to do this 20th thing today, right now, because if I don't… The world will end." It can feel like that a lot of the time for the teams I work with. We're an environmental charity and like most charities we're strapped for money, people and time to do all the things that it might take to fulfil that one mission that is on forever scope creep(?) – changing the world for the better.

Here are some of the ideas both practical and profound that came from our open space:

Where's the problem really at?

1) It's over-commitment for every individual, but one that is ingrained in existing culture of always seeking to do more, give more and the pride that can come from that as part of the organisational and personal identity.

2) Is failing really the issue? We're failing to get things done all the time, but its not really seen as failure.

3) Is it less about each person and more about the interactions between the team and others. You always saying "yes" to that extra request, knowing in your heart it really is a "no" but too polite/scared/used to saying yes? What's the "why" behind this and can it be challenged

The Practical

4) Move the the stand-ups. At the moment the team flat-out refuses to a daily 15 mins, but ad-hocs do happen around a desk quite often. So how about taking a stand-up to them. Designate a desk and at certain time, pick-up the rest of the team (the team-train :P) and do it round the desk.

5) They love to talk. Another reason why 15 min commitment is never 15 mins and the fear of meetings. So try 5 mins to start. Take a stop-watch, start with 1 minute each. There can always be extra time at the end if people want to hang back. Don't label it a 'meeting' or some grand process thing.

6) Really work harder on the definition of done making sure it shows the value and do it together. Ask the question for every task, "what would it mean for it to be done"

7) When the hesitation comes to moving something into done. i.e. Want to add another layer of we could do 1 more thing, instead add it as an extra task, then add these as new things to be prioritised rather than allowing continual progress, but no completion.

8) Make more of DONE. So that success and progress is celebrated with this as the key focus. Visual prompts, anything to recognize and shift pride in the done rather than the constant doing. Can we make 'done' more fun.

9) Recommended Ted Talk "Power of vulnerability". Find the space to talk openly, challenging the always saying 'more' or 'yes' and examining the why behind habits.

Diving Deeper

The mission is big and gets bigger each time we look at it and the urge is to run full pelt at it, all day, everyday. Perhaps we need to recognize that it's not a sprint at all. Or lots of sprints that we need, but a marathon. We need the grit and pace to keep going.

Perhaps the courage needed isn't about failure, but courage to call 'it' done, to accept 'it' won't be perfect and to be courageous enough to admit we only have so much we can give. To know what we are capable of.

Thanks to all participants, who came and contributed or just listened in. It was incredibly useful to delve into the agile values and how these rub up in reality against the ones in non-profit teams. Love the ideas for sneaky stand-ups and other creative ideas, as well as making an effort to go back and challenge the team to be more open with each other to break some old habits.

It was fun and full of energy. I'm ready to go back and try them out!

I'm sure I didn't manage to scrawl down all the great insights and range of discussion that was had. If there's something key I missed, further thoughts or would like to keep in touch you can find me at @startmyquest or linked in Wendy Yuen.

SAFe or Un-SAFe

Convener: David Hicks @AgileDave

Photo of Dot Voted Agenda attached:

Photo of Final Participants' Names & Their Recommendations attached:


Further Notes from one of the participants below.
Kind regards
agil8, One Kingdom Street,
Paddington Central, London W2 6BD
+44 207 681 6078

Begin forwarded message:

From: Kris Philippaerts
Date: 25 September 2013 12:57:32 CEST
To: David Hicks
Subject: Notes SAFe

  • Structured, disciplined
  • Scripting the critical moves
  • Same cadanse for different projects
  • Synchronized plannings
  • ScrumXP is basic building block
  • Designed for different programs, each containing 50+ people
  • Fractal: practices are reused on all levels
  • Something youncan start doing now
  • Red versus blue: architecture features versus business features
  • Leffingwell is just a frozen state of SAFE
  • Bad image:
    • Very commercial
    • Highly polished
  • Built on the house of lean
    • Try to work with feature teams
  • Roadmap built-in: how to get there (??)
  • Good place to start, but need to be climbing up
  • PO is on project level, Product Manager is higher level PO, scaled vision
  • SAFE speaks in business language where Scrum does not
Level 3: team 
  • Strong on XP practices: you cannot scale crappy code
  • Is actually Scrum, but goes away from the "ideal" picture: an imperfect pragmatic version
  • HIP sprints:
    • hardening sprints, sort of program increment.
    • no coding, hardening practices, integrated ci
    • somewhat fuzzy, no eal agreement
    • Can be seen as celebration moment, sort like hackathon
Level 2: program coordination
  • New roles
  • System working, integration, …
  • Architectural runway: framework in advance of dev teams
  • Agile release train: over level 1 and 2:
    • 2 day release planning

Level 1: portfolio

  • Based on kanban approach
  • Investment themes
  • System of epics, business and architectural
Other frameworks: LESS and DAD
  • Less is more scrum oriented: keep to minimum
  • Safe is more described as broad and deep
  • DAD: good on diagram method, nice, on the way, pragmatic. But for the details, might be too rigid, like RUP.

NonViolent Communication

Convener : Arnaud Lamouller-Bonaventure
Participants :
- Pia Boye
- Adrian Perreau de Pinninc
- Annelies Poot
- Christof Braun
- Mark Williams

First, a definition

Nonviolent Communication holds that most conflicts between individuals or groups arise from miscommunication about their human needs, due to coercive or manipulative language that aims to induce fear, guilt, shame, etc. These "violent" modes of communication, when used during a conflict, divert the attention of the participants away from clarifying their needs, their feelings, their perceptions, and their requests, thus perpetuating the conflict. 

Violent behaviors are :
Moralistic judgments:Blame, insults, put-downs, labels, criticisms, comparisons, and diagnoses  
Non Negotiable Demands with blame or punishment if they fail to comply 

Denial of responsibility we can't deal with our guiltyness
Making comparisons between people 
Unsolicited advice because it lacks of respect and consideration of the other's choices. 

Violent communication don't take care of other's human needs.
NonViolent Communication for unlock conflict or suffering situations.
When I live a difficult situation (example:my team members don't respect the sprint planning !), by putting the responsibility on environment or other people, I am in a powerlessness position.

If I focus on me, and am aware that my troubles don't come form the environment or others behaviors, but from my own feeling in this situation (I like that everything goes as planned), all depends of me and I have the power to change this.

4 steps to feel better:
- do Observation:at the end of the fifth sprint, team had finished 7 stories when we planned 10 during the sprint planning.
- Focus on your Feelings:I feel angry and disappointed.

- Identify your Unsatisfied deeper Needs:I need security
- make yourself a Demand:I will talk about my anger and disappointment during the retrospective without blame anyone.

Be careful:needs are not strategies. 
I need to go to meetup : that is a strategy to satisfy your need of community.
Pattern to describe a problem non-violently
What to do when others don't want to communicate:

Do the Observation-Feelings-Needs-Demands process to soothe yourself.
Remember that you can't change others easily, but you can change your feeling face to the situation.

“If there is no solution to the problem then don't waste time worrying about it. If there is a solution to the problem then don't waste time worrying about it.”
Dalai Lama XIV
Many thanks to this session's attendees and to you who read this report.

Book : "Living NonViolent Communication" by Marshall Rosenberg
NVC group research : NVC@school



Hiring in a dev/ops environment

We discussed the challenges of hiring for a dev/ops environment. We broke it into 3 parts:
- What we look for in a candidate
- How to advertize positions
- Interviewing Process

What we look for in a candidate
- Ambiguity
- Change
- Eager to Learn
- Able to fail
How to advertize the position
- Focus on the ad

   — where
   — what
- Sponsor Meetups for Agile at company
- Educate recruiters
   — Feed them Agile
Interviewing Process
- Dev/ops mixed staff interviews

  — let them fight
- Interview in dogbone 

Large spec panicked customer

Convener: Steve Carter

Participants: Stefanie Marinelli

Catalin sindelaru

Steffen trefo

Stephanie Mueller

Irmgard sabet-wasinger

I described a situation with a very small team and a large bduf specification. Work items are typically urgent and prio 1 and bigger than one sprint. This model was a caricature of my real world situation.

Many suggestions were forthcoming, not all of which were within my sphere of influence, but also some basic violations of scrum were found that are within my power to fix.

I came away with a good clear idea of many lines of attack for the problem and will take first steps on my return.







Testing in the agile context

Hi All,

We had a good session on testing with some great contributions. The big take outs were:

1) How much testing to automate and how much overhead to maintain.

a) the automaton strategy needs to be defined up front and managed across the team. This is not necessarily the QA manager.

2) Metrics to capture

a) keep them simple and few

b) refer to them and check the trends to make sure you are going on the right direction

3) Important to keep testing within the sprint and avoid the temptation to have testing sprints as this results in finding bugs later.

4) The trend seems to be towards QA manager roles rather than more traditional Test Manger roles with a focus on coaching and mentoring rather than organising all test activities.

Thanks everyone,


Stories on prejudice about agile

Convener: Björn Radon
List of participants:
Olivier Azeau
Leonoor Koomen
Stefanie Lang
Radu Secosan
Michael Downing
Cristian Cimpineanu

Ioan Armenean
Discussion and Recommendations:
Björn motivated the session: the more failed agile adoptions, the more people with prejudice about Agile and Scrum because of that.

The discussion was spreading to a more general "do your work as good as possible" type.
One participant meant that you should not brand it agile, but live and work according to the core values and do your best. In that way you can influence the team and company in that way without the prejudice getting in the way.

One participant advised to facilitate off site events over a couple of days and go through the core principles and to get some team building going. Also you can process experiences of previous failed efforts at such gatherings.

One participant told a story about a scrum master going into an organization for an agile transition, but he was only on site once a week. 
One participant meant that you should mirror to the people who are very disconnected that they appear so and give them the opt-out alternative. A few very negative people can be devastating to a company, and there are very low chances of them changing, so it is a waste of energy to keep trying to get them on board over weeks and months.

I think that wraps it up.

How can retrospectives be more impactful?

Convener: Sabine Grieger
Participants: Stene, Adam, Marco and approx. 30 more
Discussion and recommendations: we discussed different approaches on how to make the retrospectives more active and lifely. Participants shared ideas that others can try. The overall agreement was that it is very important to get the team members upfrom their chairs, get the discussion started and ensure that valuable action items are identified and followed through. If there is no action after a retrospective, participants will loose interest over time and not make an effort to identify areas for improvement.

Release planning

Convener: Pentti Virtanen

Attendance 12


Talking points (flaps):


Initial ideas when we started.

Release planning creates business value

Is release planning a separate activity?

Who is doing release planning?

Reality or a dream

It is not a commitment




Releases planning is good but release plans are useless

Product owner is responsible

Release plans are not commitments


Pentti Virtanen, Software Specialist, Ph.D., CST
Tel. +358 50 461 7724
Tieturi – Training for Success
Read my latest blog post at




Planning Poker – Inflation of Story Points

Convener: Susanne Albinger
Discussions and Ideas:
  • Story points are only important for long term planning
  • Ignore story points for sprint planning
  • Fear of estimating too low: put no pressure on the team, if they finish earlier, just take in another story
  • Use animals instead of numbers
  • The discussion and common understanding is the most  important thing in the planning poker -  not the number => make this clear to the team
  • Use T-Shirt sizing and measure the average time it takes to get a story of a size done => tool to plan ahead

Agile Contracts and Engagement

David Grant
List of Participants
Nancy Mayer
Larry Cross

Raj Mudhar

Marc Voillemor
Yrgan Rame
Stephanie Muller
Csaba Domleo
Tomas Kelemen
Laure Pain
…and many, many more.  Tjank you all so much.

Discussion and Recommendations

There is an open-source, creative commons agile contract is availale at  Raj Mudhar is working on an agile contract for the public sector at Deloitte.  You can reach him at
A successfully delivered fixed-time, fixed-scope contract can help with a shift to an agile contract because it establishes trust. If you have a good reputation, this might not be necessary.
You can use a fixed-price, fixed-scope-size contract, but swap out scope on the basis of story points or functional point estimates.
Make the availability of a product owner a pre-requisite for the contract.  PO should be on the customer-side of the contract,and should define the Definition of Ready and Definition of Done.  Ready should include definition of all acceptance criteria, and done should include zero regressions.
Staff augmentation is related: instead of the supplier taking responsibility for the delivery of the project, supplier provides a scrum team.  This has the downsides that the scrum team will take the project knowledge away when the engagement ends, and may take time to understand the domain.
Agile contracts should discuss scrum ceremonies and artefacts and be based on incremental deliveries or on delivery of epics.  The contract should have a two-way committment and have transparency built-in.
One hybrid contract included a renewable fixed-price, fixed scope sub-contract which was renewable after each iteration.  When release artefact is delivered or deployed and meets the definition of done, supplier is paid.  It might be useful to include a "sneak preview" during the sprint to ensure customer's expectations are met.  This is an example of high collaboration.  This contract has a single sprint cancellation clause, so once work has begun, it must be completed.
Another example contract expanded on this by allowing under- and over-delivery. For example, if the development team delivered 80% of stories, they receive 80% of payment.   Might need some discussion of impediments here:  what would happen if the supplier is impeded by the customer, for example?
KPIs: defect count,etc.  are not useful indicators – use satisfaction instead.  Collaboration over rigid contracts!
Before first iteration, and after milestones, survey customer on their satisfaction and understanding of the agile approach.
The agility of the contract is directly related to the level of trust between the customer and the supplier.


Using Scrum To Learn Scrum

Convener: Adam Polczyk
Participants: Michelle Walker, Eugene van Der Meuwre, Bernard Schneider, Stefan Roock.
We had a very interesting discussion about our experiences with the practice of using Scrum to teach/learn Scrum. Everyone was positive about the approach.

Sent from my HTC

Agile adoption without convincing

  • Jaroslav Orsag
List of participants – sorry, only few names collected: 
  • Yrian Reime (Norway)
  • Alan from TopDanmark (Denmark)
  • Wolfgang Richter (Italy)
Discussion and recommendations:
  • if you want team to follow you, thay must trust you
  • trust can be obtained by being one of them
  • if you manage them, you are not one of them and trust has gone
  • you manage them if you manage their salaries, bonuses, hiring, …
  • shift from manager to servant leader
  • don't be so much involved in tasks
  • get inspiration from outside, have external coach, talk to scrum people outside
  • recommended reading: The Five Dysfunctions of a Team (
  • must make a decision wether to be a manager or a scrum master
  • manager is loyal to / focused on director
  • scrum master is loyal to / focused on team
  • in Norway it's difficult to fire someone -> employees have no fear -> employees speak openly to managers -> different culture

    sweden is even further

  • in picture attached diagram of compatibility between specific roles is sketched
Big thank you to all the participants on the session – you helped me a lot.
Jaroslav Orsag (Slovakia)

Focusing on the user needs in Scrum

Focusing on the user needs in Scrum

We discussed whose responsibility it is to focus on the needs. Ultimately it is the POs responsibility, but there has to be a shared commitment to fulfilling the needs in the team. It's beneficial if the team members can take part in the user analysis activities to get a better understanding. Sometimes there is a conflict between the UX perspective and the business perspective, as a UX person you need to be sensitive to other priorities besides UX.

It is very hard to understand the needs if you never see any real usage of your product. The best thing is to get out there, when that isn't possible you can use proxies or look at usage of similar products. When you understand the needs it's easier to prioritize the backlog and decide which stories can create the largest value.

A Business impact map with measurable effect goals can give a clear view of the vision in a bird's perspective. Sometimes you need to create more detailed user stories which can complement the Business impact map and it's good to sometimes shift perspective from frog's perspective to bird's perspective.

It's common that POs are very solution oriented and forget about the needs. Lean startup events are a great way of getting out there and meeting real potential users. Gemba walks are used in Lean manufacturing to get close to the value creation. This principle can be applied when it comes to needs analysis as well.

Our feelings can sometimes get in the way of our needs. If people are emotional they might need help to put words on their feeling by labelling to enable them to access their actual needs.

Best regards
Sara Leren

Med vänliga hälsningar

Sara Lerén
tel. 0705-240421

Coaches and Trainers are loners – discuss.

Paul Niehaus
Bjorn Radon
Nicolas Delahaye
Mr X
It was interesting that all discussions were one on one…sort of proves the point doesn’t it?
All attendees and non attendees agreed :-)
Impediments are not being able to network easily. Techniques and gatherings are used as vehicles in this respect.
Advantages are that that objectivity can more easily be maintained.  There is no need for alliances,  and hidden agendas do not need to be pursued. Saying like it is, is easier.
A social conscience is however needed because to motivation must be to make it better for everyone and not just one interest group.
Creating mechanisms for peer feedback is also important.  Co-coaching and co-training are also good mechanisms.
An observation is that a loner is not same as being lonely. 
Also the position can make one a loner.
QED :-)
Sent from Samsung Note tablet

Open Space Break out #11 Scrum Coaching Retreat London

Timescales: London in  w/c  9th June 2014 - overall 4 events in 2014 – Europe, India, china , USA
Centrally coordinated by CSCs, however open to everyone.
70-80 people limited 
Sessions focused on coaching where topics are suggested and the groups use scrum to take a deeper dive into them.  This is a deeper look than usual conferences.
Potential topics: New games, could be on retrospectives.  Forming new patterns to deal with issues. Coach the coach. Train the trainer. Growing coaches. Growing user group communities. 
Theme forming: strengthening the community at large or strengthening the coaching community.
Pricing : £350-£400 – possible sponsorship, but not some big branding event. 
Venue suggestions: colleges and universities.  Google camps. Warwick. Oxford, Cambridge 
Near fresh air
Steve Mc Fayden
Steve clymer ( offer of help-
David grant(offer of help –
Bjorne Jensen (attended an earlier retreat) interested in running 2015 session. 
Helen meek 
Mark summers (open space suggestor)
Christopher Mathis
Paul niehaus (offer of help) 
Zia mallik
Nigel baker 
Kenneth dunith
Julian daddy (interested in attending -
Michael downing 
Glenn smith. 

The Balance between agile and Controlling

Convener:Hong Xiang

Participants: Sabine, Zvonimir, Shen, and another three

Discussion: What are the conflics between agile and Controlling? How can we resolve them? What are your experiences about this topic?


We can get rid of the Controlling at enterprise level totally. Some of the Controlling are necessery. The Managers have to controll the project Töne, budget and deadline. The core of the agile and scrum is human, is trust. When there are more and more trust, we don’t need to make so many reportings. The reporting overheads and comunication overheads schuld be reduced. We should provide more tranceparency to give our managersmore save feelings. Such as through sprint reviews, providing scrum artifacts, and so on.

Diese Nachricht wurde von meinem Mobiltelefon mit Kaiten Mail gesendet.

Session on Large Number of Teams and Complex Software

Convener: Scott Duncan
Participants: (probably had twice as many people attending but the
following are the only ones who identified themselves through signup sheet
or business cards): Scott Cothrell, John Gouveia, Ari Brown, Cliff Oliveira, Marc Story, Rahil Patel, Ryan Garcia, Jerry Lathem, Eric Yang


Focused mainly on scaling and team distribution and little on the complexity of the software.
With a large number of teams, where do all the Scrum Masters come from if they are to be ”just” Scrum Masters.
Agile can make distributed teams harder due to the assumption regarding direct contact between people. On the other hand, the emphasis on communication encourages not falling back on “document passing” as the default (and only) assumption for contact.
A key outcome was to collect contact information from people who wanted to continue discussion on this topic after the Gathering. Anyone else interested in such a “community” can contact me at

Also collected the following “data” from some attendees:

#Teams Company Domain

160 Intergraph “CAD”

50-65 DoD/VA iEHR

~20 Jack Henry financial

12 network platform

500? Adobe design, docs, analytics

2 NASA simulation

10 AMDOCS carrier billing

220 Splubk big data/OI

12 Cisco security

300 Vanguard financial services

Women in Scrum Open Space

The following is a list of topics discussed:

  • We introduced ourselves
  • We created a list of important topics (via brainstorming)
  • We prioritized the topics (in the interest of time I grouped them later and they could be rearranged as the group sees fit)

15- create a community outside of the conference

2- have some conversations/ connections

10- learning, supporting, mentioning

2- young women have it harder

5- how do we attract more women to scrum

20- encourage women to come forward and be visible

3- women on the board

3- no women keynote

4- blog more

0- get voices heard

#?- help people stay engaged when life happens

1- how do we observe scrum as women

Ideas for potential ways to stay connected (This will be organized by Leslie going forward with help from others)

  1. LinkedIn (SA already has some groups and could add ours)
  2. Meet Up
  3. Facebook
  4. Google Group


  1. Carol offered up the “go to meeting” acct for SA that we can use
  2. Distribution list agree a date tool
  3. Lean In book recommended

Thoughts – we for sure want to be inclusive and grow but we wanted to keep it small until we get our feet under ourselves (1 month?) and then expand it. The idea is to grow but we don’t know what we are yet…

doc iconScrum Gathering Women in Scrum notes.docx

Lean Startup Combined with Scrum

Group Learnings:

(In the Group’s words) Get the book!

Tool for Product Owner Lean Canvas [Tool to represent the business model and experiments]. Find quickest way to test assumptions.

Lean is geared towards product analysis.

Lean vs Scrum

Minimum Viable Product (MVP) Impact analysis

Lean Startup concepts help a Product Owner be a better Product Owner

Lean Start is for Product Owner

Convener: M. Kelley Harris

List of Participants: Andrew Kallman, Kevin Graves, Moonie Lantion, Robert Morris, Lynn Winterboer, Vivtek Malhotra, Bernd Klupp, Sateesh Nagilla, Vinay Nagarnj, Harry Nieboer, Ran Nyman, Pavel Dabrytski, Janet Figueroa, Rob Spieldenner

Team Motivation (Excited about Agile?)

Convener: Bill Slocum

Participants: (See below)

The purpose was to do some collaboration on how to get team members more excited about Agile so they want to do more. They need to understand that this is not just another passing fad. Key points were captured and are attached here. High level summary: We know that motivation is not easily solved. There are many factors that affect ones motivation, and what works for some teams may not work for others. Affecting factors range from external sources (such as management and others) to personal reasons for the individual themselves (some will never be motivated). A short summarization of our discussion on possible ways to increase ones motivation; through the use of continuously sharing the measurable benefits, incentives, anonymous input from the team for retrospective (on people/reasons causing motivational issues), reminding team there is not much to fall back to (waterfall is worse), small celebrations during sprint on progress (can be a simple ‘woo hoo’), and team self evals to name some. Thanks to all for their input! This message and any attachments are solely for the use of intended recipients. The information contained herein may include trade secrets, protected health or personal information, privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation













How to find out how good you are at agile at your company

Organised by: Harry Nieboer (

Setting: my company in the Netherlands sends out employees to conferences (like the Scrum Gathering) and training. But how good are we performing anyway, and does investing in learning really help? How do you actually find out how good you are at agile? We started the discussing with three questions:

1. Who cares? Is this something management should care about? (at least according to the developers) Is this something the Scrum Master should be held accountable for? (she is the one with the mission of making the team work well together) Is this something the Team should be held accountable for? (could well be part of self organizing)

2. How would you assess your current agile capability? Should you use independent audits? Could you let your teams fill out the Scrum Checklist from Henrik Kniberg? (

3. And then? Publish the results, to encourage competition? Act on the impediments? We discussed the above three questions and concluded the Why was missing. If you know what you want to accomplish, you can than derive what you should measure.

* For my company mostly doing projects for external clients, we are aware that we need to become a more agile company. More agile meaning being able to start up new projects fast, having environments and complete oiled agile teams available within days. The general understanding was that all should care. There were additional suggestions on how to do the assessments: surveys, 12questions (used at Nokia) and (free) checklists at . There were suggestions on metrics to look for:

* How long does it take to get an idea to production

* Bug response time

* Ratio between value delivered and failures

* Business value

* Waste due to waiting (measured in queue length or total queing time)

* Cycle time Especially, you would like to measure leading indicators (and not lagging), helping you to change directions when necessary. And what to do with the outcome?

Publishing results can be risky (people might nog want to be open in answering questions the next time), although transparency was considered important. An other outcome would also be to change teams (transfer your best developer to a team having issues in this area, so they can pair and the team can grow).

Participants were: Sami Lilja, Gil Nahmias, Erin Jostes, Boris Jurcic, Oliver Gommer, Paul McGregor, Remi Kok and David Kane, and some ten others whose names we did not get.

Agile Software Development in the Government

Convener: Charlene Cuenca

List of Participants: Charlene Cuenca, Becky Redeker, Frank Balogh, Don Macintyre, Scott Cothrell, John Duque, John Gouveia, David Kane, Tom Mellor

Topics included:

  • Project setup and composition
  • Each person discussed their company and project role
  • Team structures
  • The size, composition, and processes within the teams
  • Product owner issues
    • There were several issues revealed about product owners not being in the ideal role. They were product owner proxies or project managers but not really representative of the end user or customer.
  • Non Ideal Scrum setups
    • There was a discussion about a team that did not have release planning, a team that did not have daily stand ups, a team that had moving release dates
  • Sprint lengths
    • Sprint lengths varied from 2 weeks to 3 weeks to 4 weeks to one month
  • Certification and Accreditation issues
    • The group discussed the issues with the certification and accreditation process within the government and how it affects the development cycle. This typically resides out of the release cycle and can affect the next sprint cycle capacity.

Acquisition process
The acquisition process is known to be a cause of problems in agile development. There is an ongoing effort within the government to make the acquisition process more agile. As of today the process change has slowed but has the backing of several key members in the agile community. Discussions and recommendations: This was a collaborative round table discussion focusing on the issues within Agile projects in the government space. It was noted that different branches of the military could have different issues implementing agile processes due to the core differences in the military branches themselves. A participant stated that the Marines in general seem to be more agile – they are tasked with a problem and work as a team to resolve it out in the field. Those higher in the Marine structure will let the team form and solve the issue. In other branches, there may not be that level of cooperation. The traditional command and control structure within the government seems to hamper the agile development effort. The grassroots effort going on within the DoD seems to stall when reaching the middle management level . The acquisition process was also discussed as a reason for the slow transition to Agile processes.

Several resources were shared that were related to Agile within the Government. One was the adapt group. Also a video link was shared featuring Teri Takai.

Overall the session was useful and it was interesting to discuss the various ways that projects are implemented in various branches of the government.

No Estimates: Alternatives to Estimates

Title: No Estimates: Alternatives to Estimates

Convener: Woody Zuill

Participants: There were approx. 45 participants

Discussion:   We asked the question: Why do we think we need estimates?, and collected post-it notes with the reasons we “think we need estimates”

We then grouped them, and found the following groupings:

1 – Predictability (about 3/4 of the notes collected)

2 – “Go or No Go” decisions

3 – Prioritization

4 – “Fill” a Sprint with work

This led to a second rhetorical question: Why do we need predictability?

- We decided that a “5 whys” exercise should be done to get down to the bottom of the real reasons we insist that estimates are needed.   We discussed the idea that MUCH of the training in the Agile field is about estimates, prioritization, sprint planning, release planning and so on, and yet there is nothing in the Agile Manifesto that points to the idea that estimates or this type of planning is needed or important.   At this point we asked for discussion on possible alternatives to estimates.

A few were discussed:

- Kanban

- Pull discrete pieces of work

- Early and often delivery of working software

Some time was spent addressing the idea that “we still have to do estimates to be able to make software”.

Conlusion: While there are some people working without estimates, there are still many unanswered questions about how to go about doing that. It was observed that there are many different environments and while “no estimates” might work in some, it might not work in others.   In other words, we had no “conclusion”, but we did have a lot of ideas we can explore when we get back with our teams and daily work.

Collaborative Continuous Learning

Convener: Woody Zuill

Participants: Approx 10 people

Discussion:   We shared ideas about how we’ve been finding ways to encourage learning collaboratively on our teams.   The basic idea: Learning together as a team can be a way to identify the things we need to learn, and at the same time accelerate our learning.   I shared a few ideas that I have seen (such as Evan Gardner and Willem Larsen’s work on accelerated group learning for language fluency), coding dojos, and other shared learning experiences.   As the group discussed various experiences they have had, we captured this list and discussed each one to get the basic ideas:

- Pair programming

- Code dojos

- Actually do stuff together

- Guilds (across team sharing at “role” level)

- ”Pair” coaching

- Coaching Circle

- Coaching dojo

- Observer, both as Learning and as Master

- Expose ideas using “What I did in a similar situation” wording

- Have a “Daily Focus” each day

- like continuous integrations, TDD, etc.

Metrics That Work – Our Journey From Ugly to Effective


- Rahil R. Patel (@freemarket)

List of Participants

- I had about 40 – 45 folks in the room

- I screwed up and didn’t take attendance.

Discussion and Recommendation:

Initial 10 minute monologue from me about our journey from the Early days of metrics centered around task hours and capacity planning through the ‘middle ages’ of metrics and then what we do today. We had an engaging conversation on what others are doing in their organization, and what’s working for them. We also discussed Metrics in the tactical context (Sprint Metrics) and the backlog context. We did run out of time to be able to discuss more on what does not work with participants and their organizations. A lot of great ideas surfaced and were discussed. I’ve provided my email to participants to feel free to contact me to continue discussing and give them examples (screen shots) of metrics that help us. I’m going to post my voice file later as I’m facing technical challenges with the file.











Grass roots Agile teams surviving in a strong PMO environment

Convener: Gary Moore

List of participants: Tuyen Tran; Niloufar Dasti; Ian L.; Aleks Gill; Alex Kidd; Charles He; Raoul Kaiser; Jeremy Perdue; Charlene Cuenca; John D.; Mimi Sulfridge; Dimitri De Nil; Grant Meyer; Jimmy Strobe; Dave Limbaugh; Merland Halisky; Elaine Bulloch; Tom Cagley; Jadish Karira; Carmen MacKinnon; Vivek M.

The session began with Gary sharing his observations at the company he is working with: In an effort to be more successful, the development organization adopted Agile/Scrum and self-organized into 12 teams. For several reasons, the Project Management Office resisted the necessary change for Agile to thrive and became more stronger over time. The Agile development organization has suffered since because of this. For the next ~30 minutes the attendees that were experiencing similar challenges at their companies shared with the other attendees. A small number of attendees that have had positive experiences shared during the last ~15 minutes.

Some observations from the discussion:

o Some level of change needed to occur in the PMO for Agile to thrive and it happened over a long period of time (2-3 years) o Strong upper management support was needed to allow Agile teams to be respected by the PMO

o In the absence of this, some deception was necessarily (e.g. a “second set of books” with PMI metrics were derived from Agile metrics) in order to communicate project status to the larger organization

o A strong definition of roles needs to be communicated and understood so PMs/POs/SMs don’t work at cross purposes

How to become CSC?!

Session Host: Andreas Schliep, Certified Scrum Coach & Trainer & Friends

Session members: [many]

About: Information and insights on how to become a Certified Scrum Coach.

Brief introduction to the CSC program, application prerequisites and process. More information:

Scrum of Scrums

Discussion focused around what folks are doing in terms of ceremonies at a scrum of scrums level. Most folks had some form of daily/weekly meeting of scrum of scrums, however having planning, demo, and retros at that level was much rarer.