Why is Scrum so easy to understand but incredibly hard to master?
It’s been said that scrum is easy to understand, but incredibly hard to master. I don’t know if that’s true. I don’t think that scrum is easy to understand, there are thousands of books, videos, and blogs on the topic so it would be fair to say that scrum can be tough to understand.
Hard versus Easy
There appears to be a school of thought which concludes that if something is difficult to understand, and difficult to master, it must be broken or irrelevant.
I disagree with that.
Running 100 metres in an Olympic record time is incredibly difficult, and it would take me a great deal of time and effort to achieve that, but it doesn’t render that sport broken or irrelevant.
Some things simply take time to understand, implement, and master.
What makes scrum hard to master.
In many ways, it is our accumulated baggage that makes scrum hard to understand and implement.
If you walk into a startup environment, filled with heaps of recent
MIT
graduates (Massachusetts Institute of Technology) and a dynamic, agile leader leading the flock, you’re likely to find that agile and scrum would be quickly understood, adopted, and mastered within that environment.
If you walk into a bank that has 250 years of history, and you need to integrate the board members with senior managers, and mid-level managers, and junior managers, all the way through to the people who work at the coalface, it’s going to be hard.
If the people who work at the coalface haven’t seen an executive in all their time at the company, but frequently must follow instructions, policies, rules and ‘best practices’ passed down from those senior leaders and executives; it will be hard for that person to grasp the nature of agile leadership and how scrum develops autonomous, collaborative, and creative teams.
They simply have no frame of reference for agile, nor could they imagine taking a decision without getting approval or sign-off on that first. They couldn’t imagine taking the lead and speaking truth to power about what needs fixing, what resources they need, and what great would look like in future.
If they did that today, they would be fired or demoted.
So, adopting scrum and mastering the agile framework effectively depends on your frame of reference for work, product development, or even project management.
Transparency.
One of the pillars of empiricism, which is a foundation of scrum, is transparency.
Transparency means:
Making language transparent. Say what you mean and mean what you say.
Making jargon transparent. Everyone understands what you mean when you use a term.
Making plans transparent. What are we attempting and why does that matter.
Making strategy transparent. This is what we want to achieve, and this is why.
Making work transparent. This is what we are doing, this is how it is progressing.
And so forth.
Now, if your team all arrived from Intel, that would be ok because it is common practice to have OKRs (
Objectives and Key Results
) visible at all times. A kind of visual scoreboard for everyone to see what you are working on, how that aligns with strategic objectives, and how you are performing.
If you work in an organization where things are opaque, mistakes are swept under the rug, and senior managers build fiefdoms rather than strong team environments, adopting scrum is going to be really, really, really hard.
Consumption versus Comprehension
It is easy to read the words in the scrum guide, and straightforward to follow how the agile framework is structured.
It is hard to grasp how this came to be, the underlying principles, theory, and learning from agile environments that underpins Scrum.
It is even harder to apply these theories, principles, values, and concepts in a live environment where people are under pressure to deliver a working solution to a client every few weeks.
They are up against organizational policies and internal working agreements that are completely out of alignment with agile values and principles. Out of alignment with scrum values and philosophies.
In many ways, it’s a clash of culture.
Comprehension
What is the purpose of scrum?
What is the purpose of Empirical Process Control that underpins scrum?
What is the purpose of the scrum values?
What is the purpose of the Agile values?
What is the purpose of the Agile principles?
What is the purpose of each scrum artefact?
What is the purpose of each scrum event?
Do people understand and embody this strong sense of purpose, this deep connection to values and principles within your environment or do they go through the motions of scrum?
Do they embrace learning and use data and evidence to inform their decisions or is it an assumption or opinion developed behind closed doors?
Do they create environments that are psychologically safe, where people can speak truth to power and safely express their concerns, observations, and ideas?
In traditional environments, organizations value obedience, compliance, and diligence. In agile environments, we value collaboration, inspiration, and creativity. People who are committed to a purpose, a vision, and are inspired to deliver their best work in pursuit of that mission and purpose.
If you keep bumping into walls within your environment because of misalignment between agile values and principles with traditional management and project management policies, you don’t have a communication problem, you have a comprehension problem.
An Example of scrum going wrong.
In almost all the agile consulting calls I make, the one scrum event I see where people completely misunderstand the purpose of the event, is the sprint review.
The purpose of the sprint review is to figure out what needs to happen next.
Since the last sprint review:
The product has changed.
The business may have changed.
The customer needs or requirements may have changed.
The market may have changed.
And so forth.
How do these factors affect the product backlog?
If the product backlog is a transparent list and demonstration of our current understanding of what needs to happen next;
how does the past two (2) or four (4) week sprint affect that?
How does the feedback, review, and insight we receive from customers and product stakeholders affect that?
How does what we have learned, the data, and evidence affect that product backlog?
It is very seldom that I witness product development or scrum teams walking out of a sprint review with an updated product backlog.
If they understood the true purpose of the sprint review, in addition to receiving feedback and reviews from customers about what has been built in the sprint, they would be leveraging that event to inform what their priorities for the next sprint should be.
Most scrum teams simply demo the product, get limited or zero feedback on what has been built or what needs to happen next, and walk out with very little real insight or valuable information.
The difference between a superficial and deep understanding of scrum. One team walks out none the wiser about how to contribute value and increase customer satisfaction, customer acquisition, and customer retention. The other team hits the ball out of the park and is focused on value creation and backlog refinement before they even enter the next sprint.
Productive versus Effective.
This is why scrum isn’t easy to understand, you don’t just get it from browsing through the scrum guide. This is why it’s hard to do, it requires you to focus on every element of the journey and extract the maximum value from each event and artefact. This is why there is such a big difference between what different scrum teams are able to perform, achieve, and deliver.
This is why a cookie cutter approach to deploying and implementing scrum doesn’t work.
Organize around value creation.
Some people think this is frustrating, but for me, this is where the opportunities lie.
This is where competitive advantage lives.
Every company is unique and every team, within that organization, is unique. The customers they serve are unique, and the context within which they operate is unique. So, it isn’t always about price when it comes to pitching or delivering a product.
There is so much more to it than that.
If every company offered the exact same service, the exact same product, and so forth then there would probably be no need for your company. No need for your product. No need for your team.
It would all boil down to price, but it should never be about price, it should be about value.
When you structure the organize around value creation, bring the right people together, create the right team ethos, and grow your team’s capability and effectiveness, you are perfectly positioned to dominate the markets you serve.
You are perfectly positioned to disrupt competitors who have mediocre teams and limited internal capability. You are perfectly positioned to acquire, satisfy, and retain customers over the long-term.
So, is it hard to understand scrum? Yes. Is it hard to master scrum? Yes. Is it worth it? Yes.
About NKD Agility
Naked Agility is an #agile consultancy that specializes in #scrumtraining, #agilecoaching and #agileconsulting to help teams evolve, integrate, and continuously improve.
We recognize the positive impact that a happy AND inspired workforce can have on customer experience, and we actively help organizations to tap into the power of creative, collaborative, and high-performing teams that is unique to #agile and #scrum environments.
If you are interested in #agiletraining, visit
https://nkdagility.com/training/
If you have identified the need for #agilecoaching and #agileconsulting, visit
https://nkdagility.com/agile-consulting-coaching/
We would love to work with you.
#scrum #agile #scrumteam #agileprojectmanagement #agileproductdevelopment #projectmanagement #productdevelopment #agilecoach #agileconsultant #agiletraining #scrumtraining #scrumorg
foreign
so the question was
um why is Scrum so easy to understand
but incredibly difficult to master
and that that’s an interesting and
recently contentious one because there’s
there seems to be a prevailing
idea that if something is difficult and
hard and lots of people can’t do it
that it must be inherently broken
and to that I would say I I’m not gonna
win a hundred meters race in the
Olympics no matter how hard I try and
does that mean that that sport is
inherently broken no it just means that
I can’t do it I can try really hard and
I could probably with lots of practice
learn to run pretty fast without falling
on my face although that might be
difficult but the reality is that
um
um
it it it’s only difficult
because of our inherent baggage right
um if you think about the the
tayloristic practices of the past and
how they impose themselves throughout
the entire hierarchy of an organization
the entire structure of an organization
and we’re we’re talking about moving to
something different and scrum’s purpose
one of one of scrum’s purposes is
transparency
right it’s designed so that by
implementing it
it makes transparent
things that make empiricism difficult in
your organization
so it’s gonna be hard right because lots
of organizations are not set up for
accepting empiricism right many
organizations have vanity metrics have
have uh uh enforced ways of working that
work for one team over here somewhere
but don’t work for all of these other
teams so
um that idea that that scrum is easy to
understand I think is also has a little
bit of a fallacy because it’s not that
easy to understand if it was easy to
understand you wouldn’t have thousands
of books on the Chrome guide right it’s
it’s not easy to understand the the
it’s easy to read the words it’s fast to
read the words
but understanding the theory and first
principles that are embedded in there
understanding the the the like what are
we at what is the purpose
for for each of the events what are we
supposed to get out of it because almost
almost all
um of the events that teams do that I go
see
um are are don’t fulfill the purpose
described in the Chrome guide right
um a good example of that is the the
Sprint review
um the purpose of the Sprint review
is to figure out what’s next
it’s to to to take into account since
the last Sprint review the product has
changed the business has changed
right they might change their mind they
might change direction the market might
have changed
how did those things affect the
transparency of the product backlog If
the product backlog is meant to be a
transparent list of our current best
understanding of what’s next
how does what’s happened in the last two
weeks affect that
and and very rarely do I find teams
actually walking out of Sprint planning
with an updated product backlog right
with with that information embedded in
there they’ve they’ve reordered the
backlog with the stakeholders they’ve uh
brought in that information they’ve
asked the right questions what I see
most teams do is they demo the product
ask for feedback they don’t get any
feedback or limited feedback or that one
person that shouts and then they’re done
that’s not a Sprint review right so
that’s that’s why it’s it’s not easy to
understand and it’s not hard to do sorry
yeah it’s not easy to understand it’s
hard to do and the outcomes that people
get are so varied because of those
incompatibilities between what people
interpret as The Thing versus the actual
thing and that that I think is
um
it’s not it’s I was going to say that
that’s frustrating right but I don’t
think it is I think it’s part of the fun
right it’s it’s how do we how do we how
every company need every company and
every team needs to be unique otherwise
there’s no point in them being there
right if I can just get another team to
do it or another company to provide that
product why would I use your company
versus that company it all comes down to
price right it shouldn’t be about price
it’s about value that’s being delivered
how do you create an organizational
structure how do you create a team ethos
a product that is unique and distinct in
the markets so that you build more value
and that that that’s that’s these unique
interpretations of the scrum guide these
unique uh practices that you add to the
scrum guide scrum’s just a little
rulebook right it’s like when you go out
and buy Monopoly it comes with a rule
book not a strategy guide you need to
add those strategies you need to figure
out based on the game that we’re playing
of Building Products potentially
software
what are the tools that I need to make
that successful what are the additional
practices I need to add to make that
successful what are the choices I have
and the way I do it that makes me my
product and my team distinctive in the
marketplace so that more people want my
stuff than my competitor’s stuff that
for me is is is is is why
scrum is easy to understand but
incredibly difficult to master because
products are doing businesses
thanks for watching the video If you
enjoyed it please like follow And
subscribe I always reply to comments and
if you want to have a chat about this or
anything else agile scrum or devops then
please book a coffee with me through
naked agility
Die Frage war also: Warum ist Scrum so leicht zu verstehen, aber unglaublich schwer zu meistern? Und das ist eine interessante und in letzter Zeit umstrittene Frage, denn es scheint die Vorstellung vorzuherrschen, dass, wenn etwas schwierig und schwer ist und viele Leute es nicht schaffen, es von Natur aus kaputt sein muss.
Dem würde ich entgegenhalten, dass ich bei den Olympischen Spielen keinen Hundertmeterlauf gewinnen werde, egal wie sehr ich mich anstrenge. Bedeutet das, dass dieser Sport von Natur aus kaputt ist? Nein, es bedeutet nur, dass ich es nicht schaffe. Ich kann mich wirklich anstrengen, und mit viel Übung könnte ich wahrscheinlich lernen, ziemlich schnell zu laufen, ohne auf die Nase zu fallen, auch wenn das schwierig sein könnte. Aber die Realität ist, dass es nur deshalb so schwierig ist, weil wir so viel Ballast mit uns herumschleppen, nicht wahr?
Denken Sie nur an die tayloristischen Praktiken der Vergangenheit und wie sie sich in der gesamten Hierarchie eines Unternehmens, in der gesamten Struktur eines Unternehmens durchsetzen. Und wir sprechen davon, dass wir zu etwas anderem übergehen wollen. Und das Ziel von Scrum, eines der Ziele von Scrum ist Transparenz, richtig? Es ist so konzipiert, dass es durch die Implementierung Dinge transparent macht, die Empirie in Ihrer Organisation schwierig machen.
Es wird also schwierig sein, richtig? Denn viele Organisationen sind nicht darauf eingerichtet, Empirie zu akzeptieren, richtig, viele Organisationen haben Eitelkeitsmetriken, haben Arbeitsweisen erzwungen, die für ein Team hier drüben irgendwo funktionieren, aber nicht für all diese anderen Teams. Die Vorstellung, dass Scrum leicht zu verstehen ist, ist meiner Meinung nach auch ein kleiner Trugschluss, denn es ist nicht so leicht zu verstehen. Wenn es einfach zu verstehen wäre, gäbe es nicht Tausende von Büchern über den Scrum Guide, oder? Es ist nicht leicht zu verstehen.
Es ist einfach, die Worte zu lesen, es ist schnell, die Worte zu lesen, aber die Theorie und die ersten Prinzipien zu verstehen, die darin eingebettet sind, zu verstehen, worum es geht, was der Zweck jedes einzelnen Ereignisses ist. Was sollen wir davon haben? Denn fast alle Veranstaltungen, die die Teams, die ich besuche, durchführen, erfüllen nicht den im Chrome-Leitfaden beschriebenen Zweck.
Ein gutes Beispiel dafür ist der Sprint-Review. Der Zweck des Sprint-Reviews ist es, herauszufinden, was als nächstes ansteht. Dabei ist zu beachten, dass sich das Produkt seit dem letzten Review verändert hat, dass sich das Geschäft verändert hat, richtig? Vielleicht haben sie ihre Meinung geändert, vielleicht haben sie die Richtung geändert, vielleicht hat sich der Markt verändert. Wie haben diese Dinge die Transparenz des Product Backlogs beeinflusst? Wenn das Produkt-Backlog eine transparente Liste unseres aktuellen Verständnisses dessen sein soll, was als Nächstes ansteht, wie wirkt sich dann das, was in den letzten zwei Wochen passiert ist, darauf aus?
Und sehr selten finde ich Teams, die aus der Sprintplanung mit einem aktualisierten Product Backlog herausgehen, richtig? Sie haben das Backlog zusammen mit den Stakeholdern neu geordnet und diese Informationen eingebracht. Sie haben diese Informationen eingebracht. Sie haben die richtigen Fragen gestellt. Die meisten Teams stellen das Produkt vor und bitten um Feedback. Sie bekommen kein oder nur wenig Feedback oder eine Person, die sie anschreit, und dann sind sie fertig. Das ist kein Sprint-Review, richtig? Deshalb ist es nicht leicht zu verstehen und nicht schwer zu machen. Entschuldigung. Ja. Es ist schwer zu verstehen, es ist schwer zu machen, und die Ergebnisse, die die Leute bekommen, sind so unterschiedlich, weil diese Unvereinbarkeiten zwischen dem, was die Leute als die Sache interpretieren, und der tatsächlichen Sache bestehen.
Und das ist, meiner Meinung nach, nicht das, was ich sagen wollte, das ist frustrierend, oder? Aber ich denke nicht, dass es das ist. Ich denke, das ist Teil des Spasses, oder? Es geht darum, wie wir, wie wir, wie jedes Unternehmen, jedes Unternehmen und jedes Team einzigartig sein muss. Andernfalls hat es keinen Sinn, dass sie da sind, oder? Wenn ich einfach ein anderes Team oder ein anderes Unternehmen beauftragen kann, um das Produkt zu liefern, warum sollte ich dann Ihr Unternehmen beauftragen und nicht jenes? Es läuft alles auf den Preis hinaus, oder? Es sollte nicht um den Preis gehen. Es geht um den Wert, der geliefert wird.
Wie schaffen Sie eine Organisationsstruktur? Wie schaffen Sie ein Team-Ethos, ein einzigartiges und unverwechselbares Produkt auf dem Markt, um mehr Wert zu schaffen und diese einzigartigen Interpretationen des Scrum-Guides. Diese einzigartigen Praktiken, die Sie dem Scrum-Leitfaden hinzufügen. Scrum ist nur ein kleines Regelbuch, richtig? Das ist so, wie wenn Sie Monopoly kaufen, das wird mit einem Regelbuch geliefert, nicht mit einem Strategiehandbuch. Sie müssen diese Strategien hinzufügen. Sie müssen herausfinden, welche Werkzeuge ich in dem Spiel, das wir bei der Entwicklung von Produkten, möglicherweise Software, spielen, brauche, um erfolgreich zu sein. Was sind die zusätzlichen Praktiken, die ich hinzufügen muss, um erfolgreich zu sein? Welche Möglichkeiten habe ich, um mich, mein Produkt und mein Team auf dem Markt hervorzuheben, so dass mehr Leute meine Produkte wollen als die der Konkurrenz?
Das ist für mich der Grund, warum Scrum leicht zu verstehen, aber unglaublich schwer zu meistern ist, weil Produkte Unternehmen sind. Danke, dass Sie sich das Video angesehen haben. Wenn es Ihnen gefallen hat, mögen, folgen und abonnieren Sie es bitte. Ich antworte immer auf Kommentare und wenn Sie sich mit mir über dieses oder ein anderes Thema aus den Bereichen Agile, Scrum oder DevOps unterhalten möchten, dann buchen Sie bitte einen Kaffee mit mir über Naked Agility.
So the question was, why is Scrum so easy to understand but incredibly difficult to master? And that’s an interesting and recently contentious one because there seems to be a prevailing idea that if something is difficult and hard and lots of people can’t do it, that it must be inherently broken.
And to that I would say I’m not going to win a hundred meters race in the Olympics no matter how hard I try and does that mean that that sport is inherently broken? No it just means that I can’t do it. I can try really hard and I could probably, with lots of practice, learn to run pretty fast without falling on my face, although that might be difficult.
But the reality is that it’s only difficult because of our inherent baggage, right? If you think about the Tayloristic practices of the past and how they impose themselves throughout the entire hierarchy of an organization, the entire structure of an organization. And we’re talking about moving to something different.
And Scrum’s purpose, one of Scrum’s purposes is transparency, right? It’s designed so that by implementing it, it makes transparent things that make empiricism difficult in your organization. So it’s gonna be hard, right? Because lots of organizations are not set up for accepting empiricism right many organizations have vanity metrics have enforced ways of working that work for one team over here somewhere but don’t work for all of these other teams.
So that idea that Scrum is easy to understand I think is also a little bit of a fallacy because it’s not that easy to understand. If it was easy to understand you wouldn’t have thousands of books on the Scrum Guide, right? It’s not easy to understand.
It’s easy to read the words, it’s fast to read the words, but understanding the theory and first principles that are embedded in there, understanding the, like, what are we at, what is the purpose for each of the events? What are we supposed to get out of it? Because almost all of the events that teams do that I go see don’t fulfill the purpose described in the Chrome guide.
A good example of that is the sprint review. The purpose of the sprint review is to figure out what’s next. It’s to take into account since the last sprint review, the product has changed, the business has changed, right? They might have changed their mind, they might have changed direction, the market might have changed.
How did those things affect the transparency of the product backlog? If the product backlog is meant to be a transparent list of our current best understanding of what’s next, how does what’s happened in the last two weeks affect that? And very rarely do I find teams actually walking out of sprint planning with an updated product backlog, right? With that information embedded in there, they’ve reordered the backlog with the stakeholders. They’ve brought in that information. They’ve asked the right questions.
What I see most teams do is they demo the product, ask for feedback. They don’t get any feedback or limited feedback or that one person that shouts, and then they’re done. That’s not a sprint review, right? So that’s why it’s not easy to understand and it’s not hard to do.
Sorry. Yeah. It’s not easy to understand, it’s hard to do, and the outcomes that people get are so varied because of those incompatibilities between what people interpret as the thing versus the actual thing.
And that, I think, is not it’s I was going to say, that’s frustrating, right? But I don’t think it is. I think it’s part of the fun, right? It’s how do we, how do we, how, every company need, every company and every team needs to be unique. Otherwise there’s no point in them being there, right? If I can just get another team to do it or another company to provide that product, why would I use your company versus that company?
It all comes down to price, right? It shouldn’t be about price. It’s about value that’s being delivered. How do you create an organizational structure? How do you create a team ethos, a product that is unique and distinct in the market so that you build more value and that that’s that’s these unique interpretations of the Scrum Guide.
These unique practices that you add to the Scrum guide. Scrum’s just a little rule book, right? It’s like when you go out and buy Monopoly, it comes with a rule book, not a strategy guide. You need to add those strategies. You need to figure out, based on the game that we’re playing of building products, potentially software, what are the tools that I need to make that successful?
What are the additional practices I need to add to make that successful? What are the choices I have in the way I do it that makes me, my product, and my team distinctive in the marketplace so that more people want my stuff than my competitors stuff. That for me is why Scrum is easy to understand but incredibly difficult to master because products are doing businesses.
Thanks for watching the video. If you enjoyed it please like, follow and subscribe. I always reply to comments and if you want to have a chat about this or anything else Agile, Scrum or DevOps then please book a coffee with me through Naked Agility.
Así que la pregunta era, ¿por qué Scrum es tan fácil de entender, pero increíblemente difícil de dominar? Y eso es una interesante y recientemente polémico porque parece que hay una idea predominante de que si algo es difícil y duro y un montón de gente no puede hacerlo, que debe ser inherentemente roto. Y yo diría que no voy a ganar una carrera de cien metros en las Olimpiadas por mucho que me esfuerce, ¿significa eso que ese deporte está intrínsecamente roto? No, sólo significa que no puedo hacerlo. Puedo esforzarme mucho y probablemente, con mucha práctica, podría aprender a correr bastante rápido sin caerme de bruces, aunque sería difícil.
Pero la realidad es que sólo es difícil debido a nuestro bagaje inherente, ¿verdad? Si piensas en las prácticas tayloristas del pasado y en cómo se imponen en toda la jerarquía de una organización, en toda la estructura de una organización. Y estamos hablando de pasar a algo diferente. Y el propósito de Scrum, uno de los propósitos de Scrum es la transparencia, ¿verdad? Está diseñado para que al implementarlo, haga transparentes cosas que hacen difícil el empirismo en tu organización.
Así que va a ser difícil, ¿verdad? Debido a que muchas organizaciones no están preparadas para aceptar el empirismo, muchas organizaciones tienen métricas de vanidad, han aplicado formas de trabajo que funcionan para un equipo por aquí en alguna parte, pero no funcionan para todos estos otros equipos. Así que esa idea de que Scrum es fácil de entender creo que es también un poco de una falacia, porque no es tan fácil de entender. Si fuera fácil de entender no tendrías miles de libros sobre la Guía Scrum, ¿verdad? No es fácil de entender.
Es fácil de leer las palabras, es rápido de leer las palabras, pero la comprensión de la teoría y los primeros principios que se incrustan allí, la comprensión de la, como, ¿qué estamos, cuál es el propósito de cada uno de los eventos? ¿Qué se supone que debemos sacar de ello? Porque casi todos los eventos que hacen los equipos que yo voy a ver no cumplen el propósito descrito en la guía de Chrome. Un buen ejemplo de ello es la revisión del sprint. El propósito de la revisión del sprint es averiguar qué es lo siguiente. Es para tener en cuenta desde la última revisión del sprint, el producto ha cambiado, el negocio ha cambiado, ¿verdad? Podrían haber cambiado de opinión, podrían haber cambiado de dirección, el mercado podría haber cambiado.
¿Cómo afectan esas cosas a la transparencia del portafolio de productos? Si el backlog del producto es una lista transparente de nuestra mejor comprensión actual de lo que viene, ¿cómo afecta lo sucedido en las últimas dos semanas? Y muy rara vez encuentro equipos realmente salir de la planificación del sprint con un backlog del producto actualizado, ¿verdad? Con esa información incrustada allí, han reordenado el backlog con las partes interesadas. Han traído esa información. Han hecho las preguntas correctas. Lo que veo hacer a la mayoría de los equipos es demostrar el producto… No reciben ningún feedback, o reciben un feedback limitado, o esa persona que grita, y ya está. Eso no es una revisión del sprint, ¿verdad? Así que por eso no es fácil de entender y no es difícil de hacer. Lo siento.
Sí. No es fácil de entender, es difícil de hacer, y los resultados que la gente obtiene son tan variados debido a esas incompatibilidades entre lo que la gente interpreta como la cosa frente a la cosa real. Y eso, creo, no es lo que iba a decir, es frustrante, ¿verdad? Pero no creo que lo sea. Creo que es parte de la diversión, ¿verdad? Es cómo, cómo, cómo, cada empresa necesita, cada empresa y cada equipo necesita ser único. Si no, no tiene sentido que estén ahí, ¿verdad? Si puedo conseguir que otro equipo lo haga o que otra empresa me proporcione ese producto, ¿por qué utilizaría tu empresa en lugar de esa otra? Todo se reduce al precio, ¿no? No debería tratarse del precio. Se trata del valor que se ofrece.
¿Cómo se crea una estructura organizativa? ¿Cómo se crea un ethos de equipo, un producto que es único y distinto en el mercado para que usted construya más valor y que esas interpretaciones únicas de la Guía Scrum? Estas prácticas únicas que añades a la guía de Scrum. Scrum es sólo un pequeño libro de reglas, ¿verdad? Es como cuando sales y compras Monopoly, viene con un libro de reglas, no una guía de estrategias. Tienes que añadir esas estrategias. Hay que averiguar, basándose en el juego que estamos jugando de la construcción de productos, potencialmente software, ¿cuáles son las herramientas que necesito para hacer que tenga éxito? ¿Cuáles son las prácticas adicionales que necesito añadir para tener éxito? ¿Cuáles son las opciones que tengo en la forma en que lo hago que me hace, mi producto, y mi equipo distintivo en el mercado para que más gente quiere mis cosas que mis competidores cosas? Para mí es por eso que Scrum es fácil de entender, pero increíblemente difícil de dominar porque los productos están haciendo negocios.
Gracias por ver el vídeo. Si te ha gustado, por favor, dale a me gusta, sígueme y suscríbete. Siempre respondo a los comentarios y si quieres tener una charla sobre esto o cualquier otra cosa ágil, Scrum o DevOps entonces por favor reservar un café conmigo a través de agilidad desnuda.
La question était donc de savoir pourquoi Scrum est si facile à comprendre mais incroyablement difficile à maîtriser. C’est une question intéressante et récemment controversée parce qu’il semble y avoir une idée dominante selon laquelle si quelque chose est difficile et difficile et que beaucoup de gens ne peuvent pas le faire, c’est qu’il doit être intrinsèquement cassé.
À cela, je répondrai que je ne gagnerai pas une course de cent mètres aux Jeux olympiques, quels que soient mes efforts, et cela signifie-t-il que ce sport est intrinsèquement défectueux ? Non, cela signifie simplement que je ne peux pas le faire. Je peux essayer très fort et je pourrais probablement, avec beaucoup d’entraînement, apprendre à courir assez vite sans tomber sur la tête, même si c’est difficile. Mais la réalité est que c’est difficile qu’à cause de notre bagage inhérent, n’est-ce pas ?
Si vous pensez aux pratiques tayloristes du passé et à la manière dont elles s’imposent à toute la hiérarchie d’une organisation, à toute la structure d’une organisation. Et nous parlons de passer à quelque chose de différent. Et l’objectif de Scrum, l’un des objectifs de Scrum est la transparence, n’est-ce pas ? Il est conçu pour qu’en le mettant en œuvre, il rende transparentes les choses qui rendent l’empirisme difficile dans votre organisation.
Donc ça va être difficile, n’est-ce pas ? Parce que beaucoup d’organisations ne sont pas conçues pour accepter l’empirisme - beaucoup d’organisations ont des métriques de vanité, ont appliqué des méthodes de travail qui fonctionnent pour une équipe ici quelque part, mais qui ne fonctionnent pas pour toutes les autres équipes. Donc l’idée que Scrum est facile à comprendre est un peu fausse parce que ce n’est pas si facile à comprendre. Si c’était facile à comprendre, il n’y aurait pas des milliers de livres sur le Guide Scrum, n’est-ce pas ? Ce n’est pas facile à comprendre.
C’est facile de lire les mots, c’est rapide de lire les mots, mais comprendre la théorie et les premiers principes qui y sont intégrés, comprendre, par exemple, où nous en sommes, quel est le but de chacun des événements ? Qu’est-ce que nous sommes censés en retirer ? Parce que presque tous les événements que les équipes organisent et que je vois ne remplissent pas l’objectif décrit dans le guide Chrome. La revue de sprint en est un bon exemple. L’objectif de la revue de sprint est de déterminer ce qui va suivre. Il s’agit de prendre en compte le fait que depuis la dernière revue de sprint, le produit a changé, l’entreprise a changé, n’est-ce pas ? Ils ont peut-être changé d’avis, ils ont peut-être changé de direction, le marché a peut-être changé.
Comment ces éléments ont-ils affecté la transparence du carnet de commandes ? Si le carnet de commandes est censé être une liste transparente de notre meilleure compréhension actuelle de ce qui va suivre, comment ce qui s’est passé au cours des deux dernières semaines l’affecte-t-il ? Il est très rare que les équipes sortent de la planification du sprint avec un carnet de commandes mis à jour, n’est-ce pas ? Elles ont réorganisé le backlog avec les parties prenantes. Ils ont apporté ces informations. Ils ont posé les bonnes questions. La plupart des équipes font une démo du produit et demandent un feedback. Elles n’obtiennent aucun retour, ou un retour limité, ou encore une personne qui crie, et c’est fini. Ce n’est pas une revue de sprint, n’est-ce pas ? C’est pourquoi ce n’est pas facile à comprendre et ce n’est pas difficile à faire. Je suis désolé. Oui. Ce n’est pas facile à comprendre, c’est difficile à faire, et les résultats que les gens obtiennent sont si variés à cause de ces incompatibilités entre ce que les gens interprètent comme la chose et la chose réelle.
Je pense que ce n’est pas ce que j’allais dire, c’est frustrant, non ? Mais je ne pense pas que ce soit le cas. Je pense que cela fait partie du plaisir, non ? Il s’agit de savoir comment nous pouvons, comment nous pouvons, comment chaque entreprise a besoin, chaque entreprise et chaque équipe a besoin d’être unique. Sinon, ils n’ont aucune raison d’être là, non ? Si je peux demander à une autre équipe de le faire ou à une autre entreprise de fournir ce produit, pourquoi utiliserais-je votre entreprise plutôt qu’une autre ? Tout se résume au prix, non ? Ce n’est pas une question de prix. Ce qui compte, c’est la valeur apportée. Comment créer une structure organisationnelle ? Comment créer une éthique d’équipe, un produit unique et distinct sur le marché afin de créer plus de valeur et ces interprétations uniques du guide Scrum. Ces pratiques uniques que vous ajoutez au guide Scrum. Scrum n’est qu’un petit livre de règles, n’est-ce pas ? C’est comme lorsque vous achetez un Monopoly, il est livré avec un livre de règles, pas avec un guide de stratégie. Vous devez ajouter ces stratégies. Vous devez déterminer, sur la base du jeu auquel nous jouons en construisant des produits, potentiellement des logiciels, quels sont les outils dont j’ai besoin pour réussir ? Quelles sont les pratiques supplémentaires que je dois ajouter pour réussir ? Quels sont les choix qui s’offrent à moi dans ma façon de faire pour que mon produit, mon équipe et moi-même nous distinguions sur le marché et que plus de gens veuillent mes produits que ceux de mes concurrents.
Pour moi, c’est la raison pour laquelle Scrum est facile à comprendre mais incroyablement difficile à maîtriser parce que les produits font des affaires. Merci d’avoir regardé la vidéo. Si vous l’avez appréciée, n’hésitez pas à l’aimer, à la suivre et à vous abonner. Je réponds toujours aux commentaires et si vous voulez discuter de ce sujet ou de tout autre sujet concernant Agile, Scrum ou DevOps, n’hésitez pas à prendre un café avec moi par l’intermédiaire de Naked Agility.
Então, a pergunta era: por que o Scrum é tão fácil de entender, mas incrivelmente difícil de dominar?
E essa é uma questão interessante e recentemente controversa, porque parece haver uma ideia predominante de que, se algo é difícil e árduo e muitas pessoas não conseguem fazê-lo, isso deve ser inerentemente quebrado.
Eu diria que não vou ganhar uma corrida de cem metros nas Olimpíadas, não importa o quanto eu tente, e isso significa que esse esporte é inerentemente ruim? Não, significa apenas que não posso fazê-lo. Posso me esforçar muito e provavelmente, com muita prática, aprenderia a correr bem rápido sem cair de cara no chão, embora isso possa ser difícil.
Mas a realidade é que só é difícil por causa de nossa bagagem inerente, certo? Se você pensar nas práticas tayloristas do passado e em como elas se impõem em toda a hierarquia de uma organização, em toda a estrutura de uma organização. E estamos falando de mudar para algo diferente.
E o propósito do Scrum, um dos propósitos do Scrum é a transparência, certo? Ele foi projetado para que, ao implementá-lo, torne transparentes coisas que dificultam o empirismo em sua organização.
Vai ser difícil, certo? Porque muitas organizações não estão preparadas para aceitar o empirismo, certo? Muitas organizações têm métricas de vaidade, têm formas de trabalho impostas que funcionam para uma equipe em algum lugar, mas não funcionam para todas as outras equipes.
Portanto, a ideia de que o Scrum é fácil de entender também é um pouco falaciosa, porque não é tão fácil de entender. Se fosse fácil de entender, não haveria milhares de livros sobre o Guia do Scrum, certo? Não é fácil de entender.
É fácil ler as palavras, é rápido ler as palavras, mas entender a teoria e os primeiros princípios que estão embutidos nele, entender o que estamos fazendo, qual é o propósito de cada um dos eventos? O que devemos obter com isso? Porque quase todos os eventos que as equipes fazem e que eu vejo não cumprem o objetivo descrito no guia do Chrome.
Um bom exemplo disso é a revisão do sprint. O objetivo da revisão do sprint é descobrir o que vem a seguir. É preciso levar em conta que, desde a última revisão do sprint, o produto mudou, o negócio mudou, certo? Eles podem ter mudado de ideia, podem ter mudado de direção, o mercado pode ter mudado.
Como essas coisas afetaram a transparência do backlog do produto? Se o backlog do produto deve ser uma lista transparente do nosso melhor entendimento atual do que está por vir, como o que aconteceu nas últimas duas semanas afeta isso?
E muito raramente encontro equipes que realmente saem do planejamento de sprint com um backlog do produto atualizado, certo? Com essas informações incorporadas, eles reordenaram o backlog com as partes interessadas. Trouxeram essas informações. Fizeram as perguntas certas.
O que vejo a maioria das equipes fazer é demonstrar o produto e pedir feedback. Não recebem nenhum feedback, ou recebem um feedback limitado, ou aquela pessoa que grita, e então terminam. Isso não é uma revisão de sprint, certo? É por isso que não é fácil de entender e não é difícil de fazer. Desculpe-me.
Sim. Não é fácil de entender, é difícil de fazer, e os resultados que as pessoas obtêm são muito variados devido a essas incompatibilidades entre o que as pessoas interpretam como a coisa e a coisa real.
E isso, eu acho, não é frustrante, eu ia dizer, é frustrante, certo? Mas não acho que seja. Acho que isso faz parte da diversão, certo? É como nós, como nós, como cada empresa precisa, cada empresa e cada equipe precisa ser única. Caso contrário, não há motivo para estarem lá, certo?
Se eu puder contratar outra equipe para fazer isso ou outra empresa para fornecer esse produto, por que eu usaria a sua empresa em vez daquela? Tudo se resume a preço, certo? Não deveria ser uma questão de preço. O que importa é o valor que está sendo entregue.
Como criar uma estrutura organizacional? Como criar um ethos de equipe, um produto único e distinto no mercado, para gerar mais valor e interpretações exclusivas do Scrum Guide. Práticas exclusivas adicionadas ao Guia do Scrum.
O Scrum é apenas um pequeno livro de regras, certo? É como quando você compra o Monopoly, ele vem com um livro de regras, não com um guia de estratégias. É preciso adicionar essas estratégias. É preciso descobrir, com base no jogo que estamos jogando de criar produtos, potencialmente software, quais são as ferramentas necessárias para ter sucesso? Quais são as práticas adicionais para ser bem-sucedido?
Quais são as opções que tenho para tornar a mim, meu produto e minha equipe distintos no mercado, para que mais pessoas queiram meus produtos do que os da concorrência. Para mim, é por isso que o Scrum é fácil de entender, mas incrivelmente difícil de dominar, porque os produtos estão fazendo negócios.
Obrigado por assistir ao vídeo. Se você gostou, por favor, curta, siga e se inscreva. Eu sempre respondo aos comentários e, se você quiser conversar sobre isso ou qualquer outra coisa sobre Agile, Scrum ou DevOps, marque um café comigo por meio da Naked Agility.
æ以é®é¢æ¯，ä¸ºä» ä¹Scrum é£ä¹å®¹æç解，ä½ææ¡èµ· 来å´æ æ¯å°é¾？
è¿ä¸ªé®é¢å¾æææ，最è¿ä¹å¾æäºè®®，å 为人们似ä¹æ®é认为，å¦æä¸ä»¶äºå¾é¾å¾é¾，å¾å¤äººé½åä¸åˆ°，é£å®è¯å®。
天çå°±æ¯åçã
对æ¤，我æ³è¯´çæ¯，æ 论æå¤ä¹åªå，我é½ä¸å¯è½å¨å¥¥。
è¿ä¼ç¾ç±³èµè·ä¸è·è，è¿æ¯å¦æå³çè¿é¡¹è¿å¨æ¬è´¨？
ä¸å°±æ¯åç？ä¸，è¿åªæ¯æå³çæåä¸åˆ°ã
我å¯ä»¥é常åªåå°å°è¯，éè¿å¤§éç»ä¹ ，我ä¹è®¸å¯ä»¥。
å¦ä¼è·å¾å¾å¿«èä¸ä¼æå，尽管è¿å¯è½å¾é¾ã
ä½ç°å®æ¯。
é£å°±æ¯。
å°é¾åªæ¯å 为我们åºæç袱，对å？
å¦æä½ æ³ä¸æ³è¿å»çæ³°å主ä¹åæ³，æ³ä¸æ³å®ä»¬。
æ¯å¦ä½æèªå·±å¼ºå ç»æ´ä¸ªç»ç»çç级å¶åº¦，æ´ä¸ªç»ç»çç»æç。
è我们æ£å¨è°è®ºçæ¯åä¸åçæ¹ååå±。
Scrumçç®ç，Scrumçç®çä¹ä¸å°±æ¯éæ，对å§？
Scrumç设计åè¡·å°±æ¯éè¿å®æ½Scrum，让ç»ç»ä¸é£。
äºè®©ç»éªä¸»ä¹é¾ä»¥å®ç°çä¸è¥¿åå¾éæ。
æ以ä¼å¾é¾，对å§？å 为å¾å¤ç»ç»å¹¶ä¸æ¯ä¸ºæåç»éªä¸»ä¹。
è设ç«ç，å¾å¤ç»ç»é½æèè£çææ ，é½æ强å¶çå·¥。
ä½æ¹å¼，è¿äºæ¹å¼å¯¹è¿éçæ个å¢éææ，ä½å¯¹。
å
¶ä»å¢éå´æ æã
å æ¤，Scrumå¾å®¹æç解çæ³æ³æ认为ä¹æç¹è°¬è¯¯，å 为å®å¹¶ä¸é£ä¹å®¹æç解。
å¦æå®å¾å®¹æç解，ä½ å°±ä¸ä¼ææåä¸ä¸æ¬å
³äºScrumæåç书äº，对å§？
è¿å¹¶ä¸å®¹æç解。
读åè¯å¾å®¹æ，读åè¯ä¹å¾å¿«，ä½è¦ç解其ä¸è´å«çç论å。
é¦è¦åå，ç解我们å¨åä»ä¹，æ¯é¡¹æ´»å¨çç®çæ¯ä»ä¹？
我们åºè¯¥ä»ä¸å¾åˆ°ä»ä¹？å 为å ä¹ææ我å»çè¿çå¢é。
æ´»å¨é½æ²¡æ达到Chromeæåä¸æè¿°çç®çã
å²åºå®¡æ¥å°±æ¯ä¸ä¸ªå¾å¥½çä¾åã
å²åºå®¡æ¥çç®çæ¯æ¾åºä¸ä¸æ¥ç计åã
å®è¦èè到èªä¸æ¬¡å²åºå®¡æ¥ä»¥æ¥，产ååçäºå。
å，ä¸å¡åçäºåå，对å？ä»ä»¬å¯è½æ¹åäºæ³æ³，å¯è½æ¹åäº。
æ¹å，å¯è½æ¹åäºå¸åºã
è¿äºäºæ
对产å积åçéæ度æä»ä¹å½±å？å¦æ产å积åçç®。
çæ¯éæå°åˆåº我们å½å对ä¸ä¸æ¥å·¥ä½çæä½³ç解，é£。
ä¹è¿å»ä¸¤å¨åççäºæ
ä¼å¯¹å
¶äº§çä»ä¹å½±å？
我å¾å°çå°æå¢éå¨å®æå²åˆºè®¡åå，è¿å¸¦çæ´æ°ç产å积å，
对å？ä»ä»¬ä¸å©çç¸å
³è
ä¸èµ·éæ°æåºäºç§¯åå·¥ä½ã
ä»ä»¬å¼å
¥äºè¿äºä¿¡æ¯ã
ä»ä»¬æåºäºæ£ç¡®çé®é¢ã
我ç到大å¤æ°å¢éçåæ³æ¯，ä»ä»¬æ¼ç¤ºäº§å，å¾æ±åé¦ã
ä»ä»¬æ²¡æå¾å到ä»»ä½åé¦，æèä»ä»¬å¾å到çåé¦å¾æé，æ。
ä»ä»¬åªæä¸ä¸ªäººåäºä¸å£°，ç¶åä»ä»¬å°±å®äºäºã
è¿ä¸æ¯å²åºè¯å®¡，对å？æ以è¿å°±æ¯ä¸ºä»ä¹ä¸å®¹æç解。
，ä¹ä¸é¾åå°ã
æ±ææä¹æ¯åå·®ä¸å«ç，å 为人们对äºç©çç解ä¸å®é
。
äºç©ä¹é´åå¨çä¸ä¸è´ã
我æ³，è¿ä¸æ¯ææ³è¯´ç，è¿å¾ä»¤äººæ²®ä¸§，对å？ä½。
我ä¸è¿ä¹è®¤ä¸ºã
我è§å¾è¿æ¯ä¹è¶£çä¸é¨å，对å§？æ¯å®¶å
¬å¸，
æ¯ä¸ªå¢éé½éè¦ç¬ä¸æ äºã
å¦å就没æåå¨çæä¹äº，对å§？å¦ææå¯ä»¥æ¾å«。
çå¢éæ¥å，æè
æ¾å«çå
¬å¸æ¥æä¾äº§å，é£我为ä»。
ä¹è¿è¦ç¨ä½ çå
¬å¸，èä¸æ¯é£å®¶å
¬å¸å¢？è¿ä¸å。
é½å½ç»äºä»·æ ¼，对å§？è¿ä¸åºè¯¥æ¯ä»·æ ¼çé®é¢ã
å…³é®å¨äºæä¾çä»·å¼ã
å¦å建ç»ç»ç»æ？å¦åé ä¸ç§å¢éç²¾ç¥，一ç§å¨å¸。
åºä¸ç¬ä¸æ äº，åä¼ä¸åç产å，ä»èåé æ´å¤ä»·å¼，è¿å°±æ¯å¯¹《Scrumæå》çç¬ç¹è¯éã
ä½ å¨Scrumæåä¸æ·»å çè¿äºç¬ç¹å®è·µã
Scrumåªæ¯ä¸æ¬å°å°çè§å书，对å§？就好æ¯ä½ å»ä¹°《大å¯》。
ç¿，å®é带çæ¯ä¸æ¬è§å书，èä¸æ¯ä¸æ¬çç¥æåã
ä½ éè¦æ·»å è¿äºçç¥ã
ä½ éè¦ææ¸
æ¥，åºäº我们æ£å¨ç©çæ建产å（
å¯è½æ¯è½¯ä»¶）ç游æ，我éè¦åªäºå·¥å
·æè½è®©æ¸¸ææå？为。
äºåå¾æå，我è¿éè¦å¢å åªäºå®è·µ？我å¨å·¥ä½æ¹å¼ä¸æåª。
äºéæ©å¯ä»¥è®©我，
我ç产åå我çå¢éå¨å¸åºä¸ä¸ä¼ä¸å，ä»è让æ´å¤。
人éè¦我ç产å，èä¸æ¯我ç«äºå¯¹æç产å。
对我æ¥è¯´，è¿å°±æ¯ä¸ºä»ä¹Scrumå¾å®¹æç解，
，ä½å´å¾é¾ææ¡，å 为产åå°±æ¯å¨åçæã
è¯è°¢è§çè§é¢ã
å¦ææ¨å欢，请ç¹èµ，
关注å订é
ã
å¦æä½ æ³å我èèææ·，
ScrumæDevOps，请éè¿Naked Agilityä¸我约个æ¶é´åæ¯åå¡ã
