Experiences and learnings from AgileUnlimited

Bottom Line of Learning from the Road trip with Agile Unlimited

Mai 16 - Darmstadt

If someone is asking me what I have learned from my road trip with AgileUnlimited I would say: "I learned especially two things:

I learned about the learning. Today I understand much better what constraints and environments support and motivate learning.
I learned from the method: The method of lean startup showed me that I am successful because I understand my customers job-to-be-done and my individual value proposition.

Learning empowered me to be and to do what I be and do today. The pattern of learning are always the same to me. My conclusion is sometimes we all schould be aware about our learning behavior and the environment that makes us curious, motivating and willing to learn.

Pattern of Learning

Agile Unlimited - an exceptional experience

Sep 15 - Munich

In August I joined eGym for full 2 weeks and it is safe to say that I was busy to the last minute during my time there. The company itself says: "Nadine's influence was such an exceptional experience, that we are sure to master our challenge of rapid growing more than ever before." Read more here.

Agile Unlimited is guest at the Agile Community of Goodgame Studios

Jul 15 - Hamburg

The Community Evening at Goodgame Studios was beginning with lounge music, fingerfood and cold beer. And we all (around 45 participants) enjoyed a really relaxed setup and atmosphere. Awesome start! Then I induced my talk. My goal was to take the auditory to a journey – to my own journey with Agile Unlimited. And I hope I was successful. At least the feedback was telling me I was. I talked about the proceeding with Lean Startup methods to go further with Agile Unlimited:

how I develop my journey in small iterations of testing my assumptions minimum viable.
And how I learn from my experiments

I also referred about the patterns I mentioned in different companies like large enterprises and former startups.

One questions driving the audience was for example:

Auditor: “Nadine, what is your opinion, if someone is saying the team is to young for a step towards to a change?”
Nadine: “There is no stage to young or to old or something in between to take a step towards change. Dump that. That is not the point. The point is, everything is changing all the time. As an Agile Coach it is your job first to be aware and to recognize actual pain points of a team. And second to support them and to lead them to an improvement.” One straight but true opinion of an auditor to that context was: “If you do not trust your team, forget everything else. Because in that case you can pack your bag and going home!”

Another question was:

Auditor: “Don’t you think that coaching of middle management is often to late or even missing?”
Nadine: “Yes. That’s true. But it depends on were the art of agile working was seeded. If the seed comes from middle management – coaching is often assured. If it comes from the teams, coaching of middle management is often missing or to late. I can definitely say, you never can change a culture, but you can create systemic environments and conditions where a culture pattern can emerge. The only chance to emerge is, to create the conditions an all levels.”

After a break, we started into the second part of the community evening - the World Café. I prepared eight tables with eight different questions to the topics education, employees, motivation and goals, leadership, processes, product development, innovation and salary. Great people of the Goodgame Agile Coaching Team and other Goodgamers (Florian Berninger, Magnus Hofer, Per Jochumsen, Holger Tewis, Karsten Müller, Mark Hersch, Adiya Kydyrbekova) were in charge of the tables as hosts.
During a ten minute break the participants already had the chance to walk around, having a look at the questions and deciding which table they like to start with. In three rounds, the participants were changing the tables every 20 minutes. The discussions were mostly great and inspiring. Some questions were performing better than others. Here is the recapitulation of the main points discussed at each table. It is a valuation of the hosts:

Table Motivation and Goals: “You know, each employee brings an intrinsic motivation. Which goals should be aligned and how?”

Understanding the individual preferences based on intrinsic motivation can help setting up teams: Complementing individual preferences will enable every team member to do more work that he likes.
Strong, well communicated and transparent (company, team and product/project) goals can result in a great, focused team spirit. With that in place, you will often benefit from intrinsic motivation as well.
Personal goals for employees should not be "pushed", instead they need to allow personal development in the direction of the employee’s preferences.

Table Employees: “How can we design a recruitment process centered around a self-organizing team?”

We started the discussion by placing the team in the middle of the process. The team recognizes the need for an additional member. Supported by a recruitment coach, that helps the team in identifying what they seek for in their new colleague, they draft acceptance criteria on a social as well as professional level. The team can then forward this information to a trusted recruitment facilitator, who selects suited individuals to be interviewed by the team. In the next step the colleague to be is integrated into the team. This can be done through a boot camp, pairing and/or a social event. This phase is used as a reality check and should show how well the" colleague to be" fits into the team. Afterwards the team decides if the individual will join the team or if they want to continue the recruitment process.

