Scrum and Organization English version h"p://bit.ly/r0Lc8F
Ryutaro YOSHIBA(@Ryuzee) Agile Coach Certiﬁed Scrum Professional(CSP) Certiﬁed Scrum Master(CSM) Certiﬁed Scrum Product Owner(CSPO) http://www.ryuzee.com/ Chief Technical Oﬃcer at Startup. http://www.ﬂickr.com/photos/adforce1/2539903964/
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 eﬃciency to implementing strategy – IT system is the source of competitiveness – It is strongly required to deliver good product faster.
Competition speed get faster
Expiration time of business model is shortened.
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.”
Software Uncertainty • Cone of Uncertainty From 10 Deadly Sins of Software Estimation by Steve McConnell, ©2002-‐‑‒2007
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.
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
The seven wastes • Over-‐‑‒production From TOYOTA production system. – Features which are not used, Features which do not earn value • Waiting – Waiting for speciﬁcations, 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 ﬂow and Reworking
What is Agile？ Realizing customer value. Realizing happiness of the members related to development. Raising the proﬁt of the company. Agile is a tool for achieving the above. http://www.ﬂickr.com/photos/dhammza/474654705/
Scrum Basics http://www.ﬂickr.com/photos/royskeane/413103429/
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
プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る ステークホルダー チーム (7±2⼈人) 製品の利利⽤用者、出資者、管理理職 などの利利害関係者。鶏と称す プロダクトの開発を⾏行行う。 製品の成功に向けて最⼤大限 の努⼒力力をコミットする デイリースクラム プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒見見積もり。 項⽬目の追加はいつでも⾃自由だが実施有無や優 先順位はPOが決める。 毎⽇日チームが以下の３つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 更更新してグラフにプロットする 何をもって「完了了」とするかを 定義したリスト スプリント計画会議 スプリント プロダクトバックログを再度度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬目 をタスクにばらす 最⼤大4週間までのタイムボックス 各スプリントの⻑⾧長さは同⼀一。この間は外部 からの変更更を受け⼊入れない タスク 時間で⾒見見 積もり 毎⽇日の繰り返し スプリントバックログ そのスプリント期間中に⾏行行う タスクのリスト スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する ふりかえり スプリントの中での改善事項 を話合い次に繋げる 出荷可能な 製品の増分 複 数 回 ス プ リ ン ト を 繰 り 返 す
Product Owner ・Responsible for the product
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
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
ScrumMaster • Guardian of the Scrum process • Protecting the team from external interferences
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
Team • • • • 5-‐‑‒9 members Cross functional Full time Self organized
Team • Team commits that All the team members will make collaborative eﬀorts 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
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 “Deﬁnition of Done” • Responsible for giving help to other team members. • Responsible for training other team members.
Responsible for continuous improvement
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. • • • • • •
What is “Commitment”？ • Commitment is … – Doing teamʼ’s best to ﬁnish 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 ﬁnish stories based on all team memberʼ’s agreement.
Pig and Chicken PO & SM & Team User、Manager、 Stakeholders…
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 dissatisﬁd 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 ﬁrm faith in the team.
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 ﬁnd 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.
Changing role of manager • Traditional conduct – Pyramid organization – Command & Control – Authoritarian – No ﬂexibility – Answer – Scold – Deny – Micromanagement • Required conduct – Network organization – Support – Democratic – Flexibility – Lead – Praise – Aﬃrm – 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.
Leadership model (SL) • Leadership model is classiﬁed into four as shown in the left chart. – – – – From http://www.situational.com/ S1:Speciﬁc suggestion S2:Explanation and answer S3:Participatory S4:Delegative • In Agile development, S3 or S4 is required and typical WF leader is S1. • Eﬀective leadership diﬀers depending on the maturity of the subordinates or the organization.
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 eﬀective 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.
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 buﬀers.
Realistic Scrum adoption
Deﬁnition 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 diﬀerent for each project and will also depend on the teamʼ’s maturity level. But DoD is essential for Scrum projects
Deﬁnition of Done Example • For a story • – All codes including test code and production code checked in. – All unit tests passing – All acceptance tests identiﬁed, written, passing – Help ﬁle 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 ﬁxed 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
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.)
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 ﬁnished at the end of each sprint (or at the end of each release).
Quality in Scrum At the end of a sprint “Tests” are done. In the sprint review, we can conﬁrm that the implemented feature is suitable for the customer or stakeholderʼ’s requirements. http://www.ﬂickr.com/photos/kakutani/2761992149/
Quality in Scrum Scrum is only deﬁned 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)
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
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 “Deﬁnition of done” Checkstyle Warning Coverage
Evaluating the teamʼ’s activity Line of code Activity at SCM Hours committed
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 ﬁrst 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 “Deﬁnition of done” • Organizations which have a principal of document approval must be reformed.
Failed Scrum • • • • • • • • • • • • • Opposition of individuals Confusion No Discipline Subversive Behaviour Apathy Fear Dominance Hostility Excessive superiority Ignorance Deﬁned positions Being too comfortable Indiﬀerence
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
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-‐‑‒Reﬂection Missing Self-‐‑‒Reﬂection Missing Commitment Non-‐‑‒Learning Wrong Value Deﬁnition No leaving Comfort Zone
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 Ineﬀective ScrumMaster Cookie Cutter Process, Imposed Process Group pressure, Invisible Product Owner, No Empowerment No adaption, Change too frequent
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
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. • “Deﬁnition 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.