Scrum DOES NOT Equal AGILE
Summary
TLDR本视频脚本讨论了敏捷开发过程及其误解。演讲者分享了他在不同公司使用敏捷方法的经验,包括所谓的'水Scrum瀑布'模型。他强调了敏捷宣言背后的12个原则,解释了这些原则如何被误解,以及如何正确地实现敏捷。演讲者还讨论了在组织中引入敏捷性的挑战,包括信任、勇气和持续交付的重要性。他指出,没有技术敏捷性,真正的敏捷性是不可能实现的,而持续交付是实现敏捷性的关键。
Takeaways
- 😀 作者在多个公司中工作,这些公司虽然采用敏捷方法,但通常不承认其为瀑布模型(Waterfall)的一种变体,即所谓的'Water Scrum Fall'。
- 🔧 作者在20多年前作为开发者工作时,公司采用了极限编程(XP)和配对编程等敏捷实践,而作者的第一份教师工作是教授Java编程,采用的是瀑布模型。
- 🤔 尽管作者现在对瀑布模型持批评态度,但当时并未看到问题,这反映了对敏捷和瀑布模型理解的演变。
- 👨🏫 作为敏捷教练,作者在过去10年或更长时间里帮助组织采用敏捷流程,但并非所有敏捷教练都能改变管理层决定的流程。
- 📝 敏捷宣言背后的12条原则经常被忽视,人们更倾向于记住敏捷宣言中的四个价值观。
- 💡 敏捷宣言的价值观有时会被误解,例如'响应变化'被错误地解释为不需要计划。
- 🔗 作者强调,敏捷宣言中的价值观并不意味着放弃计划或文档,而是强调在计划和文档需要时能够适应变化。
- 👥 敏捷宣言中强调的'个体和互动'比流程和工具更重要,但实践中往往因为沟通困难而倾向于增加流程和工具。
- 🌐 技术敏捷性是实现真正敏捷的关键,没有持续交付或集成的支持,敏捷开发将无法实现。
- 🚫 作者批评了一些组织只是表面上采用敏捷实践,如每日站立会议和使用JIRA等工具,但没有给予团队信任和勇气去真正地适应变化。
- 🔄 敏捷的核心是'检查和适应',这意味着需要定期检查工作进展并根据反馈进行调整。
Q & A
什么是敏捷开发中的'water scrum fall'?
-在敏捷开发中,'water scrum fall'是指一种混合了传统瀑布模型和敏捷开发的实践。它通常包括大量的前期分析、一些敏捷迭代,然后是大量的测试和集成。这是一种在阶段门模型中工作的方式,但并非真正的敏捷。
脚本中提到的'stage gate model'是什么?
-'Stage gate model'是一种产品开发流程,它将开发过程划分为多个阶段,每个阶段结束时都有一个决策点或'gate',以决定项目是否应该继续进行。这有助于管理风险并确保项目按计划进行。
脚本中提到的'XP'是指什么?
-'XP'指的是极限编程(Extreme Programming),它是一种敏捷软件开发方法,强调技术实践,如测试驱动开发、持续集成、结对编程和重构。
为什么脚本中的演讲者最初认为瀑布模型没有问题?
-演讲者最初认为瀑布模型没有问题,因为他当时年轻,需要工作,而且他认为瀑布模型允许人们精确地计划他们想要制作的东西,然后分析所需时间,设计,实现,集成,并最终得到一个完整的工作产品。
为什么Dave Thomas认为'敏捷已死'?
-Dave Thomas认为'敏捷已死'是因为他观察到人们使用敏捷流程的方式已经不起作用了。他提倡应该更多地关注敏捷原则背后的思想,而不是严格遵循敏捷流程。
敏捷宣言中的12个原则是什么?
-敏捷宣言中的12个原则包括:1) 优先满足客户通过早期和持续交付有价值的软件;2) 欢迎在开发过程中改变需求;3) 频繁交付可工作的软件;4) 商业人员和开发者必须每天一起工作;5) 围绕有动力的个体构建项目;6) 面对面交谈是最有效的信息传递方式;7) 可工作的软件是开发的首要指标;8) 敏捷流程促进可持续发展;9) 持续关注技术卓越和良好设计;10) 简化工作是至关重要的;11) 最好的架构、需求和设计来自自组织团队;12) 定期回顾并调整行为。
脚本中提到的'Manifesto for Half-assed Agile Software Development'是什么?
-'Manifesto for Half-assed Agile Software Development'是由Kerry Buckley创造的一个幽默的敏捷宣言版本,它通过添加一些额外的文本来讽刺那些只遵循敏捷宣言的字面意义而不真正理解其背后原则的实践。
为什么脚本中的演讲者认为'响应变化'比'遵循计划'更重要?
-演讲者认为'响应变化'比'遵循计划'更重要,因为即使有计划,也应该接受对计划的变更。敏捷并不意味着没有计划,而是意味着如果计划有变更,应该拥抱这些变更。
脚本中提到的'技术敏捷性'是什么?
-技术敏捷性是指在软件开发过程中,团队能够快速适应变化并持续交付高质量软件的能力。这包括拥有良好的测试基础设施、自动化工具和持续集成/持续交付的实践。
为什么脚本中的演讲者认为'每日立会'(Daily Scrum)很重要?
-演讲者认为'每日立会'很重要,因为它是一个沟通的平台,团队成员可以讨论他们需要帮助的事情、提出问题或分享他们的疑惑。这些短会议对于团队协作至关重要,有助于确保项目按正确的方向前进。
脚本中提到的'AINO'是什么意思?
-'AINO'是'Agile In Name Only'的缩写,意思是表面上声称是敏捷的,但实际上并没有真正实施敏捷的原则和实践,只是名义上的敏捷。
Outlines
😀 水平流程与敏捷实践的个人经历
本文段中,演讲者分享了自己对水平流程(Waterfall)和敏捷(Agile)方法的个人见解。他坦白自己从未在真正的水平流程中工作过,但曾在多个公司中以阶段门模型(Stage Gate Model)工作,这实际上是一种所谓的'水Scrum瀑布'(Water Scrum Fall)。演讲者还介绍了自己作为敏捷教练的经历,以及如何面对对敏捷流程持怀疑态度的人。他强调了敏捷宣言背后的12条原则,并指出敏捷的本质是关于原则而非严格的流程。
😕 敏捷宣言的误解与正确解读
在第二段中,演讲者讨论了敏捷宣言的四个核心价值点:个人和互动、工作的软件、客户合作以及对变化的响应。他指出这些原则经常被误解,举例说明了'半吊子敏捷软件开发宣言'(Manifesto for Half-assed Agile Software Development),并解释了这些原则的正确理解方式。演讲者强调,敏捷并不意味着没有计划,而是要接受计划的变化;合同谈判是可以接受的,但应该具有灵活性;工作软件比文档更重要,但文档仍然需要更新;最重要的是,个体和互动比流程和工具更为重要。
🤔 敏捷实践中的挑战与个体价值
第三段中,演讲者探讨了在敏捷实践中遇到的挑战,特别是如何真正地重视个体和他们之间的互动。他比喻了组织中的流程如同疤痕组织,指出过多的流程会导致组织变得不灵活。演讲者认为,应该通过增加个体间的沟通和互动来提高组织的敏捷性,而不是简单地增加流程和工具。他强调了每日站立会议的重要性,以及如何通过这些会议来促进团队成员之间的沟通和协作。
🛠️ 技术敏捷性与持续交付的重要性
在最后一段中,演讲者强调了技术敏捷性的重要性,并指出没有持续交付或至少是持续集成,就无法实现真正的敏捷性。他讨论了敏捷性的核心——检查和适应(Inspect and Adapt),并解释了为了适应变化,需要管理层和客户的信任,以及能够快速响应变化的技术基础设施。演讲者批评了一些组织只是表面上实行敏捷,但实际上并没有赋予团队必要的信任和勇气去改变软件。他总结了真正的敏捷性需要的要素,并鼓励观众探索更多关于团队合作和领导力的技术和方法。
Mindmap
Keywords
💡敏捷开发
💡瀑布模型
💡Scrum
💡敏捷原则
💡持续交付
💡技术敏捷性
💡每日立会
💡个体和互动
💡工作软件
💡客户合作
💡响应变化
Highlights
作者在多个公司中实践了敏捷开发,并称之为'water scrum fall',即前期大量分析,中间敏捷迭代,后期测试集成。
作为开发者超过20年,作者最初在一个纯敏捷流程中工作,使用XP和结对编程。
作者曾作为教师教授Java编程,当时使用的是Rock过程,这是一种典型的瀑布模型。
作者对瀑布模型的看法有了变化,从最初的认同到后来的尴尬和批判。
作为敏捷教练,作者在过去10年中帮助组织采用敏捷流程。
敏捷宣言的12条原则被提出,强调客户满意度、变更需求的欢迎、频繁交付、团队协作等。
Dave Thomas提出敏捷已死,提倡更注重敏捷原则而非僵化的流程。
敏捷宣言的四大价值被解释,包括个体和互动、工作的软件、客户合作、应对变化。
作者批判了对敏捷宣言的误解,如认为敏捷不需要计划或文档。
强调敏捷流程中计划和文档的重要性,但需要适应变化。
讨论了敏捷合同的概念,强调合同需要一定的灵活性。
作者分享了如何向怀疑敏捷的人解释敏捷的价值和原则。
提到了敏捷流程中个体和互动的重要性,以及如何促进团队沟通。
作者讨论了如何通过日常站立会议促进团队成员之间的沟通。
敏捷不仅仅是Scrum,也不仅仅是使用特定的工具或流程。
敏捷的核心是检查和适应,需要透明度和能够快速响应变化。
作者强调了技术敏捷性的重要性,认为没有技术支持就无法真正实现敏捷。
最后,作者批判了一些组织只是名义上的敏捷,而没有真正赋予团队信任和勇气去改变。
Transcripts
I never worked in a waterfall process
well of course that's a lie I mean I've
never worked in a waterfall process
where we actually agreed and admitted to
it being a waterfall process
I've worked in numerous companies where
we worked agile within the gates in a
stage gate model
we had what people call water scrum fall
a lot of analysis up front some agile
iterations and then a lot of testing and
integration afterwards
foreign
Corey and I'm a co-host and Dave
Farley's continuous delivery Channel
welcome to this channel if you've not
been here before please hit subscribe
and if you enjoy the content today hit
like as well before we begin a thank you
to our Channel sponsors equal experts
try centers transfit and Ice panel all
of whom help us grow the channel and
provide products that align very well
with what we discussed in this channel
when I started working as a developer
more than 20 years ago we worked in a
purely agile process we worked with XP
we worked with pair programming we
worked very iteratively and in super
small increments smaller than two weeks
the company I worked for even designed
some pair programming tables with help
from Quebec ironically my first job as a
teacher in industry was actually to
teach Java programming in the Rock
process which is actually very much a
waterfall process
at the time I didn't think that that was
a problem at all even though we would
never work in such a process in our
company I could see the point of
waterfall process where you can actually
plan exactly what it is you want to make
and then you can analyze how long it
will take and you can make the design
and then you make the implementation and
then you put all implemented Parts
together and then everything works in
the end
at the time I couldn't really see a
problem with it and the people that I
was teaching this couldn't see a problem
with it either
of course I'm immensely embarrassed
about that now but I was young and I
needed the money now since I've been
working in some sort of agile way for
the past 20 years I should probably know
what to say to people who are skeptical
about RTL processes shouldn't I
especially since I've been an agile
coach for the past 10 years or more
and with an agile coach I mean somebody
that the management has invited into an
organization to make people work in the
agile process that they have decided
they should work with or at least that's
what most agile coaches do
I know that there are also some
adventurous agile coaches who go out and
modify the process that the management
decided that people should work under
they change it to something that fits
the developers better I think that's a
brilliant thing to do but you don't
always get that choice as an agile coach
not all agile coaches can do that so I
do understand that there's skepticism
around the concept of agile
I know that even Dave Thomas who was one
of the people who wrote that gel
Manifesto started talking about how
agile is dead more than 10 years ago
what he meant was that the way we're
using agile processes Now does not work
he says that agility is more interesting
but what does he mean by that he means
that instead of following an agile
process to the letter you should instead
think about the agile principles behind
it all there are 12 agile principles
the first is our highest priority is to
satisfy the customer through early and
continuous delivery of valuable software
number two
welcome changing requirements even late
in the development agile processes
harness change for the customers
competitive Advantage three deliver
working software frequently from a
couple of weeks to a couple of months
with preference to the shorter time
scale 4. business people and developers
must work together daily throughout the
project five build projects around
motivated individuals give them the
environment and support their need and
trust them to get the job done 6. the
most efficient and effective method of
conveying information to and within a
development team is face-to-face
conversation seven working software is
the primary measure of development eight
agile processes promote sustainable
development the sponsors developers and
users should be able to maintain a
constant Pace indefinitely
9. continuous attention to technical
excellence and good design enhances
agility 10. Simplicity the art of
maximizing the amount of work not done
is essential 11. the best architectures
requirements and Designs emerge from
self-organizing teams 12.
at regular intervals the tune reflects
on how to become more effective than
tunes and adjusts Its Behavior
accordingly that's basically
retrospectives
but unfortunately the 12 principles are
very long to read for people so they
don't read them
it's much easier just to look at the
agile Manifesto It's only got four
different points individuals and
interactions over processes and tools
working software over comprehensive
documentation customer collaboration
over contract negotiation and responding
to change over following a plan
these four points are easily
misunderstood in both directions
famously we have the manifesto for
half-assed agile software development by
Kerry Buckley this adds some extra text
to them for example responding to change
over following a plan provided a
detailed plan is in place to respond to
the change and it is followed precisely
the subtext to the manifesto for half
asked agile software development is
while the items on the left sound nice
in theory where an Enterprise company
and there's no way we're letting go of
the items on the right
but I also see skepticism arising from a
misunderstanding in the other direction
it's much easier just to read the agile
values and if we look at the last one we
value responding to change over
following a plan that is very easily
interpreted as when you do Agile you
don't need a plan
because of this we have people claiming
that when we are agile it's Anarchy
because we never plan anything and I
hear people laughing at me when we talk
about planning and they say oh I know
I'm sorry we're planning so we're not as
agile as you want this to be
it really makes me angry when people say
that but luckily I've worked with my
anger management so they don't notice
anything but the holes in the walls and
the hallways
but the point about this agile value is
that we value responding to change over
following a plan it doesn't mean that we
don't have a plan or that we don't try
to follow the plan agile doesn't mean
that you don't have a plan it means that
if you have a plan you should accept to
embrace changes to that plan
actually I think that making a plan is
brilliant no matter how agile you're
working it's a very good idea to think
things through as far as you can but
then you also have to accept that even
though you want to think things through
you shouldn't dive into analysis
paralysis and try to think about all the
different eventualities that might arise
in the future you should make an
overview of the plan and then the closer
you come to the different milestones in
the plan the more detailed the plan can
be it's a little bit like the way that
we look at backlogs we say that the
tasks described in the backlog need to
be more and more precise the closer we
get to top priority of the backlog and
the further we are away from the top
priority the less detailed the tasks can
be described
but the problem is that people read the
principles in a shallow way and
misunderstand what being agile is about
because they just see that oh we can't
follow a plan so that was my rant about
0.4 in the agile Manifesto next I'm
going to work backwards and tackle the
third we value customer collaboration
over contract negotiations oh okay so we
can't make contracts with our customers
you say
the only thing that we can do is chit
chat with the customers every other week
and that's the way that we can make the
system that's also not correct it's
quite okay to negotiate a contract but
when you are negotiating a contract with
somebody and you want to work in an
agile way then you of course have to
tell the customers that you're working
in an agile way and that means that
we're trying to learn and that we're now
creating the contract with some
flexibility there's a lot of debate
about agile contracts and I'm not going
to go into detail with them here
moving backwards in the agile Manifesto
the previous point is we value working
software over comprehensive
documentation
does that mean that we shouldn't
document anything no you've learned it
now no you can definitely create
documentation but you have again to
accept that the working software will
change and the documentation has to
change with it often the best way to do
that is to either make the documentation
in the code AS comments or some sort of
annotation so that it changes with the
code alternatively you just have to
revisit the documentation whenever you
change the software
otherwise the documentation will be
stale and nobody will read it and it
will have been a waste of time to create
it I know that some people have started
feeding their code into chat gbt and
then the chat GPT will actually make a
very nice documentation of their code it
could potentially be a bit dangerous
because you do not know where your code
goes when you give it to a chat bot but
if you don't care about that that might
be a way to actually keep your
documentation up to date and the last or
the first point is we value individuals
and interactions over processors and
tools and this is an interesting one
if it is true that we value individuals
and interactions over processors and
tools why is it then that some of the
agile coaches say that if you don't
follow this process completely then it
doesn't work why is it then that people
sometimes say that the toolger is what
makes the magical what happened there
the problem is I think that it's much
easier to use processes and tools and
have rules for those things than it is
to actually value individuals and
interactions between individuals when
you have some individuals that need to
communicate and you want to make sure
that they do it in the right way it's
much easier to make them follow a rule
set and then if something goes wrong
with the communication you're thinking
oh we should add some more rules to this
we should put some more processes into
this maybe we should use another tool to
check just how many hours you spend on
this task
and then something goes wrong again and
then they say oh we need more control we
need more processes we need more tools
and then what happens in an organization
like that is that processes are like
scar tissue an analogy is that if you
cut your hand your skin creates scar
tissue to make your skin A Little Bit
Stronger so that if you cut your hand
again it'll be more resilient and the
more you cut your hand the more Scar
Tissue you get on your hand but when you
get a lot of scar tissue you're not very
flexible anymore and rigid processes are
like scar tissue in an organization
whenever something goes wrong you create
another process in order to prevent this
failure from happening again but the
more processes you put into an
organization the less agile it gets and
that is why instead of just adding more
processes we actually need to add more
interaction and communication between
the people but that takes time and
that's difficult and it's easier just to
create more processes and for me that's
probably one of the things that it it's
most difficult about introducing agility
in an organization I can easily make
people understand that plans can change
by showing them how their own plans have
changed previously
I can show them that contract
negotiation is not as valuable as
customer collaboration and how it can
work better with demo sessions or better
reviews with stakeholders
it doesn't take many meetings to prove
that the value of what we do becomes
better with better communication and
they already know that comprehensive
documentation that is always right does
not exist and that working software is
the only thing that is correct all the
time but the last point about valuing
individuals in interactions that is the
hardest thing for me to convince people
of in an organization for some reason
people are not able to communicate about
things like API between systems or how
to hand over systems between developers
and operations and I know that there are
more organizations now where we have a
very good collaboration between
developers and operations but it's not
like that everywhere yet and in general
when people are placed in different
teams the other colleagues quickly
becomes the other people and
communication becomes harder but instead
of just creating more and more processes
and communication layers and tools
between these people what we should do
is that we should remove all these
things and enable them to communicate it
with each other to find a way for them
to communicate maybe even every day or
maybe every other day the actual human
beings need to communicate with each
other and to say out loud if something
is stalling them
and here it comes back to the Daily
scrum meeting the stand-up meeting that
some people hate for various reasons
they think that it's a complete waste of
time and some days you might not get
something out of the daily stand-up
meeting but the daily stand-up meeting
is there for a reason
and instead of just following the
process you should ask yourself why do
you have this meeting and what are you
supposed to get out of it you're not
having the daily stand-up to talk about
what you did in detail and not to talk
about how many meetings you're going to
today but it's a forum to talk about
things that you need help with or
questions that you have or things that
you're wondering about and having those
very short daily meetings is so
important for people to work together I
remember once I talked to somebody who
was a manager in a company that made a
new browser that was much quicker than
the existing browsers on the market
and I asked him if they were using an
agile process and he said no we hate
agile it's the worst it's a complete
waste of time okay I said so what are
you doing then how are you communicating
well obviously he said we're
communicating every morning just very
shortly just to make sure that we're on
the right path okay I say right okay how
do you make your plans well we do make
plans he said but we revisit them every
week just to make sure that we're going
in the right direction okay and how
about your communication with the
customer well of course we're
communicating with the customers we're
showing them what we have from time to
time so that we know whether we're going
in the right direction or not and we aim
to have the software always be shippable
we are shipping a new version to the
customer every few weeks and then I
asked him how is this not agile because
we're not doing scrum
and this is one of the biggest
misunderstandings to say that agile is
always scrum and scrum is always agile
you can definitely use scrum in an
waterfall process you can use scrum as a
way to support project managers into
seeing exactly what people are doing and
how many hours they're using it to do it
and you can plan Sprints months ahead of
time you can also definitely do Agile
development without using scrum or any
other documented process such as Crystal
dsdm ASD lean kanban XP or AUP the core
idea of agile besides all the principles
the values and the processes is inspect
and adapt if you are inspecting and
adapting to what you find out then you
are being agile
but in order to do that you actually
need to inspect you need to be able to
see how things are working so you need
that openness from the people working
perhaps that you're abort with the flow
or you need to have demos with the
stakeholder so you need to have
management knowing what's happening not
how many hours you've spent but what's
actually happening you need that
inspection and then you need to be able
to adapt to the situation and adapting
to the situation means that you can
react to What you see when you inspect
but the problem is that there are so
many things you need in order to be able
to adapt you need to trust from
management and you need trust from the
customers to change the functionality
that you promised into something that is
better
and you need the management to actually
invest in Agile development by
supporting continuous delivery because
if you do not have continuous delivery
or at least continuous integration you
cannot be agile
because in order to adapt the software
you need to have the courage to change
the software and in order to do that you
need to know that when you make a tiny
change somewhere it doesn't mess
everything up
so we actually need technical agile
support in order to be truly agile
there's no real agility without
technical agility and that means that
you have to strive for the continuous
delivery that this channel supports in
order to have real agility so
in summary I see organizations claiming
that they agile because they make people
stand up 15 minutes every morning and
they use jira or Asia devops but if you
do not give people the trust and courage
and testing infrastructure to change the
software you're missing the point and
then you're agile in name only which
acronym fondly is my name a-i-n-o
thank you for watching if you're
interested in learning more ideas and
techniques for teamwork and Leadership
and Tech teams check out our teamwork
and Leadership playlist that you can see
here
foreign
[Music]
تصفح المزيد من مقاطع الفيديو ذات الصلة
Unclogging the Retail Supply Chain
From Automated to Autonomous Supply Chains
12 Steps to a Resilient Enterprise
Lean vs Agile vs Waterfall | What is Lean | Difference between Waterfall and Agile | Intellipaat
From Traditional to Digital Supply Chain Networks - AWS
Generando Resiliencia en la Cadena de Suministro de la Industria Automotriz | CLIS
5.0 / 5 (0 votes)