Table Salary: “You no longer get a salary but you will get 'everything you need. Everybody else does as well. What will happen?"

People will do only things, they are motivated to do
There will most probably be no competition and less envy

But the discussion turned out to be very hard to define what one needs. And it will be hard to ever leave such kind of a system if it is limited to just one company.

Table Learning: “Nobody is telling you anymore what you shell learn. How do you care about your self-improvement?”

We started with collecting different formats how to spread knowledge, like pair programming, hackathons, 20% time or community of practices.

Then we talked about the motivation for learning or if people would just stop learning at all, concluding that everybody intrinsically wants to learn. We concluded with a more radical discussion about what we need to do to stop learning at all.

Table Innovation: “From now on you have to manage the innovation in your company. What would you do?”
We came fast to the conclusion: to be truly innovative people need more freedom and support from superiors. They need to know that making mistakes is allowed, they should be driven out of their comfort zone, have the freedom to try out new things.
At a point we also realized that "stealing" and modifying something can lead to more innovation. Another component to encourage people to be more innovative is to provide them with the tools they need, so that if they come up with an idea they can write it down (whiteboards, markers, paper etc.)
People should be motivated to be creative, should have a vision and identifying with the company / team. They should also feel responsible for the product they create.

Table Leadership: “You do not have any boss telling you what to do. You are like everybody else member of a team in your company. How can that work?“
Teams need to have a certain kind of leader, but not certainly have a direct manager. Decisions will take longer if the whole team is involved but you will have a bigger commitment within the team. Several values, like Respect, Trust need to be given, so that the team can perform well. Roles or Job titles are not needed, but might be indirectly given by the skills a team member has. Conclusion: Teams need at least a direction where to go to - either from the outside or grown in the team.

Table Product Development: "All products in your company be seen as experiments. What impact does this have?"
All involved discussers at the table ‘Product Development’ were pointing out, that nobody is omniscient. But feedback is needed to get more and more secure about an assumption. Agile methods enable fast feedback. Sectors with a high demand on innovation appreciate this approach or better – have to, if they want to stay compatible.

Table processes: “The Wiki etc. in your company has been abolished. How do you organize your knowledge in the future?"
The group first tried to get to the bottom of why Wikis are bad: the are not updated continuously, the know how antiquates, search engines are bad, tags and labels are not used the right way. If knowledge can not be documented anymore, then the people should talk about it – make Story telling. Talking should migrate to tradition – should become normal – a culture. But is a culture easier to install than a Wiki? That’s not the point. What is more sustainable – a Wiki or a culture? We concluded the culture. There are a lot of companies out there not using Wikis. The old master and assistant pattern is to slow to relay knowledge. But the principle of pairing is a great way to do so. Pairing fosters skill know how and that can really replace Wikis. The discussion ended with an open question of how to advance the domain specific know how?

Tanks to all participants, organizers and motivators :-)

By the way, Goodgame also wrote a Blog about this evening. Read more here.

STYLIGHT meets the Agile Coach on tour - an Interview with Nadine

Jun 09 - Darmstadt

At STYLIGHT I visited the headquarters in march 2015 for one month as a freelance agile coach supporting the current Agile Coaches, Torsten and Manuel.

Incorporating the agile way of thinking, I did a little retrospective about freelancing at STYLIGHT. You can read more in the interview at the STYLIGHT Blog.

Agile Unlimited is Funding Social Projects & Organizations

Jun 08 - Darmstadt

It is important to me to feel and to live a lean spirit during being on the road with Agile Unlimited. That is why I do not take money for my work. Never mind what people out there think about my motivation and vision. What I get with Agile Unlimited is in comparison to money invaluable.

Agile Unlimited is

pure lean spirit,
learning from insights and incomparable teams and working environments in so many different companies with so many different people,
networking and getting contacts to people and companies in high speed,
having fun and doing what I like and love – being a passionated agile coach,
and getting better in so many things.

What I give to the companies with Agile Unlimited is an increment value by challenging, improving and evolving their business. Since April 2015 I started to ask the companies I worked for: „What is my work worth to you and would you pay me?” and “Would you donate an amount of money instead of paying me?” And I noticed they would and they do. So, on that track I like to mention three great donations companies and still universities were realizing.

Thank you so much:

Infomar systems: 2000 €
Stylight: 2000 €
eGym: 2000 €

The money was going to SOS-Kinderdörfer in Nepal and Bundesverband Kinderrheuma e.V.

