1. Scrum and Organization English version h"p://bit.ly/r0Lc8F
2. Ryutaro YOSHIBA(@Ryuzee) Agile Coach Certified Scrum Professional(CSP) Certified Scrum Master(CSM) Certified Scrum Product Owner(CSPO) http://www.ryuzee.com/ Chief Technical Officer at Startup. http://www.flickr.com/photos/adforce1/2539903964/
4. Business background • Change in business environment • Swift decision-‐‑‒making and actualization are required. • Companies run the risk of being left behind by the market if they do not change. • Changing company is strongly required. • Change in the purpose of IT investment – From efficiency to implementing strategy – IT system is the source of competitiveness – It is strongly required to deliver good product faster.
5. Competition speed get faster
6. Expiration time of business model is shortened.
7. Correspondence to change NOT “Sticking long-‐‑‒term to an elaborate plan determined beforehand“ Instead ”We should assume that changes will take place and change track as and when necessary.”
8. Software Uncertainty • Cone of Uncertainty From 10 Deadly Sins of Software Estimation by Steve McConnell, ©2002-‐‑‒2007
9. Probability of delivery • The delivery date forecast of software is probability distribution. Relative probability In general, the project manager sets the delivery date which has the highest probability of delivery. However, the total possibility to deliver in time is very low.
10. Use ratio of features • 64% of features are not used. Use ratio of features システムの機能の利利⽤用割合 いつも使う Usually 7% 7% O3en よく使う 13% Some;mes たまに使う 16% Rarely Never まったく使われない None 45% ほとんど使われない 19% From Standish report in 2000
11. The seven wastes • Over-‐‑‒production From TOYOTA production system. – Features which are not used, Features which do not earn value • Waiting – Waiting for specifications, Waiting for building, Waiting for testing • Transportation – Switching tasks • Over-‐‑‒processing – Reports which are not useful to the team, Duplicate components • Inventory – Bulk documents • Motion – Travel time in distributed development, manual work because of lacking tools • Defects – Finding defects at later process flow and Reworking
12. What is Agile？ Realizing customer value. Realizing happiness of the members related to development. Raising the profit of the company. Agile is a tool for achieving the above. http://www.flickr.com/photos/dhammza/474654705/
13. Scrum Basics http://www.flickr.com/photos/royskeane/413103429/
14. Scrum＝Framework • Key concept – Self organized – Time-‐‑‒boxed – Inspection and Adaptation • Not a collection of technical practices • Not preventing from using the other Agile methods at the same time • Actually, it is necessary to use parts of XP practices
15. プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る ステークホルダー チーム (7±2⼈人) 製品の利利⽤用者、出資者、管理理職 などの利利害関係者。鶏と称す プロダクトの開発を⾏行行う。 製品の成功に向けて最⼤大限 の努⼒力力をコミットする デイリースクラム プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒見見積もり。 項⽬目の追加はいつでも⾃自由だが実施有無や優 先順位はPOが決める。 毎⽇日チームが以下の３つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 更更新してグラフにプロットする 何をもって「完了了」とするかを 定義したリスト スプリント計画会議 スプリント プロダクトバックログを再度度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬目 をタスクにばらす 最⼤大4週間までのタイムボックス 各スプリントの⻑⾧長さは同⼀一。この間は外部 からの変更更を受け⼊入れない タスク 時間で⾒見見 積もり 毎⽇日の繰り返し スプリントバックログ そのスプリント期間中に⾏行行う タスクのリスト スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する ふりかえり スプリントの中での改善事項 を話合い次に繋げる 出荷可能な 製品の増分 複 数 回 ス プ リ ン ト を 繰 り 返 す
16. Product Owner ・Responsible for the product
17. Product Owner • Arrange the list of features necessary for the product • Decide release dates and contents • Responsible for the productʼ’s business value • Prioritize features • Re-‐‑‒evaluate features and priorities • Accept or reject teamʼ’s work • Discontinue sprint
18. Product Owner Absence • Typical Anti-‐‑‒Pattern • This problem surfaces when there are a lot of stake-‐‑‒holders. • Lack of feedback process • Team can not understand… – What should be made – Whether the features are correct – Whether the features have business value Action: Select Product Owner or Build Product Owner Team
19. ScrumMaster • Guardian of the Scrum process • Protecting the team from external interferences
20. ScrumMaster • Representative for project management • Responsible for earning value from Scrum and doing Scrum practice • Remove impediments • Ensure the team is fully functional and productive • Keep close cooperation with involved persons • Protect the team from external interferences
21. Team • • • • 5-‐‑‒9 members Cross functional Full time Self organized
22. Team • Team commits that All the team members will make collaborative efforts in project. • The team decides who is in charge of which task. Not the manager. • Evaluation is not based on how many tasks have been completed. • Switching members is not allowed during the sprint. • Responsible for following teamʼ’s rules • Responsible for continuous improvement
23. Responsibility to follow teamʼ’s rules • All Agile processes require – Delegation to the team – Establishing a team culture and standards • Responsible for attending daily Scrum • Responsible for doing work complying with “Definition of Done” • Responsible for giving help to other team members. • Responsible for training other team members.
24. Responsible for continuous improvement
25. Retrospective Place and chance to improve process NO attacks on individuals NO linking individual evaluations. All members should be able to speak freely. Trace action items in previous retrospective Are there same the problems which were found in the previous retrospective? • Trying to solve all the problems at once is likely to fail. • You must have a problem-‐‑‒solving mindframe. • • • • • •
26. What is “Commitment”？ • Commitment is … – Doing teamʼ’s best to finish stories selected by the team. – Not team memberʼ’s individual responsibility but Teamʼ’s responsibility • Estimation is NOT Commitment – But in many cases, estimation is considered as commitment. It is bad habit. • After several sprints are complete and the Teamʼ’s velocity is stable, you can commit to finish stories based on all team memberʼ’s agreement.
27. Pig and Chicken PO & SM & Team User、Manager、 Stakeholders…
28. Operation process transition • A change from the past command control model to a self-‐‑‒organized model is required. – Command and Control • Sense of values that members simply have to obey their superior's instructions – Members feel that they are being forced – Whether the superior's instruction has been observed becomes the evaluation point. – Training is not well executed, so members will become lesser copies of their superiors. – An excellent person who is dissatisfid with the current state will soon resign. – Self-‐‑‒organized • Managers have to take responsibility and have to solve impediments which canʼ’t be solved by the team. • Managers have to support and facilitate the team • Managers must have firm faith in the team.
29. Team management • Sharing team Vision – Keep motivation by sharing the goals of the team and purpose of the team. • Cycle of improvement in the self-‐‑‒ organized team – Always be aware of things which can be improved. – Retrospective meetings are a opportunity to find things which can be improved. – Do not let the problems stand. It is important to keep monitoring whether the team is always trying to improve and solve problems.
30. Changing role of manager • Traditional conduct – Pyramid organization – Command & Control – Authoritarian – No flexibility – Answer – Scold – Deny – Micromanagement • Required conduct – Network organization – Support – Democratic – Flexibility – Lead – Praise – Affirm – Delegate You have to stop micromanagement if you want the team to be selforganized. Generally team tend to follow instructions. So We will never be self-organized unless there is no instruction from outside of the team.
31. Leadership model (SL) • Leadership model is classified into four as shown in the left chart. – – – – From http://www.situational.com/ S1:Specific suggestion S2:Explanation and answer S3:Participatory S4:Delegative • In Agile development, S3 or S4 is required and typical WF leader is S1. • Effective leadership differs depending on the maturity of the subordinates or the organization.
32. Cultivation of human resource • The team fosters/trains members. • Not OJF through one-‐‑‒one-‐‑‒one training. • All team members cooperate to help improve each othersʼ’ skills. • It is effective to hold study sessions within the team. We can gain a good return on a small investment. • Rapidity of skill development depends on the culture and environment.
33. Employee Evaluation • From Individual evaluation to Team evaluation • Transparency of evaluation process – Evaluation standards to which everyone consents – Do not use the transparency in the Agile process to punish individuals or the team. – Obscurity of evaluation is the root cause of stagnation. – Obscurity of evaluation leads to over-‐‑‒burdening, hiding problems, negligence, keeping excessive buffers.
34. Realistic Scrum adoption
35. Definition of Done • List of tasks that team have to complete to achieve a shippable product. • For example, Writing code, Unit testing, Integration testing, Writing release note. • Preparing DoD for story, DoD for sprint and DoD for release is highly recommended. • Contents of the DoD list will be different for each project and will also depend on the teamʼ’s maturity level. But DoD is essential for Scrum projects
36. Definition of Done Example • For a story • – All codes including test code and production code checked in. – All unit tests passing – All acceptance tests identified, written, passing – Help file auto generated – Functional tests passes • For a sprint All stories satisfying DoD Product backup updated Performance Testing complete Diagram of classes, database tables and architecture updated – All bugs fixed or postponed – Code coverage over 80%. – – – – For an internal release – – – – – – • All sprints satisfying DoD Installation packages created operation guide updated trouble-‐‑‒shooting guide updated Disaster Recovery plan updated All test suites passes For a production release – – – – – – – All internal releases satisfying DoD Stress testing implemented Performance tuning implemented Network diagram updated Security pass validated Threat analysis testing validated Disaster recovery plan tested
37. Scrum and XP • Scrum practice – Role • ScrumMaster • Team • Product Owner – Event • Daily Scrum • Sprint planning meeting • Sprint review • Retrospective – Things created • Product Backlog • Sprint Backlog • Burndown chart • XP Practice（Typical 12） – – – – – – – – – – – – Planning game Small release Metaphor Simple design Automated test Refactoring Pair programming Joint ownership of code Continuous Integration 40 hours work in a week On site customers Coding standard Some XP practices(red characters) must be integrated into Scrum process, so that the whole project can be covered from a technological perspective. XPʼ’s “40 hours work” does not use in Scrum because self-‐‑‒organized team is the most important thing and if the team decide to work overtime, they can do that. (But sustainable pace is also important, so this should be a target for improvement investigation in retrospective sessions.)
38. Quality in Scrum 24hours Sprint 2-‐‑‒4weeks Sprint Goal Return Cancel Return Coupon Gift wrap Wrapping Cancel Product Backlog Sprint Backlog Coupon Potential shippable Product increments Unit tests and Integration tests and acceptance test finished at the end of each sprint (or at the end of each release).
39. Quality in Scrum At the end of a sprint “Tests” are done. In the sprint review, we can confirm that the implemented feature is suitable for the customer or stakeholderʼ’s requirements. http://www.flickr.com/photos/kakutani/2761992149/
40. Quality in Scrum Scrum is only defined as framework and Automated testing is not mentioned. But Automated testing is essential for Agile development The cost of manual for small-‐‑‒scale releases testing will increase with the growth of the product... Manual testing decreases the productivity and earning value. (The ratio of regression testing to cost will increase)
41. Agile Testing Quadrants Business Facing 【Manual】※1 Exploratory Testing Scenarios Usability Testing User Acceptance Testing Alpha / Beta Q2 【Automated】 Unit Tests Component Tests Q3 【Tools】 Performance Testing Load Testing Security Testing Q1 Technology Facing ※1 can be automated by ATDD Q4 Critique Product Supporting the Team 【Automated & Manual】 Functional Tests Story Tests Prototype Simulations
42. Automated Testing (Q1) Number of test cases PMD warning It is necessary to build an evaluation system, which is automated as much as possible, based on “Definition of done” Checkstyle Warning Coverage
43. Evaluating the teamʼ’s activity Line of code Activity at SCM Hours committed
44. Documents • It doesn't mean documents are not written • The necessary documents have to be written at appropriate times. – The documents necessary for observance of the law are not necessary from the first stage of development. – It is necessary to always maintain the material for maintenance and operation from timing in which the product is released to production environment. – Many documents can be automatically created. • Writing documents needs to be included in “Definition of done” • Organizations which have a principal of document approval must be reformed.
46. Failed Scrum • • • • • • • • • • • • • Opposition of individuals Confusion No Discipline Subversive Behaviour Apathy Fear Dominance Hostility Excessive superiority Ignorance Defined positions Being too comfortable Indifference
47. Failed Scrum • • • • • • • • • • • • Micromanagement Mini-‐‑‒Waterfalls Finger-‐‑‒pointing Revoking Team-‐‑‒Decisions ScrumMaster＝Accountable for the team Heroism Command & Control Bad Values Hierarchical Thinking Securing oneʼ’s own position Compliance Blame
48. Failed Scrum • • • • • • • • • • • • • Process at Sprint N Same as Sprint 1 No Known Sprint Velocity No Hands-‐‑‒on Customer Demo No Code-‐‑‒Reviews Stand-‐‑‒up meetings monotonous Tests Not Run Before Check-‐‑‒In Misleading Metrics No Group-‐‑‒Reflection Missing Self-‐‑‒Reflection Missing Commitment Non-‐‑‒Learning Wrong Value Definition No leaving Comfort Zone
49. Failed Scrum • • • • • • • • • • • No Time for responding to Change Retrospective without Action Doing things that do not work again No Refactoring Sprint Review without conclusions/decision items No Tests 10 Ways to do things in 10 days Ineffective ScrumMaster Cookie Cutter Process, Imposed Process Group pressure, Invisible Product Owner, No Empowerment No adaption, Change too frequent
50. Failed Scrum • • • • • • • • • • • • • Many Loose Ends Task Handover Only BA Talks to Customers No Team Planning No Slowing down for Teammates Deciding for the customer Check-‐‑‒In Race Hard-‐‑‒coded Communication Path No Shared Responsibility Push System Turf Wars Separation Politics
51. Conclusions • Agile is necessary to respond to the change in the speed of business. • Estimates are uncertain and we tend to make useless products. • It is important to make systems based on business value. • Team over Individual • We have the responsibility to improve processes. • “Definition of done” is essential for projects. It is related to Quality. • Documentation is also necessary. • Many of the causes of failed Agile development are cultural.
