Stop "Going Agile"!

始める前にしておく必要がある 3 つの会話 

Martin Suntinger Martin Suntinger

会社は "アジャイル推進" というミッションを、本当の意味を理解する前に設定しまうことがよくあります。しかしすぐにほころびが出始め、期待が失われ、誰もが "アジャイル推進" の価値そのものを疑問に感じるようになり、アジャイルを達成する機会はまったく損なわれてしまいます。

実際は、アジャイル推進によりチームの生産性があがり、プロジェクトを早く引き渡せるようになりますが、それは全員がルールに合意できる場合に限ります。e コマースの大企業、Gilt 社の Heather Fleming と Justin Riservato が、アジャイルの原則に対するコンセンサスを得ることが、プロセスの実装よりも重要である理由についてお話しします。

具体的には、Heather と Justin は、チームがアジャイル導入の作業に取りかかる前に答えを用意しておかなければならない 3 つの重要な質問への回答を検討します。

  • "But when will you be done?" Why getting rid of the concept of deadlines is the most important (and most difficult) conversation when going agile.
  • "This is my top priority, but I can't meet with you until next week." What to do when your business partner can't (or won't) be a full member of the team.
  • "I just want to code. Why do I have to be in all these meetings?" Why implementing Scrum is not the first step to going agile.

Watch and learn

Q & A

ここでは、Heather と Justin が、このプレゼンテーションの Q&A セッションで最も質問が多かった事柄をいくつかを選びました。アジャイル方法論を適用する方法について詳しく理解するのに役立つ内容です。

Q1:アジャイルボードにはデジタルと物理的なものがありますが、どちらを選びますか。

A1: It really depends on your team setup. Are you all in the same place? How big is your team? Do you have space for a big physical board? We have done both at Gilt, but have found that as we grow and expand to dozens of teams that the agile boards in JIRA Software are more practical than physical boards. They are easier to set up and make changes to, and easier to share with remote team members. What we love about physical boards is that you just can’t ignore them, they are so in your face. And they are a great place to hold impromptu discussions about current work, or to have stand-ups if you do those.

Q2:アジャイル プロセスについていけない、または理解していない管理者やクライアントとどのように仕事しますか。時々、自分がうまくいっていないワークフローのコーチのような気がしてきます。

A2: It’s important to think about your order of operations. If you are trying to work in an agile process with people who don’t believe in it, then you are jumping the gun a bit. The most important part of making this work is to gain consensus in the philosophy before you execute a process. We have done this in the past by looking at specific problems that a team is having with the current process and solving them in an agile way. Can you walk your manager or client through real problems they’re trying to solve and how you would approach it in an agile framework? Can you take them bit by bit towards becoming agile, rather than in a big changeover of the total process? You can then start to show real results this way, incrementally, as the team is working better. In short, take an Agile approach to going Agile. ;)

Q3:プロジェクトが固定契約または固定スケジュールで、実装する要件の一覧が付いている場合、アジャイルのプロセスをどのようにして実現できるのでしょうか。

A3: First off, it is impossible to complete a project successfully given a fixed schedule AND a fixed list of requirements to implement, so is there a way to get everyone to agree that this is Fantasy Land? Most constraints around deadlines and requirements are not true constraints: they are wishes. Start discussing why you are doing the work, or what is the problem that you are trying to solve. If you truly understand the goals of the project and the reasons for the constraints, you can make sure that the team is doing the right work at the right time. Writing all the requirements down with dates next to them doesn’t magically make everything happen on time.

Q4:ほとんどのプロジェクトでは、ふつうパートナーや顧客にリリース日を伝えています。この場合、交渉可能なのは機能セットだけです(ただし、品質上の妥協はあります)。固定された期限の制約の中でどのように作業しますか。

A4: We think you answered this yourself — you do this by negotiating scope. If you don’t, you are right that quality will suffer. Thinking that you can just jam in the scope regardless is a dream — you need to make sure your teams are working with reality, even if it’s not what people want to hear. Heather wrote a short blog post on this which you can read here.

Q5:スクラムの実装方法を変更すべきだという主張をどう思いますか。

A5: The rigidity of scrum is our biggest problem with it. To think that a single highly-prescriptive process will work for all teams, regardless of what they are working on, and who they are is presumptuous. We have seen it work for teams, but scrum is not the only way to be agile, and a lot of teams fail with agile because they think they have to implement scrum in a specific way with all of the prescribed job roles, user stories, acceptance criteria, meetings, and artifacts. Heather also has an issue with the title “Scrum Master.” ;)

Q6:関係者がチームメンバーに直接影響を与えるのをどのように防ぐことができますか。

