Scrum DOES NOT Equal AGILE

Summary

本视频脚本讨论了敏捷开发过程及其误解。演讲者分享了他在不同公司使用敏捷方法的经验，包括所谓的'水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

00:00

😀 水平流程与敏捷实践的个人经历

本文段中，演讲者分享了自己对水平流程（Waterfall）和敏捷（Agile）方法的个人见解。他坦白自己从未在真正的水平流程中工作过，但曾在多个公司中以阶段门模型（Stage Gate Model）工作，这实际上是一种所谓的'水Scrum瀑布'（Water Scrum Fall）。演讲者还介绍了自己作为敏捷教练的经历，以及如何面对对敏捷流程持怀疑态度的人。他强调了敏捷宣言背后的12条原则，并指出敏捷的本质是关于原则而非严格的流程。

05:01

😕 敏捷宣言的误解与正确解读

在第二段中，演讲者讨论了敏捷宣言的四个核心价值点：个人和互动、工作的软件、客户合作以及对变化的响应。他指出这些原则经常被误解，举例说明了'半吊子敏捷软件开发宣言'（Manifesto for Half-assed Agile Software Development），并解释了这些原则的正确理解方式。演讲者强调，敏捷并不意味着没有计划，而是要接受计划的变化；合同谈判是可以接受的，但应该具有灵活性；工作软件比文档更重要，但文档仍然需要更新；最重要的是，个体和互动比流程和工具更为重要。

10:03

🤔 敏捷实践中的挑战与个体价值

第三段中，演讲者探讨了在敏捷实践中遇到的挑战，特别是如何真正地重视个体和他们之间的互动。他比喻了组织中的流程如同疤痕组织，指出过多的流程会导致组织变得不灵活。演讲者认为，应该通过增加个体间的沟通和互动来提高组织的敏捷性，而不是简单地增加流程和工具。他强调了每日站立会议的重要性，以及如何通过这些会议来促进团队成员之间的沟通和协作。

15:06

🛠️ 技术敏捷性与持续交付的重要性

在最后一段中，演讲者强调了技术敏捷性的重要性，并指出没有持续交付或至少是持续集成，就无法实现真正的敏捷性。他讨论了敏捷性的核心——检查和适应（Inspect and Adapt），并解释了为了适应变化，需要管理层和客户的信任，以及能够快速响应变化的技术基础设施。演讲者批评了一些组织只是表面上实行敏捷，但实际上并没有赋予团队必要的信任和勇气去改变软件。他总结了真正的敏捷性需要的要素，并鼓励观众探索更多关于团队合作和领导力的技术和方法。

Keywords

💡敏捷开发

敏捷开发是一种以人为核心、迭代、循序渐进的软件开发方法。它强调适应性、协作和对变化的快速响应。在视频中，敏捷开发被讨论为一种更灵活、更适应变化的软件开发方法，与传统的瀑布模型形成对比。

💡瀑布模型

瀑布模型是一种线性且顺序的软件开发方法，其中每个阶段必须在下一个阶段开始之前完全完成。视频中提到，尽管瀑布模型在某些情况下有其优势，如能够精确规划和设计，但在快速变化的环境中可能会显得不够灵活。

💡Scrum

Scrum是一种敏捷框架，用于开发和维护复杂产品。它强调迭代进展、持续改进，并在团队成员之间促进透明沟通。视频指出，Scrum是敏捷开发的一种形式，但并非敏捷的全部，也不是所有敏捷开发都必须采用Scrum。

💡敏捷原则

敏捷原则是指导敏捷开发实践的一系列价值观和原则，包括客户合作、响应变化、个体和互动的重要性等。视频中提到12条敏捷原则，它们是敏捷实践的核心，强调了与客户合作和响应变化的重要性。

💡持续交付

持续交付是一种软件开发实践，它允许开发团队频繁地向生产环境交付软件的更改。视频中强调，为了真正实现敏捷，团队需要有勇气和技术能力去不断交付和适应变化，这是敏捷开发的关键组成部分。

💡技术敏捷性

技术敏捷性指的是软件架构、代码质量和开发流程的灵活性，使得团队能够快速适应变化。视频中提到，没有技术敏捷性，就不可能实现真正的敏捷开发，因为它支持快速和频繁的软件交付。

💡每日立会

每日立会，或称日常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]