Kick waste’s ass! Talk and Workshop about Lean Software Development Principles.

May 28 - Stylight, Munich

During my work with STYLIGHT in Munich I did a one hour Workshop about lean software development principles. The participants were especially software developer.

In my opinion it is absolutely essential to focus people on lean thinking in particular in a company that is actually growing. Lean spirit can be loose easily if more and more employees start to work in a company – communication is getting more complex, different requirements can result in building processes and standards to manage, roles begin to play a more important part and can construct new boundaries.

Referring to all seven lean software development principles, I was dedicating the workshop to the principle „Eliminate Waste“. It is a principle that development teams can look at very easily in their every day work.

The target of the hour was

the participants have understood the meaning and the impact of waste in Software development and in their daily work,
and they have sharpened their mind to detect and avoid that waste.

The elimination of waste is the primary goal of any lean system. In effect, lean declares war on waste – on any waste.

But what is waste? In the origin the term “Waste” comes from the lean production – as it was invented from Toyota. The original japanese word for waste is Muda. Muda stands for waste, uselessness and futility. Waste or muda is anything that does not have value or does not add value. Waste is something the customer will not pay for. Waste is hindering you doing your work. And waste hurts. Massive waste is occurring again and againg and again. You have pain with it. It drives you crazy. To make a long story short: Muda is Waste of money, brain and time.

There exist some domains of muda. And here are examples of what can drives you and your business crazy and has the potential to ruin you and your business: unnecessary output, input, or processing. It can be in the form of materials, stocks, equipment, facilities, manhours, utilities, documents, expenses, motion, and other activities that do not add value.

I let the participants go into groups of two and let them talking about muda in their daily work. I told them to be concrete in their examples. After 10 Minutes each pair presents their results to the others. It was amazing what they have identified. And we were talking about it.

A lot of the collected topics already were the consequence of a growing organization. At least the consequence of bounded thinking in the one and only team context and not beyond team limits. After realizing the sorts of waste I started to introduce the steps to effective waste elimination:

Make waste visible.
Be conscious of the waste.
Be accountable for the waste.
Measure the waste.
Eliminate or reduce the waste

In other words: Spot waste – then stop waste! Before one can stop waste, he should able to see it, recognize it as waste, identify who is responsible, and finally appreciate its size and magnitude. Waste that is not seen cannot be eliminated. When something is denied as waste, it also cannot be stopped. When one refuses to accept responsibility for the waste, then he will not eliminate it. Finally, when the waste is not measured, people may think it is small or trivial and therefore will not be motivated to stop it.

That is why it is so important that companies help their people to shape their personal mindset and the collective mindset as a crew to kick waste in the ass and getting things done that have value.

Recap of Agile Rhein Main User Group Meetup in may with the Talk about "Enter Agile Unlimited"

May 21 - Agile Rhein Main User Group at Seibert Media, Wiesbaden

Seibert Media was inviting me to talk about my experiment with Agile Unlimited at the meetup of the Agile Rhein Main User Group in may. I accepted: https://www.xing.com/events/mai-treffen-agile-usergroup-rhein-main-agile-unlimited-tour-nadine-haertel-1497268

I started the Meetup evening with the sentence „I am on the road - and this evening I will take you with me to that roadtrip.“ And I was! All present pepole where agile workers and they also are somewhere on a journey of change. I talked about all the experiences I made since I started Agile Unlimited. The experiences with

I use lean startup method to develop the experiment of Agile Unlimited

the experiment of Agile Unlimited itself,
the lean startup method I choose to develop it,
how I get around during my road trip,
the different learnings I had and the patterns I mentioned in companies and with agile working environments,
and last but not least the clashs I had with opinions and mindset of people.

The community reacts with a deep interest and value of Agile Unlimited. Questions the community members had and discussions we were launching were for example:

The community talk enriched my thoughts about the experiment of Agile Unlimited. But at the moment it is still an open end.

How do I start a job and what are the requirements?
How long would I work for an outside estimate?
What would I do, if their is a personal conflict in a team I’m mandated to challenge?
What levels of a company do I work with – teams, management, single persons or roles?
Can I imagine to work international?
How do I stand to „Agile“ as a term?
Do I know about anybody else who did such a road trip?
Can I imagine to write a book?
What question do I like to answer in the end of being on the road?
What do I think about future work environments?
What should be changed in politics and in our social system to change work environments in the direction of agile?
Can I imagine to work ever again for an enterprise?