A6: Well, a good stakeholder IS a team member. So ideally bring the key stakeholder into your team so you can all work together! If you have the kind of stakeholders that just throw things over the wall to your team, or swoop in during the project and try to change everything, it’s important that the whole team understands what they are doing and why. So no matter who stakeholders talk to they will get the same answer. That’s what makes you a team rather than a collection of individuals. You need to communicate — a lot — and ensure everyone is on the same page and moving in the same direction.

ストーリーの見積は大まかな桁数の (時間) 見積を基にしますか、またはポイントを基にしますか。

A7: We do both, and some teams don’t estimate at all. Points are great because they are more abstract, and are not tied to any specific calendar time. Hours can be helpful as a transition if your team is resisting estimation since it is more tangible. The point of estimating is to be able to tell whether your sprint is too heavy or too light and adjust, and they really serve no purpose once the sprint starts. We find that once you have worked with a team for a while, the estimation process becomes unnecessary. We can all look at the work and tell pretty easily whether it is the right amount for the sprint.

Q8:深い分析能力と製品知識を持つプロジェクトリーダーやマネージャーと、単に技術者とビジネス関係者の会議を調整して要件を収集するのとでは、どちらにどれだけの価値を置きますか。

A8: Pretty much all the value :) Coordinating meetings, taking notes, etc… are not specialized skills. Anyone can do them. While it is important that they happen, it is not really the biggest value-add you can provide for the team. If all you are doing is administrative work, then the team is right to question why you are a part of it. Everyone in the PMO at Gilt has a deep understanding of the relevant subject matter and the tools and techniques to get work done and they bring that with them to every team they work on. Many of us were engineers previously or worked with other departments at Gilt and bring with us unique subject matter expertise.

Q9:Gilt では、一般的にチームの規模はどの程度で、メンバーはどのような経歴を持っていますか。

A9: Ideally we want our teams to be lean but large enough to be self-sufficient, allowing them to move forward on projects without dependencies on other teams. We follow the ‘two pizza’ rule: teams should be able to be fed by two pizzas. We also feel strongly that each individual on the team brings with them a set of unique talents, and they should be able to bring those talents to the team regardless of what their job title is. So if, traditionally, the product owner is responsible for all presentations, but they stink at it and if there’s an engineer who is amazing at storytelling and winning over an audience, we’re going to let the engineer bring that talent to the team. You are more than your job title!

Q10:特に開発とは別のスプリントでテストを行っている場合、個別の QA チームをどのように管理しますか。

A10: This is one of the more controversial positions that we take, but we don’t have a separate QA team at Gilt. We believe in automation testing throughout the development and deploy process. Teams are responsible for the quality of their code. If you have the time and expertise to write code, you have the time and expertise to write tests for it. Throwing this over the wall to a QA team has never shown good results for us, and requires a lot of additional documentation and time to bring QA teams up to speed.

Q11: 同時に複数の「製品」に取り組んでいる複数のチームがある場合、スプリント計画中にプロダクト マネージャー全員を 1 室に集めて、製品間の相対的な優先度を決定させるというやり方はうまく機能するでしょうか。また、他にアイデアはないでしょうか。

A11: Stop! Clearly this isn’t going to work. The team should have a product manager of its own and not be working on multiple products for multiple product managers who are outside of the team. Whomever is acting as the team lead should step-up here and clearly outline the team’s methodology for prioritization, and in what order they are going to tackle the execution of that work based on this methodology. It ties back into our point that, “you have to be aligned on your methodology before you can put a process into place.”

Q12:私はマーケティング分野のクリエイティブサービスチームにアジャイルを導入しようとしています。わが社では指定の日付に納入しなければならない成果物をいくつか扱っています。(雑誌に掲載する広告の制作) このプロジェクトをアジャイルのフレームワークにどう当てはめればいいでしょうか。

A12: Agile is able to handle constraints like this. It is up to the team to identify what has to be done and by when and to plan sprints accordingly. Agile should help you hit these deadlines since it gives you the ability to adjust your priorities and your planned work (scope) every sprint. If you start tracking your velocity, you’ll soon be able to tell whether or not you’re going to hit those deadlines sooner rather than later. It’s then up to a good team leader to be able to negotiate what the team needs to be successful.

Q13は:目標の変更はスコープクリープに見えないでしょうか。

A13: Yes it does, but we don’t call it ‘scope creep’ because we want to encourage change during a project. One of the biggest advantages of an agile philosophy is that it allows you to adapt to things that are outside of your control. If the competitive landscape changes, or the needs of your business change, or there is new technology available, do you really want to plod on through the requirements matrix that was made months ago? If you want to deliver the best product for your customer, embrace change and use it to your advantage. There is no ‘scope creep’ in agile (insert Jedi mind-trick here).

次の記事
スクラム