I heard a lovely saying once and can't remember who said it. "They want Agile but they don't know what it is - so we give them Agile but we don't know what they want."
It sounds as if this is happening in your company. Someone, somewhere wants the team to use Scrum, but it's not the team.
That must be a difficult job for an SM, especially if you're doing it unofficially! There are some things I can suggest for you. First, learn some basic coaching techniques: positive language, GROW framework and giving and receiving feedback. This will give you some additional tools which are outside of Scrum and support someone in a leadership rather than a management position (even an unofficial SM can become a leader).
Then, don't worry about the actual practices. If someone has mandated Scrum then the team will be forced to do this anyway. Instead, concentrate on the values and principles of Scrum - particularly collaboration, communication and transparency. Help the team to work with each other instead of being silo'd away. You will have to be an example for them. Don't mandate pair programming, but do go over and pair. Don't mandate stand-ups, but do have conversations first thing in the morning and draw in as many people on the team as you can. Look at the principle of "Continuous Improvement". Learn how to do root cause analysis and the 5 Why's so that the team can understand better why things are hard and take action themselves.
Finally, I will echo @sjt. Don't commit Scrum suicide. However, if it's something you really want and your company aren't doing it in the right way, don't be afraid to look elsewhere. Learn some of the fundamentals, practice TDD on your own and find a new job.
Whatever you do, good luck! The first step to change is desire.
If you don't have buy in from your other developers its not going to work. Period.
Scrum requires a heap of discipline, especially during the early adoption phase.
I wouldn't be bothered that management don't care for it. If you're free to do the work of developing the software, and all they care about is results, then it shouldn't matter if you happen to have a 10 minute stand up each morning, and plan small chunks of the work into manageable bits, as long as you're hitting the targets they want you to hit.
If you're team isn't on board though, you're going to have a really hard time getting it working, and it will probably fail and cause more impact that not having tried at all.
If you can try to start it in a small project, with a few developers who are on board with the idea, then you can report back to the rest of your development team on how you found it works, what were the benefits and what were the negatives (reflecting is after all an important part of Scrum).
If you want to get your management on board, you might find that after doing a few projects this way you're much better at estimating the time it will take to develop the requirements you've been given by the PMs, hopefully being able to hit deadlines with more accuracy.
Remember, the PMs and BAs can still work in their normal way, once they've handed requirements to you, you're able to build them using Scrum. Its not ideal, but short of having the buy in of everyone, and the ability to speak directly to users and get them to help write user stories, it will be the best you've got.
When asked to estimate the time it will take to complete the project you can apply Scrum techniques. You can break the specifications down into smaller chunks, group them into sprints and develop them accordingly, hopefully yielding better results.
"I act as another SM, I want to change the current status"
Well, that's a good start right there, wanting to change the situation. Although I must say that without the management buy in, it will be tough. Try and arrange an experienced Scrum Speaker or Agile Coach come and do a presentation or workshop at your company which involves all the upper management. Once you have the management believing in Scrum, it will be all downhill from there.
"Team Leader act as a Scrum master, he controls all the things is our team"
This goes against the Self Organized and Self empowering Teams principle in Scrum. A good Scrum Master would empower the Team in a disciplined fashion within the Scrum Rules, to that appropriate level that, the Team should be able to run on it's own. One suggestion is that the Team Leads need to have a different mindset when working as a SM and different one while working as a Senior Developer, there are no Team Leads in a Scrum Team, only Scrum Team members. You cannot assign true leadership, that is a mutual role which can be earned by creating a reputation of helping others and mentoring others. Have them spit time between SM and development duties 30%, 70% or 50-50 or whatever you find appropriate. Command and control could be counter productive for the Team.
Our managers and team member are accustomed to the traditional management type, they do not care Scrum
A Scrum Trainer had told once told me, "Do not commit Scrum Suicide". If your managers do not care about Scrum, don't get fired trying to convince them. Whatever methodology you guys might follow or "not" follow, you have to realise that all this is a business. Your pay check is dependent on your boss's approval, if your boss or manager does not care about Scrum, then don;t do it. If they care about waterfall, Switch to it, do it like you care, but don't do Scrum halfway and call it scrum.
What has worked for me in the past is to identify and communicate pain-points. Certainly, you should never do something because Kent Beck told you to, especially something that will just get you fired. However, some smart people worked at figuring out a set of practices which is cohesive, and divergence from these practices almost always leads to pain points.
As just one example: if you do Scrum where you have a requirements iteration, a design iteration, an implementation iteration, and a testing iteration, this in theory could work but in practice never does. (When it does, it ends up being Waterfall, and the "iteration" notion becomes meaningless.) Pointing out to your boss that you learned something about the requirements while QA was testing might help him realize there's value in getting QA involved in requirements. Or finding risks in the software design by doing a small prototype may help to show why it might help to collapse the design iteration.
发布评论
评论（4）
我曾经听过一句好听的话，但不记得是谁说的了。 “他们想要敏捷，但他们不知道它是什么 - 所以我们给他们敏捷，但我们不知道他们想要什么。”
听起来这种事好像就发生在你的公司里。某个地方的某人希望团队使用 Scrum，但不是团队。
对于 SM 来说，这一定是一项艰巨的工作，尤其是如果你是非正式地做的话！我可以为您建议一些事情。首先，学习一些基本的辅导技巧：积极的语言、GROW 框架和提供和接收反馈。这将为您提供一些 Scrum 之外的额外工具，并支持处于领导地位而不是管理职位的人员（即使是非官方的 SM 也可以成为领导者）。
那么，不用担心实际的实践。如果有人强制执行 Scrum，那么团队无论如何都将被迫这样做。相反，专注于 Scrum 的价值观和原则 - 特别是协作、沟通和透明度。帮助团队相互合作，而不是孤立无援。你必须成为他们的榜样。不要强制要求结对编程，但一定要进行结对编程。不要强制要求站立会议，但早上第一件事就是进行对话，并吸引尽可能多的团队成员。看看“持续改进”的原则。了解如何进行根本原因分析和 5 个为什么，以便团队能够理解更好地解释事情为何困难并自己采取行动。
我还推荐Mary Lynn Manns 和 Linda Rising“Fearless Change”。这将帮助您确定还有谁可以帮助您。
最后，我会回应@sjt。不要自杀。然而，如果这是你真正想要的东西，而你的公司没有以正确的方式做这件事，不要害怕去其他地方。学习一些基础知识，自行练习 TDD 并找到一份新工作。
无论你做什么，祝你好运！改变的第一步是欲望。
I heard a lovely saying once and can't remember who said it. "They want Agile but they don't know what it is - so we give them Agile but we don't know what they want."
It sounds as if this is happening in your company. Someone, somewhere wants the team to use Scrum, but it's not the team.
That must be a difficult job for an SM, especially if you're doing it unofficially! There are some things I can suggest for you. First, learn some basic coaching techniques: positive language, GROW framework and giving and receiving feedback. This will give you some additional tools which are outside of Scrum and support someone in a leadership rather than a management position (even an unofficial SM can become a leader).
Then, don't worry about the actual practices. If someone has mandated Scrum then the team will be forced to do this anyway. Instead, concentrate on the values and principles of Scrum - particularly collaboration, communication and transparency. Help the team to work with each other instead of being silo'd away. You will have to be an example for them. Don't mandate pair programming, but do go over and pair. Don't mandate stand-ups, but do have conversations first thing in the morning and draw in as many people on the team as you can. Look at the principle of "Continuous Improvement". Learn how to do root cause analysis and the 5 Why's so that the team can understand better why things are hard and take action themselves.
I also recommend Mary Lynn Manns and Linda Rising "Fearless Change". This will help you to work out who else could help you.
Finally, I will echo @sjt. Don't commit Scrum suicide. However, if it's something you really want and your company aren't doing it in the right way, don't be afraid to look elsewhere. Learn some of the fundamentals, practice TDD on your own and find a new job.
Whatever you do, good luck! The first step to change is desire.
如果您没有其他开发人员的支持，那么它就不会起作用。时期。
Scrum 需要大量的纪律，尤其是在早期采用阶段。
我不会因为管理层不关心它而感到困扰。如果你可以自由地从事软件开发工作，并且他们关心的只是结果，那么如果你碰巧每天早上站起来 10 分钟，并将一小部分工作计划成可管理的，那也没什么关系。位，只要你达到了他们希望你达到的目标。
如果您的团队不参与其中，那么您将非常很难让它发挥作用，并且它可能会失败并造成比根本没有尝试更大的影响。
如果您可以尝试在一个小项目中启动它，并且有一些支持该想法的开发人员，那么您可以向开发团队的其他成员报告您发现它是如何工作的，有什么好处以及什么消极的一面（毕竟反思是 Scrum 的重要组成部分）。
如果你想让你的管理层参与其中，你可能会发现，在以这种方式完成一些项目后，你可以更好地估计开发 PM 向你提出的要求所需的时间，希望能够更准确地按时完成任务。
请记住，PM 和 BA 仍然可以按照正常方式工作，一旦他们将需求交给您，您就可以使用 Scrum 来构建它们。它并不理想，但如果缺乏每个人的认可，以及直接与用户交谈并让他们帮助编写用户故事的能力，那么它将是您所拥有的最好的。
当要求估计完成项目所需的时间时，您可以应用 Scrum 技术。您可以将规范分解为更小的块，将它们分组为冲刺并相应地开发它们，希望能产生更好的结果。
If you don't have buy in from your other developers its not going to work. Period.
Scrum requires a heap of discipline, especially during the early adoption phase.
I wouldn't be bothered that management don't care for it. If you're free to do the work of developing the software, and all they care about is results, then it shouldn't matter if you happen to have a 10 minute stand up each morning, and plan small chunks of the work into manageable bits, as long as you're hitting the targets they want you to hit.
If you're team isn't on board though, you're going to have a really hard time getting it working, and it will probably fail and cause more impact that not having tried at all.
If you can try to start it in a small project, with a few developers who are on board with the idea, then you can report back to the rest of your development team on how you found it works, what were the benefits and what were the negatives (reflecting is after all an important part of Scrum).
If you want to get your management on board, you might find that after doing a few projects this way you're much better at estimating the time it will take to develop the requirements you've been given by the PMs, hopefully being able to hit deadlines with more accuracy.
Remember, the PMs and BAs can still work in their normal way, once they've handed requirements to you, you're able to build them using Scrum. Its not ideal, but short of having the buy in of everyone, and the ability to speak directly to users and get them to help write user stories, it will be the best you've got.
When asked to estimate the time it will take to complete the project you can apply Scrum techniques. You can break the specifications down into smaller chunks, group them into sprints and develop them accordingly, hopefully yielding better results.
嗯，这是一个好的开始，想要改变现状。尽管我必须说，如果没有管理层的支持，这将是艰难的。尝试安排一位经验丰富的 Scrum 演讲者或敏捷教练来您的公司做一场涉及所有高层管理人员的演示或研讨会。一旦管理层相信了 Scrum，一切都会走下坡路。
这违背了 Scrum 中的自组织和自我授权团队原则。一个好的 Scrum Master 会在 Scrum 规则中以一种有纪律的方式赋予团队权力，达到团队应该能够独立运行的适当水平。一个建议是，团队领导在担任 SM 时需要有不同的心态，而在担任高级开发人员时需要有不同的心态，Scrum 团队中没有团队领导，只有 Scrum 团队成员。你无法指定真正的领导力，这是一种相互的角色，可以通过建立帮助他人和指导他人的声誉来获得。让他们在 SM 和开发职责之间分配 30%、70% 或 50-50 或任何你认为合适的时间。命令和控制可能会对团队产生反作用。
一位Scrum 培训师曾经告诉我，“不要犯Scrum 自杀”。如果您的经理不关心 Scrum，请不要试图说服他们而被解雇。无论你们遵循或“不”遵循什么方法论，你们都必须意识到这一切都是一门生意。你的薪水取决于你老板的批准，如果你的老板或经理不关心Scrum，那就不要这样做。如果他们关心瀑布，切换到它，像你关心的那样去做，但不要半途而废地做 Scrum 并称之为 Scrum。
Well, that's a good start right there, wanting to change the situation. Although I must say that without the management buy in, it will be tough. Try and arrange an experienced Scrum Speaker or Agile Coach come and do a presentation or workshop at your company which involves all the upper management. Once you have the management believing in Scrum, it will be all downhill from there.
This goes against the Self Organized and Self empowering Teams principle in Scrum. A good Scrum Master would empower the Team in a disciplined fashion within the Scrum Rules, to that appropriate level that, the Team should be able to run on it's own. One suggestion is that the Team Leads need to have a different mindset when working as a SM and different one while working as a Senior Developer, there are no Team Leads in a Scrum Team, only Scrum Team members. You cannot assign true leadership, that is a mutual role which can be earned by creating a reputation of helping others and mentoring others. Have them spit time between SM and development duties 30%, 70% or 50-50 or whatever you find appropriate. Command and control could be counter productive for the Team.
A Scrum Trainer had told once told me, "Do not commit Scrum Suicide". If your managers do not care about Scrum, don't get fired trying to convince them. Whatever methodology you guys might follow or "not" follow, you have to realise that all this is a business. Your pay check is dependent on your boss's approval, if your boss or manager does not care about Scrum, then don;t do it. If they care about waterfall, Switch to it, do it like you care, but don't do Scrum halfway and call it scrum.
过去对我有用的是识别和沟通痛点。当然，你永远不应该因为肯特·贝克告诉你的事情而做某事，尤其是那些只会让你被解雇的事情。然而，一些聪明人致力于找出一组具有凝聚力的实践，而与这些实践的分歧几乎总是会导致痛点。
举一个例子：如果你在进行 Scrum 时有需求迭代、设计迭代、实现迭代和测试迭代，这在理论上是可行的，但实际上却行不通。 （当它发生时，它最终会成为瀑布，“迭代”概念变得毫无意义。）向你的老板指出你在 QA 测试时学到了一些关于需求的知识可能会帮助他认识到让 QA 参与需求的价值。或者通过做一个小型原型来发现软件设计中的风险可能有助于说明为什么它可能有助于崩溃设计迭代。
What has worked for me in the past is to identify and communicate pain-points. Certainly, you should never do something because Kent Beck told you to, especially something that will just get you fired. However, some smart people worked at figuring out a set of practices which is cohesive, and divergence from these practices almost always leads to pain points.
As just one example: if you do Scrum where you have a requirements iteration, a design iteration, an implementation iteration, and a testing iteration, this in theory could work but in practice never does. (When it does, it ends up being Waterfall, and the "iteration" notion becomes meaningless.) Pointing out to your boss that you learned something about the requirements while QA was testing might help him realize there's value in getting QA involved in requirements. Or finding risks in the software design by doing a small prototype may help to show why it might help to collapse the design iteration.