Full of ideas and with new thesis I was going home. The next days I had to think about it. Especially about one question „What do I like to have answered in the end of being on the road?“ To me it is one oft the central questions to what I am doing and also of how I can validate it. I thank the Agile Rhein Main Community to that enriching evening. And after the feedback to my talk – enriching for both sides.

I am extremely looking forward to my next talk at 15th July 2015 in Hamburg with an affiliating workshop to the topic "What if... we had to work differently?": https://www.xing.com/events/journeyman-years-enter-the-agile-tour-unlimited-1561396

When companies mix project organization, agile roles and leadership tasks - How to reveal in a retrospective

Apr 20-22 - Infomar, Nuremberg

It happenes over and over again that I come across to one constellation in companies wich is bizarr to common sense but seems to be a taboo to crack: that is the combination of typical project management functions, together with agile methods and roles, mixed with leadership responsibilities. Not infrequently one person is owning up to 3 roles in parallel or one role is double casted – e.g. two people as Product Owner and both only 20% of their working time. And also not rarley and with respect to the retrospect prime directive from Norman Kerth, those companies are developing that constellations because they do not know better and they do not know how to switch to a succeding agile organization. Especially not in a scaling environment.

I encoutered a customer who had that described set-up when I worked with Martin Heider from infomar systems to deliver a Scrum and Backlog Refinement Workshop. Planned was a two day workshop. The attendees were the whole development team and all responsible project roles of one product line of that customer. Already during the morning of the first day massive impediments in the organization were revealed.

One trigger was the discussion about the agile roles and the meaning of empowerment.
Another trigger was the actual detail level of the existing product backlog and the insight who is really responsible to refine it => too many cooks poil the broth.

Both triggers were mirroring the attendees that they handicap themselves in communication, in responbilities and that „they do not work agile“. With that cognition we hit the biggest pain point of our customer. He was adopting that impediment and he was willing to work on. To do the job proberly we dedicated the second day to work on their role characteristics. To promote the biggest outome to our customer, Martin and I decided to use the following methods:

Format: We did a Retrospective because talking about roles needs a respectful society. The common purpuse was titled with: „What is the team of project responsibles able to do or able to avoid, so that the project tempo is increasing?“

Set the Stage: After establishing the Prime Directive we asked the attendees to walk on a line from zero to ten: „How strong is the actual organization slowing down the project?“ and then „How strong is your work effort and result slowing down through the actual project organization?“. It was interesting to see how the people think about their „self made“ organization and the stage was set.

Gather Data: The metaphor of the Sailing Boat (synonym to the development project) helped to brainstorm into two questions: „What is already helping you to increase project speed?“ (synonym to the wind) and „What is impeding you to increase project speed?“ (synonym to the anchor).

Generate Insights: The most weighty anchor were used to go further. We splitted the group into two working teams. The method of Star Fish helped to come more clear about the different role perception – from the role keeper as well as from the other team members around.

Decide what to do: We closed the working sessions with the Star Fish and defined the next steps together in common actions. Every working team was promoting its realizations and action points in the entire group. Our customer really brought the baken home. Together they decided action items to reduce redundance of roles and overhead in project organization. Further they commited how to empower the role of the Product Owner especially in creating a well product backlog.

Close the Retrospective: The team had the possibility to say thank you to each other as a reward to the last two days or further in the past. That method was giving the attendees an open tuning and a respectful closing. Well done :-)

Predictive Index - What else does a company wants to know about me?

Apr 13 - Goodgame Studios, Hamburg

Yes – it is important to know how good a job applicant is matching to the company and reverse. But how can you find out the best way? In a fantastic idea of a perfect constellation it is a question to answer from both sides. The applicant is choosing the company as well as the company is choosing the applicant.

Recurring I notice that more and more companies use extensive ressources and mechanisms to analyse their job aspirants before they get in touch with them. And I recognize the companies have more pull to demand data up front from the aspirants as the aspirants have. To me a real imbalance. It seems to me that a job candidate is in the role of a petitioner. And by the way, I do not like the word „applicant“ because it has virtually this petitionary smack. The company offers a job position, best case an esteeming part in their team. The job candidate offers the most valuable thing he has – himself.

