Session 15, 10:00am
Host: helene de Saint
Theme: How to add meaning and positive impact
using scrum and Open Space?
How to improve meaning and create a positive
work more fun
the workplace, have positive impact
games, including serious gaming
work in context
people and talking about their passion, trying to support them to get more from
How to build a community at work?
3.0: making your company a community (1.0: machine, 2.0 sports team, 3.0 agile
bottom up, more autonomy, teams are community and family
approach, with Scrum master protecting the team and its members
to start with Agile community you don’t have to be a star to express yourself,
everyone has a role
shared issues to create a common goal to join the community, something people can
want to share, to complain about, and want to do something about
Problems: when we
break the teams at end of the project: how to keep this feeling of belonging?
How to get control freak managers to change?
step: understand his purpose to better address it
he can be a conductor of an orchestra,
with no need to micromanage
him understand how he communicates
Problem: Managers in
France don’t give meaning or fun because they are afraid they will lose control
How to get managers to turn to Scrum?
some training on Scrum
a pilot with a manager willing to turn to scrum, then it contaminates other
him to trust people will meet his expectations, scrum board is very reinsuring
How to make sure Scrum is effective for people
to give their best and fulfill themselves at work?
manager, be a role model
people around you to develop, to express themselves
to learn to fail
little task and celebrating every small victory
them laugh before the daily scrum meeting
How to create collective fun and helping
others' achieve their goals?
team objective and team reward => Scrum: each squad has its own mission
people to be more specific about their mission and goal
How to have fun at work/in scrum projects?
the differences between fun and lack of commitment: Exemple of french
perception of fun vs work: Post-it war between buildings in la Defense, comments
showed perception that people werenot working while they were just having a
little fun to release stress
defined within team: fun is coming up more and more often
people need to be creative, and fun is creative
by example, no tie, colourful shirts for facilitator, scrum master etc
a name for the team, with a story, take a collective picture, find symbols,
play with metaphors, even internally
How to help people learn and develop?
is education of people: manager’s role is key
people out for lunch as on boarding, get to know them personally: You need to
know how people learn
Bootcamp to get people up to speed when they join the team
everything on the wall, visual thinking, transparency helps learning
How to increase efficiency in scrum and in meetings?
master is essential for this. Minimize mall pieces of time between meetings that
take a lot of efforts and frustration=> Idea: Core hours, between 11 to 2,
or all afternoon, when nobody can disturb people for meetings.
a good flow, give people more positive
give the people the possibility to control their day to day activity
people know better all the line of the project, what they are doing it for,
know all the people involved in the project
impact when manager comes regularly to check the project
put in some games or exercises, see Tasteacupcake website for agile tests.
can be powerful and useful. For instance: decide on fun Create punishment like
sing and dance when people are late, and on fun rewards if people all perform
the meeting with a song people like.
people a limited amount of time to talk in meetings and add a little jingle
when time is over for each person
of two feets, try to implement it in all meetings
- UX designers tend to well polish.
- “When we ship MVP it’s not usable.”
- Big up front design vs. agile approach.
- Difficult to describe UX with stories. (maybe Acceptance criteria, BDD definitions?)
- Changes in UI requested during sprint.
Possible acting points:
- Developers involved in early UX work. To verify implementation possibility.
- Challenge UX specialists to accept changes during project.
- User testing sessions during development.
- Explain possibilities of changes during development: When an usability problem is found, you’re able to change it during development.
Hypothetical team setup:
Multiple teams with 1 usability specialist “UX-Champion” each. He has the main focus to support team to define and implement user interface during sprint.
1 UX team with usability specialists focused on usability of product, definition of a style guide, user tests and so on. Per development team there is 1 “UX-Partner” defined to act as communication partner between development teams and usability team.
Hypothetical process (thanks to Mikkel Hansen):
Mikkel Hansen; Edvard Garcia; Magnus Dahlgren; Silvana Wasitova …
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:
Helene de Sant Front
Leon Cosmin Lupu
Maunicia de Caster Nanannete
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 …
Lead Agile Practitioner
Kuoni Global Travel Services
Phone: +447940 495987
- Convener: Sabine Canditt
- List of participants:
- Discussion and recommendations
- 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
- 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
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
Convener: Arto Eskelinen
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.
Convener: Suzanne Daigle firstname.lastname@example.org
List of Participants:
· Vincent Lasalle – email@example.com
· Georgana Georgieva – firstname.lastname@example.org
· Stefano Lucantoni – email@example.com
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.
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.
- 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…)
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
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.
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.
Photo of Final Participants' Names & Their Recommendations attached:
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 notLevel 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 hackathonLevel 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 architecturalOther 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.
Convener: Steve Carter
Participants: Stefanie Marinelli
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.
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.
Convener: Pentti Virtanen
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
- 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
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
- Jaroslav Orsag
- Yrian Reime (Norway)
- Alan from TopDanmark (Denmark)
- Wolfgang Richter (Italy)
- 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 (http://www.amazon.com/Five-Dysfunctions-Team-Large-Print/dp/0470580461)
- 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
Focusing on the user needs in Scrum
Med vänliga hälsningar
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.