It is valid that both sides check each other – qualifications and skills, character and values, benefits and profit. But be honest, there is a capital missmatch in the prerequisites how to receive information about each other. While the job candidate is using the job description, the website of the company and at the most some press releases, organizations are scanning the profile of an aspirant. They ask for vitae, testimonies, qualitfications, work experience and even your private interests. They use business-oriented social networking services like XING and LinkedIn to scan your profile, your contact list and your activities in communities. They ask for references and maybe talk to your previous employers. More and more used by organizations are skill and behavior test assessments. These tests should aid in the understanding of how employees, or candidates, will likely deal with employment situations and managerial styles. One example for that kind of test is the Pedictive Index (PI) method. The work candidate fills in a two-paged questionnaire. On the first page the candidate is evaluating what the job situation is expecting from him. The second page is for the purpose to evaluate your own personality and behaviour – idependant from the job (look at the picture).

Second page of Predictive Index: Nadine's evaluation of her own personality/behaviour – idependant from the job

I had to fill in the Predictive Index when Goodgame Studios started to contact me. The result of the questionnaire is a not self-explanatory diagram. Which means it has to be explained from a trained HR assistant. Goodgame Studios is using the result of the PI to guide the conversation at first contact and as an additional information about the candidate. I support that procedure. But what I do not like is

the situation or the feeling, that an organization is analyzing you in advance,
the fact that I have not the same or simular opportunities to find out more about the organization,
that I am not able to decide who is worth to hold that personal information about me and the results of the evaluation, and who not.

And who the hell is the owner of the data? At least that are personal facts about me.

My first reaction was. OK, I do it. But I also have some criteria I like to have a response to. So I asked back: „What would your employees answer on a scale of 0 (flat characteristic) to 6 (depth characteristic) to the following criteria“:

Vision of the organization
Agile values
Selforganization
Failure culture
Futher training and improvement

Work-life-balance
Readiness of change
Investment in technichal progress
Understanding of cusomer needs
Organizational processes

I got the response. Sad to say not in advance. But Goodgame Studios was adressing the criteria during our dialogue. That was very positive.

I decided to myself: in the future I will digging deeper into the self-evaluation of organizsations I am working with. Because I am interested in a suitable position and the right cultural environment as well as the organization is interested in finding the best candidate for the job and the right person for their team.

Succeeding with agile - the role model of Management

Mar 17 - Kegon, Wiesbaden

When I visited the people of Kegon, I found a ready welcome. It was one of their office fridays and I felt lucky that Kegon team was deeply interested in me, my agile history and progress, and the motivation behind the Agile Tour Unlimited.

I talked about the staying power and the continuous esteem of elemental movements in the direction of agile in a multicorporated enterprise like Deutsche Telekom. Kegon team was joining the question why – and in our discussion we started to analyze the reasons.We found the facts that Management is playing a key role in succeedeing with agile – Management is the damn linchpin. One decission of Management today can destroy the work of month in agile working environments tomorrow. On the other hand, one decision of Management can wing a massive change. Fact is that an agile transition project is always a journey and not a framework and that Management always has the power helping to succeed or to break that sensitive journey.

In a small company the way of agile transition is in my opinion not comparable to such in a multicorporated enterprise. Tell me - who is the source, the bearer and the believer of vision in a big enterprise? Be honest - the CEO of an international company is to far away from everything – from the people, from development, from impediments and also from management levels deeper than two levels under him/her. And these levels are the gist of the matter – we also say „bed of clay“ - because they conduct or block information as intensive they decide on. They are the bearers of vision and the employees will be loyal to their Management. The conclusion is the agility of a system follows the agility of its leadership.

OK. We know about the importance of middle management. But how can they be role models for agile working environments? I will not give an answer how to unit a group of managers. That is not the question. I will give the hint not to forget to work with middle Management. Help them to invest into the right principles and practices to deliver and develop their business model and to push quality. Find out about their needs and support them to get excellent in - with the help of agile. They are the role models for succeeding with agile.

The Agile Tour Unlimited polarizes - Coming up against scepticism!

FeB 04 - Darmstadt

As I started the idea of the Agile Tour Unlimited I was – I wouldn't say impartial – but I was convinced of my assumptions and that a lot of people, teams and companies welcome my offering. After now one month I mentioned my assumptions are true but people have a lot of questions and sometimes also impediments when they hear or read about the Agile Tour Unlimited. The reactions I was faced with:

"Don't be stupid – take money for your work!"
"What kind of business model do you drive?"
"I'm sorry but I can not support you. You would draw off my customer!"
Some great people I worked with in the past did not react at any time.
"Where is the obstacle to your work if you are for free?"
"I asked myself if your work stands for good quality if you are for free?"
"Sounds very mature. You can visit us if you are someday around!"

All of the people who made those remarks are fear of something and sceptical. The Agile Tour Unlimited polarizes. But I stay cool with that. And I wish "staying cool" to you, too. Nothing of what I offer is cryptographic or a snare I layed. I offer my experience, expertise and my motivation in 2015 for free to every company, startup and university that need help in agile working. This tour is an experiment. My capacity and my power comes from that independancy.

I am an Agile Coach with many years of experience. I am looking for new impressions and ideas in Agile work environments. In exchange I will challenge your business. So don't be shy and enter the Agile Tour Unlimited.

High perfomring Teams - challenges in distibuted and scaled environment

Jan 21 - tolino, Darmstadt

While I visited tolino I had an inspired conversation to Scum Master. We shared our point of view to high performing teams in scaled and distributed environment. In that context central question to me is what need teams to evolve, grow togehter and become high performing? It comes along with a continuous oscillation and flows into the feeling beeing a great and cool clique, developing a great and cool product. To create that environment the essential conditions are in my opinion on team level

right tools for development and
right atmosphere for team building.

Both is given to the tolino teams. Nevertheless the distributed teams have a much bigger challenge to perform. A dominant influence seem to be side effects to team building. The impediments are caused by softskill stuff like defects in communication, agreements, trust and knowing each other. These impediments are much stronger than in local teams. That is not a new insight. But what are the effects in a scaled team environment? Distribution amplifies the scaling effects!

Dependencies between the teams exist and distribution could lead to delay of shipping regarding the entire product
Customer, stakeholder and market have different perception of the product reliabilty because features are possibly not continuous delivered
Distributed teams have a disruptive oscillation: in a natural manner they compare with the "locals"

Such a development environment is a challenge to Scrum Master and has a lot of levers. But Scrum Master of tolino are aware and able to act.

The local teams at tolino have (in my sight) grand conditions to team building. And they savor it

sitting and being together in one and cool location with room for development
having on the one hand fixed team workplaces - on the other hand also opportunities to switch or running for silence
chilling in comfortable sofas and relaxing zones - at tolino in a cool industrial ambience
cooking and eating togehter in the kitchen with big table, if they want to
having a very good coffe machine :-)
playing the kicker in their freetime

I saw at tolino a great atmopsphere, people having fun, loving what they do and where they work.

Successful way of identifying a well structured initial Product Backlog

Jan 14 - Commerzbank, Frankfurt/Main

How do you define your initial Product Backlog? For starting development projects I suggest a joint procedure and involvement of all participants. At Commerzbank I helped to identify the Product Backlog for development of a new test management system. I helped to prepare and to facilitate that workshop. The workshop parameters

One day out of the building.
All involved people were invited - development Team, Product Owner, Scrum Master, Project Management and all involved stakeholder. In that case stakeholder are equivalent with customer. They use the system in the end and consist of Test Manager, Test Labor and Test Environment.
Nadine as independant and objective facilitator.

Up front the team already implemented a light prototype of a simple use case for a standard test scenario. I do not support that procedure. It ist not emergent and it is risky to produce waste. But the prototype was already there and why not using it. The procedure for the day:

Role playing game to identify the missing functionality on the fly based on the prototype. Some more use cases helped to went through.
While the role playing game I challenged open discussions of stakeholder. That helped to find out about their desire. Everything was documented on Post-its.
After testing each use case the backlog items were collected. I used Kano model to structure the stakeholder jobs-to-be-done in Must-be, attractive and one-dimensional features. Kano helped to unite stakeholder decisions to their partially different requirements and helped the Product Owner to understand the unconditional features.

The whole setting supports also getting to know each other much better, finding a mutual understanding of needs and jobs-to-be-done of customer and getting a joint understanding of terms in project context.

Misunterstood objective of a sprint review

Jan 07 - Commerzbank, Frankfurt/Main

While I prepared the kickoff workshop for a starting development team together with the Product Owner and Project Management of Commerzbank I realized that the involvement of stakeholders and customers has been misunderstood. As is often the case, I recognized that the Sprint Review is not used as useful as it could be. It shouldn't be used for reporting "look we did something" or "look we are on track" and it should not culminate in a presentation of the product increment by the team only. The Review is more like a workshop and a chance to let the customer test the product. Let them feel and touch the product and give them a trial. Through the Review the customer influence the product develpoment actively and keep it on track to cover the right Jobs To Be Done. If you do not, you risk that customer will trample the product under feet.