Agile Scrum Training

AGILE SCRUM WORKSHOP

Author : Nguyễn Thành Châu E-‐mail: [email protected] Cell phone: (+084)918226449

Tài liệu được biên soạn bởi Nguyễn Thành Châu theo yêu cầu của Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản các dựdựán nghiệp công nghệ thông Banlý quản lý các án công công nghiệp công nghệ thông tin - Bộ TT & TTtin - Bộ TT & TT

Introductions and Expectations Participant introductions v  Name v  Position and background v  How long experience with Agile-Scrum development? v  What do you want to get out of this course (expectation)?

Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

Who Am I ? q  20+ years of working experience in IT industry q  Conducted 50+ training courses related to Agile-Scrum, PM, BA, CMMI, ITIL, ISO 20k, ISO 27k. q  Consulted 20+ organization related to QMS, ISMS, ITSM q  Professional Scrum Master q  ISMS Lead Auditor q  ITIL Expert


Logistics

EMERGENCY

EXIT


4

Rules of Engagement Participate. One person speaks at any given time. Keep discussions and questions to the point. Turn on your cell phones and other communication devices to Silence mode. v  Be prompt returning from breaks. v  …… v  v  v  v 


5

AGENDA v  Traditional Software Development

v  Agile Requirement v  Testing in agile

v  Agile Introduction

v  Agile - Lean development

v  Agile Scrum Introduction

v  KanBan

v  Scrum Roles

v  Scaling and Distributed Scrum

v  Scrum Artifacts

v  Extreme Programming

v  Scrum Meeting

v  Agile For Manager

v  Agile Estimation


6

Schedule Day 1 : v Traditional Software Development v Agile Introduction v Agile Scrum Introduction v Scrum Roles

Day 2 : v Scrum Artifacts v Scrum Meetings v Agile Estimation


7

Schedule Day 3 : v  Agile Requirement v  Testing in agile v  Agile - Lean development Day 4 : v  Agile - Lean development v  KanBan v  Scaling and Distributed Scrum v  Extreme Programming


8

Schedule Day 5 : v  Agile For Manager v  Workshop summary v  Mockup exam


TRADITIONAL SOFTWARE DEVELOPMENT


10

Software Engineering

“ The application of a systematic, disciplined, quantifiable approach to development, operation and maintenance of software: that is, the application of engineering to software.” » IEEE Standard Computer Dictionary


11

Exercise 1: Explain waterfall model Traditional model: v  List all of phases of Waterfall model. Each phase will be written in a sticker. v  List all of roles of Waterfall model. Each role will be written in a sticker. v  List all of the tasks of Waterfall model. Each task will be written in a sticker. v  List all of problems, issues, or weaknesses of Waterfall model. Each problem, issue, or weakness will be written in a sticker.


12

The Traditional Development

v  Analysis v  Design v  Coding v  Testing


13

Traditional Project Challenge


14

The Traditional Development - Assumptions Traditional model is a good fit when: v  Customer knows all requirements upfront v  Requirements are stable v  Technology is well known and mature v  The problem has been solved before v  Everything goes as per plan

How often are these true?


15

What are the trusts ? v  The client doesn’t know what they want v  The client thinks they know what they want but are wrong v  We don’t understand what the client wants v  We think we understand but we are wrong v  We don’t know how to do it v  We thought we knew how but we were wrong v  Changes to external factors alter the objectives v  The client has learned along the way that they now want something different


16

Weakness of traditional software development method v  All good ideas should come in the beginning, a good idea at the release stage is a threat v  Emphasis on writing things down – leads to lack of clarity in thought and understanding v  Last minute correction not possible v  Unanticipated technical problems may lead to collapse in the model


17

The Traditional Process

Analysis Time

Design Coding Tes0ng

(The cost of change increases)


Do we have ½ final product yet?

18

Legacy of waterfall Model v  Ask Customers what they want §  When they really don’t know v  Reward them for thinking everything upfront §  And manage that as ‘scope’ v  Penalize them for adding things later §  Do strict ‘scope’ control

The result is over production of features


19

Features of traditional software v  Biggest cost of Predictive Development is over production of features v  Must be designed, built and maintained

Always Used 7%

Frequently Used 13%

Never Used 45%

v  Don’t get used, provide no value

Rarely Used 19%


Some0mes Used 16%

20

AGILE INTRODUCTION


21

Video demo

20 Oracle Agile PLM Customer Results in 90 Seconds


22

What is Agile Software Development? In the late 1990’s several methodologies began to get increasing public attention. Each had a different combination of old ideas, new ideas, and transmuted old ideas. But they all emphasized: v  close collaboration between the programmer team and business experts; v  face-to-face communication (as more efficient than written documentation); v  frequent delivery of new deployable business value; v  tight, self-organizing teams; v  and ways to craft the code.


23

Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:


24

Principles behind the Agile Manifesto

1 2 3

•  Our highest priority is to satisfy the customer through early and continuous delivery of valuable so_ware

•  Welcome changing requirements, even late in development. Agile processes leading the change for the customer’s compeccve advantage.

•  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter cmescale.


25


4 5 6

•  Business people and developers must work together daily throughout the project.

•  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

•  The most efficient and effective method of conveying information to and within a development team is face-‐to-‐face conversacon.


26


7 8 9

•  Working so_ware is the primary measure of progress.

•  Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

•  Concnuous ahencon to technical excellence and good design enhances agility.


27


10 11 12

•  Simplicity the art of maximizing the amount of work not done is essencal.

•  The best architectures, requirements, and designs emerge from self-‐organizing teams.

•  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


28

Agile Process

A N A L Y S I S D E S I G N C O D I N G T E S T I N G

20% done 100% usable

Time

The best way to manage ‘scope’ is to write less code! •  Develop 20% of features that deliver 80% values • Develop and deploy highest priority first • Stop when you run out of 0me or money


29

Waterfall Model vs. Agile Process Waterfall Model

Agile Process

Analysis

Analysis

Design

Design

Coding Tes0ng Time

Coding Tes0ng Time


30

Some advantages of the Agile approach v  The customer has frequent and early opportunities to see the work being delivered, and to make decisions and changes throughout the development project. v  The customer gains a strong sense of ownership by working extensively and directly with the project team throughout the project. v  If time to market for a specific application is a concern, Agile can more quickly produce a basic version of working software. v  Development is often more user-focused, likely a result of more and frequent direction from the customer


31

Some disadvantages of the Agile approach v  The very high degree of customer involvement may present problems for some customers who simply may not have the time or interest for this type of participation. v  Agile works best when members of the development team are completely dedicated to the project. v  Time-boxed delivery and frequent reprioritization, it’s possible that some items set for delivery will not be completed within the Timeboxed. Additional sprints may be needed, adding to the project cost.


32

Some disadvantages of the Agile approach The iterative may lead to a reduction in overall system quality, as there is less emphasis on understanding the finished system as a whole early in the project.


33

Exercise 2: Drawing a picture Draw a picture based on Waterfall model – 20 minutes v  Customer looks at a picture carefully. v  Customer explains the picture to the team. v  The team listen requirement from customer and take a note. v  The team draw a picture.

Draw a picture based on Agile – 20 minutes v  Customer looks at a picture carefully. v  Customer joins with the team to draw the picture. v  Every 5 minutes, customer can look at the original picture and come back with the team.


34

Exercise 2: Drawing a picture


35

Exercise 2: Drawing a picture


36

How to deliver project?


37

Agile Methods v  Scrum v  Extreme Programming v  Adaptive Software Development (ASD) v  Dynamic System Development Method (DSDM) v  Feature Driven Development (FDD) v  Lean Software Development v  Lean/Kanban v  …


38

Video demo 1. Five Levels of Agile Planning 2. Agile vs Traditional System Development


39

AGILE SCRUM INTRODUCTION Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

40

SCRUM The agility way…. Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

41

Video demo

1. Scrum Master Training


42

History of Scrum v  1995 §  Analysis of common software development processes not suitable for empirical, unpredictable and non-repeatable processes §  Design of a new method: Scrum by Jeff Sutherland and Ken Schwaber §  Enhancement of Scrum by Mike Beedle and combination of Scrum with extreme programming v  1996 §  Introduction to Scrum at the OOPSLA conference v  2001 §  Publication of the Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

43

What is Scrum used for? v  US FDA-approved software for X-Rays, MRIs v  High availability systems (99.9999% uptime) v  Enterprise workflow systems v  Financial payment applications v  Large database applications v  Embedded systems v  ISO 9001 organizations v  CMMi Level 5 organizations v  Onshore / offshore development


44

Who is using Scrum?


45

Even the Government is doing it…


46

Share


47

What is Scrum? “Scrum is a framework for developing complex product and systems. It is grounded in empirical process and control theory. Scrum employs an iterative and incremental approach to optimize predictability and control risk.” - Ken Schwaber


48

A Management Framework v  Scrum is a management framework for incremental product development using one or more cross-functional, self- organizing teams of about seven people each. v  It provides a structure of roles, meetings, rules, and artifacts. v  Teams are responsible for creating and adapting their processes within this framework. v  Scrum uses fixed-length iterations, called Sprints, which are typically two weeks or 30 days long. v  Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration


49

Scrum Framework v  Scrum is designed to add energy, focus, clarity, and transparency to project planning and implementation. It will: §  Increase speed of development §  Align individual and corporate objectives §  Create a culture driven by performance §  Support shareholder value creation §  Achieve stable and consistent communication of performance at all levels §  Enhance individual development and quality of life


50

Scrum Has Three Legs

We all know what Is going on

Transparency

Adaptacon

Check your work as you do it.

Inspeccon

OK to change tacccal direccon Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

51

Scrum Values v  Commitment

Scrum asks you to commit to a goal and then provides you with the authority to meet those commitments.

v  Focus

It insist that you focus all your efforts on the work you’re committed to and ignore anything else.

v  Openness

Openness is prompted by the fact everything about a scrum project is visible to everyone.

v  Respect

Scrum tenets acknowledge that the diversity of team members’ background and experience adds value to your project.

v  Courage

Finally, Scrum asks you to have courage to commit , to act, to be open and expect Respect Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

52

Scrum framework


53

Product Owner

•  Product Owner decides what should be produced so as to achieve success SPRINT •  Gets inputs from end users, team managers, stakeholders, execucves, industry experts etc NO CHANGE

uracon or Goal •  Produces the product in bDacklog which contains the features of the product to be produced in order of priority


54

Product Backlog

•  The Product Backlog is the single master list of features, funcconality etc… prioriczed based on business value and risk •  The Product Backlog is constantly being revised by the Product Owner, to maximize the business success of the team’s efforts


55

Scrum Team

•  Ideally consists of 7+/-‐ 2 people •  The team has to be cross funcconal – containing members from the different verccals required for developing the product • The team is self organizing and self managing – makes a commitment and manages its responsibilices


56

Sprint

• Sprint is referred to the fixed period of cme the team commits to work in course of developing the product • The length of the sprint is decided by the Team and the Product Owner • Working at a sustainable pace is important to avoid burn out


57

Sprint Planning Meeting

•  Before each Sprint, the team selects what it will commit to deliver by the end of the Sprint. •  The team creates a task-‐level plan for how they will deliver. •  The team works together to create an inical assignment of tasks, and compares total escmated task hours with total escmated available hours, to make sure the commitment is reasonable. • Everyone on the team takes part, regardless of experience-‐level


58

Sprint Backlog

•  The Sprint Backlog lists all the tasks, and the hours remaining for each. • The Task Board shows where tasks are in progress. •  The Sprint Backlog is updated every day by team member


59

The “no change” of Sprint

• During the Sprint, what the team commihed to deliver does not change, and the end-‐date of the Sprint does not change. • This enables team to make and keep commitments, it gives the team focus and stability during the Sprint, and it trains Product Owner to clearly think through what is on the Product Backlog. • If something major comes up, Product Owner can direct the team to terminate the Sprint prematurely, and start a new one

NO CHANGE

in Duracon or Goal


60

The “no change” of Sprint (continue)

• In return for not making changes during the Sprint, Product Owner can make any changes they want to the Product Backlog before the start of the next Sprint. • Product Owner can add, remove, reorder, or change items. They can also ask the team to re-‐implement work that’s already been completed.

NO CHANGE

in Duracon or Goal


61

Daily Standup Meeting

Each day, the team has a short meecng to update each other on progress and surface blocks. They stand up, to keep it fast. • To keep the meecng to 15 minutes, everyone reports just 3 things: done since yesterday, done by tomorrow, and blocks. • Scrum Master notes blocks, and a_erwards helps resolve them. • Others can ahend the meecng if the team invites them, but they do not speak. This meecng is not for monitoring team


62

Burnt-down Chart

Each day, the team updates simple charts that make visible how they are progressing towards their goal for the Sprint. • The Sprint Backlog lists all the tasks, and the hours remaining for each. The Burn-‐down Chart graphs the total hours le_ for all tasks. The Task Board shows where tasks are in progress. • These charts enable the team to successfully self-‐manage and deliver what they commihed to by the end of the Sprint


63

Scrum Master

The ScrumMaster is a new role. It can be played by an exiscng person (such as a former Project Manager or team-‐member). • The ScrumMaster serves the team (helping them remove any and all impediments that surface), protects the team (from any outside disrupcon or interference), and teaches and guides the team’s use of Scrum. • Without a ScrumMaster, the team has a high risk of failure.


64

Finished Work

The aim for the team is to complete 100% of what they commihed to, ideally an increment of Potencally Shippable Product at the end of each Sprint. • For so_ware, this means funcconality that has been designed, fully implemented, and fully tested, with no major defects. • Few teams can do product Potencally Shippable Product from Sprint 1, but each Sprint they work to get closer to this goal.


65

Sprint Review Meeting

At the end of the Sprint, the Product Owner, Team, Scrum Master, and Stakeholders come together and see a demo of what the team has produced. • The Product Owner gathers feedback from everyone on ways to improve what’s been built. • This feedback is incorporated into the Product Backlog.


66

Sprint Retrospective

The Team, Product Owner, and Scrum Master meet at the end of each Sprint to review their way of working, and look for ways to improve their effeccveness. • This is the mechanism for concnuous improvement, and also where criccal problems are idencfied and addressed, or surfaced to management for assistance


67

Components of Scrum

Scrum Ar0facts

Scrum Roles

Scrum Ceremonies (Events)


68

Benefits of Scrum v  Improvement Statistics:

§  Productivity Improvement – 68% §  §  §  § 

Team Morale – 52% Adaptability – 63% Accountability – 62% Collaboration and Cooperation – 81%


69

Challenges of Scrum v  Inability to get everyone involved with planning v  Failure to have dedicated roles –Scrum Master, Product Owner and Team v  Product Owner that isn’t ready for the team v  Teams lacking authority and decision-making ability v  Ineffective use of the retrospection v  Obtaining only “checkbook commitments” from executive management v  Failure to pay attention to infrastructure required v  A culture that does not support learning


70

Summary v  It is an iterative, incremental framework v  Sprints – cycles of work developed, duration 2 – 4 weeks; occur one after another without pause v  Time-boxed – they end whether or not the work ends v  At the beginning, cross-functional team forms the priority list based on customer requirements v  During the sprint the chosen items do not change v  Everyday inspection and adjustment v  End of the sprint, review with stakeholders v  Feedbacks are taken and incorporated into the sprint v  End of sprint, fully tested product is formed as per customer requirements Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

71

Video demo

1. Scrum introduction


72

Exercise 3: SCRUM Roles SCRUM: v  List all of roles of SCRUM. Each role will be written in a sticker. v  Put all of the tasks of Waterfall model match to SCRUM roles.


73

SCRUM ROLES Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

74

Scrum Roles

SPRINT

NO CHANGE

in Duracon or Goal


75

Story of Pig and Chicken


76

Roles - Chickens v  “Chicken” roles Chicken roles are not part of the actual Scrum process, but must be built. v  Stakeholders (customers, vendors) These are the people who enable the project and for whom the project They are only directly involved in the process during the sprint reviews. v  Managers People who will set up the environment for the product development organizations.


77

Roles - Pigs

Product Owner

Scrum Master

Scrum Team

Pigs

The Pigs are the ones committed to the project and performing the actual work of the project. Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

78

Product Owner Role v  Single person responsible for maximizing the return on investment (ROI) of the development effort v  Responsible for product vision v  Constantly re-prioritizes the Product Backlog, adjusting any long-term expectations such as release plans v  Finalize the answer for requirements questions v  v  v  v 

Accepts or rejects each product increment Decides whether to ship Decides whether to continue development Considers stakeholder interests

v  May contribute as a team member v  Has a leadership role Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

79

Product Owner Role The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. The Product Owner is the sole person responsible for managing the Product Backlog, includes: v  Clearly expressing Product Backlog items; v  Ordering the items in the Product Backlog to best achieve goals and missions; v  Optimizing the value of the work the Development Team performs; v  Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and, v  Ensuring the Development Team understands items in the Product Backlog to the level needed. Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

80

As a Scrum Product Owner You… v  Hold the vision for the product on behalf of the business, the customer, and the user. v  Represent the interests of the business to the team. v  Represent the product and the team to the business. v  Communicate with stakeholders regularly. v  Write user stories. v  Help others write user stories. v  Understand the business value of each user story. v  Assign numeric business value to each user story. v  Prioritize the user stories into a strictly ordered backlog.


81

As a Scrum Product Owner You…(continue) v  Identify acceptance criteria for each story. v  Collaborate with the rest of the team to create the team’s definition of done. v  Accept or reject completed work, determining whether it has met the acceptance criteria. v  Resolve conflicting requirements from stakeholders. v  Provide the information that the team needs to estimate each story. v  Make yourself available to answer the team’s questions about requirements and business value. v  Make the call in the rare instances when a sprint needs to be terminated early.


82

As a Scrum Product Owner You…(Continue) v  Clarify requirements for the team. v  Lead the first part of the sprint planning meeting. v  Lead the story time meetings. v  Gather feedback from stakeholders at the sprint review. v  Do not hold the role of scrum master. v  Do not do implementation work. v  Do not tell the team how to do the work. v  Do not estimate stories


83

Video demo 1. The Impatient Product Owner


84

Exercise 4: Product Owner Role SCRUM: v  List all of the tasks of a product owner and put the tasks under Product Owner role on the board.


85

Scrum Team

SPRINT

NO CHANGE

in Duracon or Goal


86

The Development Team role The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. v  They are “self-organizing” v  They are “cross-functional” v  They decides “what to commit to” v  Scrum recognizes no titles for Development Team members v  Scrum recognizes no sub-teams in the Development Team, v  Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole. Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

87

The Development Team role (Continue) v  One team normally does all the work - planning, analysis, programming, and testing v  Negotiates commitments with the Product Owner, one Sprint at a time v  Develops the product and gives ideas to the product owner v  Has autonomy regarding how to reach commitments v  Intensely collaborative v  Most successful when located in one team room, particularly for the first few Sprints v  Normally contain 7+ or – 2 people v  Avoid multi-tasking, avoid member changing


88

The Development Team Responsibilities v  The Scrum Team is responsible for the high-quality and timely delivery of sprint commitments in line with the expectations of the Product Manager and Product Owner. v  The Scrum Team is cross-functional and multi-skilled they know their strengths and work together to support each other through challenging times. v  The team members are not all experts in every area, however between them they have a wide range of abilities and areas of expertise. v  The Scrum Team takes responsible for their commitments and are held singularly accountable for their actions and decisions -- they are as one.


89

The Development Team Responsibilities v  The Scrum Team demonstrate their output to the Product Manager and relevant Product Owner(s) and Stakeholders at the end of each Sprint. v  The Scrum Team self-organize in order to deliver Sprint commitments. they do whatever is required in order to deliver the highest quality/value output during a sprint. [PROACTIVE] v  Question the Product Manager/Product Owner to ensure they fully understand the requirements of the Product Owner and end-user


90

Video demo

1. Team Work - https://www.youtube.com/watch?v=o9mdHMtxOjY


91

Exercise 5: SCRUM Team Role SCRUM: v  List more the tasks of a SCRUM team and put the tasks under SCRUM TEAM role on the board.


92

Scrum Master

SPRINT

NO CHANGE

in Duracon or Goal


93

Scrum Master role v  The Scrum Master is responsible for ensuring Scrum is understood and enacted by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. v  The Scrum Master is a servant-leader for the Scrum Team. v  The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. v  The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.


94

Scrum Master role v  Facilitates the Scrum process v  Creates an environment conducive to team self-organization v  Captures empirical data to adjust forecasts v  Enforces time-boxes v  Keeps Scrum artifacts visible v  Promotes improved engineering practices v  Has no management authority over the team v  Has a leadership role


95

As A Scrum Master You… v  Serve as the keeper of the scrum process, “holding space” for the team. v  Provide facilitation for team meetings during the sprint this can mean leading them yourself, recruiting an outside facilitator, or helping the team facilitate their own meetings. v  Know when to step back and let the team learn through their own experience, including mistakes. v  Are available to the team and the product owner to answer questions and give advice. v  Protect the team from outside distractions, serving as a buffer between the team and external stakeholders. Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

96

As A Scrum Master You… v  Remove impediments for the team, so they can get on with the work. v  Are not the boss. Your role is defined by a unique set of responsibilities, not by rank. v  Act as an advocate for the team to the business. v  Coach the product owner in scrum practices. v  Help the team master the use of scrum artifacts, like the task board, the sprint backlog, and burn charts. v  Coach the team, and individual team members, in scrum practices.


97

As A Scrum Master You… v  Lead the daily scrum until the team members are comfortable running it by themselves. v  Run the second half of the story time meeting, or assist the team members in running it themselves. v  Provide facilitation for, and participate in, the sprint retrospective. v  Are not the scrum police! You’re not there to tell the team what they’re doing wrong. v  Ensure that your duties as a technical contributor.


98

Scrum Master Skills v  Facilitating. v  Listening. v  Working towards self-organizing the team. v  Leading by serving.


99

Video demo 1. The Power of Scrum Master


100

Exercise 6: SCRUM Master Role SCRUM: v  List all of the tasks of a SCRUM Master and put the tasks under SCRUM Master role on the board.


101

SCRUM ARTIFACTS


102

Product Backlog v  Is a high-level document for the entire project. v  Force-ranked list of desired functionality v  Contains backlog items: broad descriptions of all required features, wishlist items, etc. prioritized by business value. v  Visible to all stakeholders v  Any stakeholder (including the Team) can add items to Product Backlog. v  Constantly re-prioritized by the Product Owner. Business value is set by the Product Owner. Development effort is set by the Team. v  Items at top are more value than items at bottom v  Maintained during the Backlog Refinement Meeting v  A Product Backlog is never Done.


103

Product Backlog


104

Product Backlog

Product Backlog items (user stories, features, or bugs)

Items are listed in top-down priority order

-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐ -‐

#

-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐ -‐-‐-‐-‐

#

-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐ -‐

#

-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐ -‐-‐-‐-‐

#

Estimate for each backlog item


105

Product Backlog

Priority

Description

Size

Value

(from SizeTeam)

(from Product Owner)

1

Feature A

3

Extra-High

2

Feature B

5

Extra-High

3

Feature C

3

High

4

Feature D

8

Extra-High

5

Feature E

5

High

6

Feature F

2

Medium

7

Feature G

13

High

8

Feature H

3

Low


106

Product Backlog

Priority

Description

Size

Value

(from Team)


1

Feature A

3

Extra-High

2

Feature B

5

Extra-High

3

Feature C

3

High

4

Feature D

8

Extra-High

5

Feature E

5

High

6

Feature F

2

Medium

7

Feature G

13

High

8

Feature H

3

Low


107

Product Backlog Item (PBI) v  Specifies the what more than the how or who of a customer-centric feature v  Often written in User Story form v  Has a product-wide definition of done to prevent technical debt v  May have item-specific acceptance criteria v  Effort is estimated by the team, ideally in relative units (e.g., story points)


108

Product Backlog Item (PBI)


109

Product Backlog- Video demo 1. Populate Product Backlog 2. Prioritize Backlog


110

Exercise 7: Develop a Product Backlog Product Backlog: v  Each team will discuss and develop a product backlog for a specific software project such as develop a website for a training center. v  Each product backlog item will be written on a stick note and put on a board.


111

Sprint Backlog v  Consists of committed PBIs negotiated between the team and the Product Owner during the Sprint Planning Meeting v  Scope commitment is fixed during Sprint Execution v  Initial tasks are identified by the team during Sprint Planning Meeting v  Team will discover additional tasks needed to meet the fixed scope commitment during Sprint execution v  Visible to the team v  Referenced during the Daily Scrum Meeting


112

Sprint Backlog


113

Sprint Task v  Specifies how to achieve the PBI’s what v  Requires one day or less of work v  Remaining effort is re-estimated daily, typically in hours v  During Sprint Execution, a point person may volunteer to be primarily responsible for a task v  Owned by the entire team; collaboration is expected


114

Sprint Task


115

Sprint Video demo 1. Populate Sprint Backlog 2. Sprint


116

Monitoring Sprint Progress v  Make the daily sum of remaining work v  Create trend v  Post for high visibility v  Reflects Development Team intuition v  Burn down charts are common


117

Sprint Burn down Chart v  Indicates total remaining team task hours within one Sprint v  Re-estimated daily, thus may go up before going down v  Intended to facilitate team self-organization v  Fancy variations, such as itemizing by point person or adding trend lines, tend to reduce effectiveness at encouraging collaboration v  Seemed like a good idea in the early days of Scrum, but in practice has often been misused as a management report, inviting intervention. The Scrum Master should discontinue use of this chart if it becomes an impediment to team self-organization.


118

Sprint Burn down Chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. It is useful for predicting when all of the work will be completed


119

Definition of Done v  Agile teams make an agreement on what criteria potentially shippable software in their environment. This agreement is called the definition of done. v  The DoD serves as a contract the delivery team writes with its stakeholders as well as the team’s standard of excellence. v  Creating the Definition of Done is a collaborative effort between the Scrum Master, Delivery Team and Product Owner. v  The initial Definition of Done can be created before or during the future iteration planning meeting, and continually revisited in future iteration planning meetings.


120

Definition of Done (DOD) v  Defines the acceptance criteria for a user story. v  It states the deliverables that accompany each Product Backlog item. v  Applies to all stories. v  Set by Product Owner in discussion with SCRUM Team. v  Should be clear and self explanatory. v  Separate DOD for Story, Sprint and Release.


121

Exercise 8: Develop a DOD for Story Definition of Done: v  Each team will discuss and develop a DOD for story.


122

Sample DOD for Story v  All story should have automated acceptance test. v  The story should have working code supported by unit test that provide around 60 – 70 percent coverage. v  The story should have well defined acceptance criteria. v  The code must have been written as a pair or should be code reviewed. v  Code must be completely checked in to the source control system and the build should pass with all the automated tests running. v  The product owner must accept the story.


123

Sample DOD for Sprint v  Product owner should have defined a sprint goal. v  All stories completed for the spring must be accepted by the product owner v  All the automated acceptance tests should be running for the stories in the sprint. v  The completed stories demonstrated successfully.


124

Sample DOD for Release v  Product is deployed to the test box and makes it to staging v  Product has a formal release date. v  There are deployment documents for the release v  Training manuals are available for users. v  All stories for the release are completed and accepted. v  The release does not have any level one bugs.


125

DoD Video demo

1. Agile in Praccce_ Definicon of Done


126

• 

Tài liệu được biên soạn bởi Ông Đoàn Đức Đề theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin/Bộ TT & TT

SCRUM MEETING Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

127

Sprint Planning

SPRINT

NO CHANGE

in Duracon or Goal


128

Sprint Planning meeting v  The purpose of the Sprint planning meeting is for the team to commit to the completion of a set of the highest ranked product backlog items. v  This commitment defines the Sprint backlog and is based on the team’s velocity or capacity and the length of the Sprint timebox The sprint planning meeting is to v  Establish goals for your sprint. v  Choose the user stories that support those goals. v  Break user stories into specific development tasks. v  Create a sprint backlog.


129

Sprint Planning Meeting v  Iteration planning is a collaborative effort involving these roles: §  Scrum Master - facilitates the meeting §  Product Owner - represents the detail of the product backlog items and their acceptance criteria §  Delivery Team/Agile Team - define the tasks and effort necessary to fulfill the commitment There are two sections in the Sprint planning meeting 1. Setting goals and choosing user stories 2. Creating tasks for the sprint backlog • 

@ Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

130

Setting goals and choosing user stories During a sprint planning meeting, the product owner and development team, with support from the scrum master: v  Discuss and set a sprint goal: The sprint goal should be an overall description supported by the highest-priority user stories in the product backlog. v  Review the user stories: Review the user stories from the product backlog that support the sprint goal and revisit and adjust the effort estimates as necessary. v  Determine what the team can commit to in the current sprint: The development team should agree and confirm it can complete the goal planned for this sprint.


131

Creating tasks for the sprint backlog v  Creates the sprint backlog tasks associated with each user story: Break the user stories into discrete individual tasks and allocate a number of hours to each task. v  Double-checks that the team can complete the tasks in the time available in the sprint: Be careful about over- committing at the beginning of a sprint, especially in the project's first few sprints. Note : If the tasks exceed the hours available, seek the project owner’s advice on which user stories to remove from this sprint.

v  Each member chooses a first task to accomplish: Development team members should work on only one task on one user story at a time


132

Sprint Planning Meeting v  The maximum time for planning a 30-day Sprint is eight hours, reduced proportionally for a shorter Sprint.


133

Sprint Planning 1 Calculate the team’s

total manhour capacity for the upcoming Sprint

5 people x 2 wks x 6hrs/day: 300.0 Minus vacation: 224.0 Minus 20% Slack/ Risk Buffer: 179.2 Commitment Cap: 179.2

2 Add the manhour

estimates for all the Sprint Backlog tasks

3 Compare the 2

numbers to help the team confirm the commitment is reasonable 179 ≈ 176 è J Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

176

134

Sprint Planning – Best Practice

Divide the Planning into 2 Halves

•  In the first half, the Product Owner briefs the team on the next priorities from the Product Backlog, and the Team selects a set of items they deem reasonable •  In the second half, the team decomposes the commitments into the Sprint Backlog of action items and tasks needed to accomplish those commitments

Defer Task Assignments

•  Many teams spend too much effort pre-assigning Sprint Backlog action items to Team Members, often causing the Sprint Planning to last many hours too long. •  Consider leaving the task assignments until later. This will allow Team Members the opportunity to self-assign the tasks, generating more buy-in.

Defer Unknown Details

•  The Sprint Backlog is an imperfect living work plan. 30-40% of the Sprint Backlog tasks will change over the course of the Sprint. •  Consider deferring the task definition for those things that are not fully understood, and simply


135

Video demo

1. How to improve your Scrum Sprint Planning 2. Agile in Praccce_ Prioricsacon using MoSCoW


136

Daily Scrum

SPRINT

NO CHANGE

in Duracon or Goal


137

Daily Scrum

Same cme Every day

Same place

Daily Scrum

15 minutes

Each team member summarizes v  What did you do yesterday? v  What will you do today? v  Are there any impediments in your way? • 


138

Daily Scrum v  The daily stand-up should be time-boxed. v  The Scrum Master should facilitate regular daily meeting times. Don't change the time of this meeting if you can avoid it; Scrum requires discipline. v  Each member of the team should participate in this meeting v  Don't update the sprint backlog during this meeting. v  Team members should be active listeners so they know how the team as a whole is doing, and so they can help one another resolve impediments. v  Ensure that each team member remains present till the end of the meeting because of the purpose of the stand-up is to understand how well we're doing to achieve sprint goals as a team. Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

139

Video demo

1. How to improve your Daily Scrum


140

Sprint Review

SPRINT

NO CHANGE

in Duracon or Goal


141

Sprint Review Meeting v  After Sprint execution, the team holds a Sprint Review Meeting to demonstrate a working product increment to the Product Owner and everyone else who is interested. v  The meeting should feature a live demonstration, not a report. v  The Product Owner reviews the commitments made at the Sprint Planning Meeting and declares which items he now considers done. v  The Scrum Master helps the Product Owner and stakeholders convert their feedback to new Product Backlog Items. v  The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend v  Four-hour time limit


142

Sprint Review - Video demo

1. How to improve your Review Meecng


143

Sprint Retrospective

SPRINT

NO CHANGE

in Duracon or Goal


144

Sprint Retrospective Meeting v  All team members reflect on the past sprint v  Make continuous process improvements v  Two main questions are asked in the sprint retrospective: §  What went well during the sprint? §  What could be improved in the next sprint? v  Three-hour time limit v  This meeting is facilitated by the Scrum Master


145

Common impediments and Mistakes Common impediments v  A common impediment to full transparency on the team is the presence of people who conduct performance appraisals v  The human tendency to jump to conclusions and propose actions too quickly v  The psychological safety is geographic distribution

Common mistakes v  Mistake 1: Retrospectives become a dull and boring routine. v  Mistake 2: Too many non-actionable improvements. v  Mistake 3: Focus on what can NOT be changed next sprint Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

146

Retrospective - Video demo

1. How to improve your Retrospeccve meecng


147

Backlog Refinement meeting

SPRINT

NO CHANGE

in Duracon or Goal


148

Backlog Refinement Meeting v  Most Product Backlog Items (PBIs) initially need refinement because they are too large and poorly understood. v  Teams have found it useful to take a little time out of every Sprint to help prepare the Product Backlog for the next Sprint Planning Meeting. v  It is common to write Product Backlog Items in User Story form. v  Agility requires learning to split large epics into user stories representing very small product features v  The Backlog Refinement Meeting lacks an official name and has also been called “Backlog Grooming,” “Backlog Maintenance,” or “Story Time.”


149

Story, Theme, Epic


150

Backlog Refinement Meeting


151

Backlog Refinement - Video demo

1. How to improve Scrum Backlog Refinement


152

The Sprint v  The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. v  Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.


153

Sprint Goal v  A Sprint’s Goal is fixed and may not change • Decrease upstream payloads by 30%

Decrease upstream payloads by 30%

• Deliver a minimal set of administra0on features

run n o 0 plica p a e in k e c i v Ma r L Se on SQ to Oracle on ad d i 0

Increase find acc search b uracy of y 20%

Deliver a minimal set of administra0on features


154

During Sprint v  No changes are made that would endanger the Sprint Goal; v  Quality goals do not decrease; and, v  Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.


155

Canceling a Sprint v  A Sprint can be cancelled before the Sprint time-box is over. v  Only the Product Owner has the authority to cancel the Sprint.


156

Release Planning


157

Purpose of Release Planning v  To make visible as much as is known about the desired release. v  Its purpose is not to make commitments. Release planning is a collaborative effort involving these roles: v  Scrum Master - facilitates the meeting v  Product Owner - represents a general view of the product backlog v  Delivery Team/Agile Team - provide insights into technical feasibility and dependencies v  Stakeholders - act as trusted advisors as decisions are made around the release plan


158

Release planning v  Breaking down barriers – The business and stakeholders and developers all plan together. v  Interactions between people - when we do Release Planning, we get all of the people who are involved into a room so they can interact. v  Iterative and incremental –We do Release Planning once (usually near the beginning of the release development), and then again and again as needed. v  An Agile Release Plan increases in accuracy over time as the results of each iteration are incorporated into it. v  4 hours max( 2hrs for 2 week sprint)


159

Release planning Defined

A high-level roadmap that forecasts “when we will do what”

Owned by

•  Product Owner

Rules

• Only the PO can prioritize the backlog • Dependencies are offered by the team, must be considered • Velocity (average output per sprint) is required to know how much to forecast for future sprints

Best Practices

• Realistic –Explains delivery dates as best case, worst case, most likely scenarios • Fresh – Updated after each sprint Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

160

Release planning


161

Release planning

Release planning is all about understanding what you're going to do towards those themes in the next release. It is setting a common understanding amongst the teams on what the release will likely look like. It is not a commitment, rather a projection. It helps to establish a common baseline across the teams.

Steps in Release Planning Understand the goal Understand the customer requirement Priori0ze and es0mate the backlog Calculate the team velocity Create a release plan Communica0ng the release plan Upda0ng the release plan


162

Release planning v Preparing for Release Planning •  •  •  •  • 

Set themes Prepare the backlog Divvy stories up Understand the issues Identify key dates

v After a Release •  Do Release Retrospective


163

Tips for Release Planning v  Do as little planning as is necessary. v  Start release planning when you realize you need it, even if it’s near the end of the release effort. v  Plan using stickies on the walls and update them into an online tool, do that later, after the meeting. v  Don’t forget that each scrum team only commits to results for the next sprint. Everything else is merely an attempt to understand what could or should happen. v  Include vendors and other third parties who are relevant and involved in your release planning meeting. v  Revisit the release plan after each sprint and update it.


164

AGILE ESTIMATION Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

165


166

Agile Uses ‘Point” to Estimate Story Size


167


168

What is a story point? v  Story point is a random measure for estimation used by Agile teams. This is used to determine the size of effort required to complete the development of a user story.

v  A story point is usually assigned after considering following factors § 

Effort required in development of story

§ 

Complexity of story

§ 

Unknowns or risk factors in the development


169

How to assign story points? Pick a baseline story

v  In the beginning team picks up a baseline story and assigns some story point to that story. Rest of the stories are assigned story points based on their comparative size with the baseline story.

v  Baseline could be different for different teams. For example one team can assign 5 where as other can assign 3 to the same story.


170

Story Point v  Sizing sequence should be geometric series: 1, 2, 4, 8, 16, 32, … v  Mike Cohen proposed Fibonacci series: 1, 2, 3, 5, 8, ... v  Its relative data and not absolute. v  Advantage: Accuracy is less important than consistency. v  Disadvantage: Its team specific values and may not have any meaning for others. Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

171

T-Shirt Sizing v  S, M, L, XL, ... v  Apply story points later. v  Good first step for tam to adapt Relative Sizing technique. v  Advantage: Easy to grasp. v  Disadvantage: Size vs Time comparison is difficult


172

Planning Poker

3 5

• 

3 • 

•  5

5

5 • 

3

5

5

5 3


173

Poker Estimation

Estimator

Round 1 Round 2

Sheila

3

5

Raj

8

5

Suresh

2

5

Annie

5

8


174

Exercise 9: Poker Estimation Poker estimation: v  Each team will use poker estimation to estimate a picture given by instructor.


175

User Story inputs

Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT Tài liệu được biên soạn bởi Ông Đoàn Đức Đề theo yêu cầu của

@Author : Đoàn Đức Đề [email protected]

176

Sizing


177

Sizing

Priority

Description

Size

Value

(from Team)


1

Feature A

3

Extra-High

2

Feature B

5

Extra-High

3

Feature C

3

High

4

Feature D

8

Extra-High

5

Feature E

5

High

6

Feature F

2

Medium

7

Feature G

13

High

8

Feature H

3

Low


178

Velocity v  Is how much product backlog effort a team can handle in one sprint. v  It is measured in Story Points. v  Once established, velocity can be used to plan projects and forecast release and product completion dates. v  Can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. v  Should not vary too much. v  How to establish velocity for a new team? :- Run 2-3 sprints without any set velocity. Benchmark could be the mean velocity of first 3 sprints.


179

Velocity 1

1

2

1

2

1

2

1 2

1 2

1 2

1

1

2

2

3

1 2

1 1

3

5

Sprint 1

Sprint 2

15 Points

12 Points

of size

of size

Sprint 3

14 Points of size

Average of ~14 Points per Sprint è “Velocity” Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

180

Velocity The Product Backlog Priority

Descripcon

Size (to build)

1

Feature A

3

2

Feature B

4

3

Feature C

3

4

Feature D

2

5

Feature E

4

6

Feature F

4

7

Feature G

3

8

Feature H

5

9

Feature I

2

10

Feature J

4

11

Feature K

2

12

Feature L

4

Total = 40 points Velocity = 14 points Time to complete = 40/14 = 2.8 Sprints


181

Planning Poker Video demo

1. Agile in Praccce_ Planning Poker 2. SCRUM 03 -‐ Escmate Backlog Using Planning Poker


182

AGILE REQUIREMENT


183

Key Principles for Agile Requirements v  Active user involvement is imperative v  Agile teams must be empowered to make decisions v  Requirements emerge and evolve as software is developed v  Agile requirements are ‘barely sufficient’ v  Requirements are developed in small, bite-sized pieces v  Enough’s enough – apply the 80/20 rule v  Cooperation, collaboration and communication between all team members is essential.


184

A picture is worth a thousand words


185

Requirements are a Communication Problem v  Written requirements

v  Verbal requirements

§  can be well thought through, reviewed and edited

§  Instantaneous feedback and clarification

§  provide a permanent record

§  Information packed exchange

§  are more easily shared with groups of people

§  easier to clarify and gain common understanding

§  may be less relevant or superseded over time

§  more easily adapted to any information know at the time

§  can be easily misinterpreted

§  can spark ideas about problems and opportunities


186

What is User Story? v  A user story is one or more sentences in the everyday or business language of the user or customer that captures what the user or customer wants to achieve through software. v  They tell a short story about how the user, customer or other persona will use the system, and what benefit they derive from the functionality. v  The goal is to provide context, which helps the Product Owner effectively manage and rank the backlog, and help the team understand how to implement functionality with the goals of customers in mind.


187

User Story v  A simple statement in a user story format gets us started, but doesn’t tell the whole story. v  The Three C’s indicate the three elements of a user story Card, Conversation, Confirmation. 1. Card - A written description of the user story for planning purposes and as a reminder 2. Conversation - A section for capturing further information about the user story and details of any conversations 3. Confirmation - A section to convey what tests will be carried out to confirm the user story is complete and working as expected


188

Story Card

As a [user role] I want to [goal] so I can [reason] For example: As a registered user I want to log in so I can access subscriber-only content


189

Story Card description v  Who (user role) v  What (goal) v  Why (reason) •  Gives clarity as to why a feature is useful can influence how a feature should function can give you ideas for other useful features that support the user's goals


190

Conversation v  Through conversation, the Product Owner and Delivery Team develop a shared understanding of the goals for functionality as well as the constraints. Often the team asks questions. v  For our password reset example, questions might include: §  What type of authentication do we need? §  What information do we need to collect about the user? §  Are there different types of users that we have to worry about? v  The whole team can participate in these discussions. Different roles and different viewpoints will surface different questions and concerns.


191

The Confirmation – Acceptance Criteria v  How will the Product Owner confirm that the story was implemented properly? v  Acceptance criteria are the conditions of satisfaction and acceptance for the story. v  Product Owners and the Delivery Team work together to provide acceptance criteria and remove any ambiguity from the user story. v  Acceptance Criteria for our Reset Password story might include: v  Username, password, and email address are all required. Display name can be provided, but is optional. v  Passwords can be 6 – 200 characters in length. v  Passwords should be stored encrypted and cannot be decrypted.


192

User Story Example: Front of Card


193

User Story Example: Back of Card


194

How detailed should a User Story be?

Detailed enough for the team to start work from, and further details to be established and clarified at the time of development.


195

INVEST in Good User Stories v  Independent – User Stories should be as independent as possible.

v  Negotiable – User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.

v  Valuable – User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.


196

INVEST in Good User Stories v  Estimateable – User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.

v  Small – User Stories should be small. Not too small. But not too big.

v  Testable – User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.


197

User Stories Summary v  User Stories combine written and verbal communications, supported with a picture where possible. v  User Stories should describe features that are of value to the user, written in a user’s language. v  User Stories detail just enough information and no more. v  Details are deferred and captured through collaboration just in time for development. v  Test cases should be written before development, when the User Story is written. v  User Stories should be Independent, Negotiable, Valuable, Estimable, Small and Testable.


198

Story Point Video demo

1. Agile In Praccce_ StoryCards_User Stories 2. Non-‐Funcconal Requirements Add Value to User Stories


199

Exercise 10: User Stories User Stories: v  Each team writes user stories of your product backlog. v  Use poker cards to estimate your user stories


200

Product Backlog Prioritization Overview v  Prioritization is a process of ranking user stories in product backlog. v  Highest customer value first. v  Owned by Product Owner. v  To be revisited whenever new requirement comes.


201

Criteria for Prioritization


202

MoSCoW Method


203

Exercise 11: Prioritization Prioritization: v  Each team prioritizes PBIs in your product backlog.


204

TESTING IN AGILE


205

How testing is different in Agile? Traditional Testing

Agile Testing

Testing occurs at the end

Testing occurs iteratively within each Sprint

Communication is formal

Communication cannot always be formal as interaction is required between the groups

Test Automation is optional

Automation is highly recommended

Testing from Requirements

Testing from Customers perspective

Detailed Test Plan exists

Lean Test Planning


206

Testing in agile 1.  During the planning phase of a project, agile testers do: v  Help the rest of the team understand the user stories v  Only take on stories that can be fully tested by the end of the sprint v  Collaborate with customers to better understand their stories v  Collaborate with developers to make sure all have the same understanding v  Start working on high level user acceptance tests for each story v  Think about any test data or testing dependencies needed for story testing


207

Testing in agile 2.  When in coding and testing phase of the project, testers do: v  Write detailed tests once coding starts v  Start with simple tests and add more complex ones later on v  Complete tests for one story at a time v  Identify testing obstacles as early as possible and communicate to team v  Facilitate communication between the customers and developers for issues that arise from coding and testing. v  Write some manual tests for scenarios that are too difficult to automate with the automated agile testing tool in hand. v  Start automating tests once enough code is written for regression suite.


208

Testing in agile 3.  During the final stage & post-release testers take part in: v  Identifying testing related obstacles during sprint v  Estimating if there was enough time to test all completed stories v  Finding ways to improve next sprint v  Demo product to business owners for feedback


209

Challenges in Agile Testing v  Testing occurs within each sprint and not just at the end v  Testing teams do not have a great deal of time to develop and maintain the test scripts v  Different skills for testers v  Requirements and plan evolve over time v  The Regression testing scope increases each sprint v  Testers may lose overall system perspective while testing from sprint to sprint


210

Automation build v  Every commit to the code should be build. v  Only the latest build to be tested or used for demo. v  Early warning for broken code. v  Pushes developers for more modular and less complex code. v  Hardware cost for automated build setup. v  Ideal in case of distributed team.


211

Build Strategy: Nightly Build v  Typically take place when no one is likely to be working in the office so that there are no changes to the source code during the build. v  Takes place automatically at a specified time. v  Ideal in case of high load and short schedule. v  Can be done on a machine which is also used for active development. v  Easy to maintain. v  Finding bugs or testing can be delayed. v  Ideal in case of centrally located team.


212

Exercise 12: Spring Backlog Spring Backlog Development: v  Each team develop Spring backlog based on priority of PBIs in your product backlog.


213

AGILE - LEAN DEVELOPMENT


214

A Lean History v  Lean is a manufacturing & production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination. v  "value" is defined as any action or process that a customer would be willing to pay for. v  Lean is centered around preserving value with less work. v  Lean manufacturing is based on optimizing flow, increasing efficiency, decreasing waste, and using empirical methods to decide what matters, rather than uncritically accepting pre- existing ideas v  Toyota was a leader in implementing lean practices in the 80s


215

A Lean History


216

Seven Lean Principles

LEAN PRINCIPLES

Eliminate Waste Amplify Learning Decide as Late as Possible Deliver as Fast as Possible Empower the Team Build Integrity In See the Whole Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

217

Principle # 1: Eliminate Waste


218

What is waste? v  Anything that doesn’t add value (as perceived by the customer) to the product v  Unnecessary code or functionality v  Unclear requirements v  Slow internal communications or processes v  Bureaucracy


219

Tool #1: Seeing Waste v  Agile practices seek to eliminate waste, but the first step is to learn how to see waste v  Good examples of waste are parts of the software process that are not analysis and coding - do they really add value to the customer? v  Shigeo Shingo identified seven types of manufacturing waste v  Mary and Tom Poppendieck translated these into the software domain in the following table


220

Tool #1: Seeing Waste Learn to see waste Waste of Manufacturing

Waste of Software Development

Inventory

Partially work done

Extra processing

Paperwork or excess documentation

Overproduction

Extra features

Transportation

Task Switching

Waiting

Waiting for the information

Motion • 

• 

Defects Wastes of Manufacturing

Learn Motion to see waste

Defects Development Wastes of Software


221

Tool #2: Value Stream Mapping v Mapping your value stream is a good way to start discovering waste in your process v This involves drawing a chart of the average customer request, from arrival to completion v At the bottom, draw a timeline that shows how much time the request spends in value-adding, waiting, and non-value- adding activities


222

Tool #2: Value Stream Mapping v  Reduce management activities such as unnecessary tracking systems. Minimize tracking by create a smooth flowing work system v  Rethink Authorization systems. Make “approvals” unnecessary v  Retrain you brain to see waste. Ask yourself “Why am I really doing this?” v  Map your value stream to identify inefficiencies


223

Principle # 2: Amplify Learning


224

Exercise 13: The Ball Game Create a process for giving and receiving the ball in your group: v  You cannot pass the ball to the person next to you v  The ball must be returned to the person who started with it. v  The ball must travel through the air v  The ball cannot be rolled across surfaces e.g. floors, walls, tables and chairs.


225

Tool #3: Feedback v  Feedback adds complexity to a system, but it also adds considerable value §  For example, a traffic light that senses cars is more useful than a traffic light on a strict timer v  The Waterfall development model does not provide much feedback; it is generally thought of as a single-pass model v  Traditional processes consider feedback loops threatening because incorporating feedback could modify the predetermined plan v  Developers should know their immediate and have ways for that customer to provide feedback


226

Tool #3: Feedback

v Increasing feedback is the single most effective way to deal with troubled software projects §  Instead of letting defects accumulate, run tests as soon as the code is written §  Instead of adding more documentation or detailed planning, check out ideas by writing code §  Instead of gathering more requirements, show the customer an assortment of potential users screens and get their input § 

Instead of studying which tool to use, bring the top three candidates in-house and test them


227

Tool #4: Iterations v  Iterations provide a dramatic increase in feedback §  The operational environment is considered early §  Design problems are exposed early §  Change-tolerance is built into the system v  Short iterations allow the system to respond to facts rather than forecasts v  Iterations are a point of synchronization between the different teams and the customer v  Iterations force decisions to be made because the system is deployed early and often Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

228

Tool #5: Synchronization v  Build the system every day after a small batch of work has been completed by each of the developers v  At the end of the day, a build takes place followed by an automated set of tests v  If the build works and the tests pass, then the developers have been synchronized v  The more builds, the better because it provides rapid feedback v  Full system tests should be run as frequently as possible


229

Tool #6: Set-Based Development Set-Based Versus Point-Based v  The point-based approach starts with one choice and is refined until it works, which takes many iterations and might not converge v  The set-based approach starts by defining everyone's constraints and then selects a choice that fits into those constraints v  Set-based development bases communication on constraints rather than choices which requires significantly less data to convey far more information v  Talking about constraints allows developers to defer making choices until the last possible moment


230

Tool #6: Set-Based Development Develop Multiple Options v  When you have a difficult problem, develop a set of solutions, see how they actually work, and merge the best features of the solutions v  It might seem wasteful to develop multiple solutions, but set- based development can lead to better solutions faster


231

Principle # 3: Decide as Late As Possible


232

Sequential versus Concurrent Sequential Depth First (Drilling into the details too fast)

Concurrent Breadth First (seeing things in full view over time)

Order of Creation ( On day 1, We created requirements)

Highest valued features first

Rigid, change is costly

Adaptable, change is manageable

Cost escalation is high when issues are found late

Cost escalation is low, as issues are found incrementally

High stakes decisions are High stakes decisions can be made based on assumptions deferred until the last and with uncertainly responsible moment


233

Tool #7: Options Thinking v  People find it difficult to make decisions when there is uncertainty present v  Delaying Decisions §  The underlying economic mechanism for controlling complexity in just-intime systems is minimizing irreversible decisions §  This contrasts with other methodologies that manage complexity by limiting decisions - e.g. "any color as long as it's black" §  Delaying irreversible decisions leads to better decisions, limits risk, helps manage complexity, reduces waste, and makes customers happy §  However, delaying decisions has a cost, but the overall system is more profitable and allows the correct decision to be made Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

234

Tool #8: The Last Responsible Moment v  The last responsible moment is the moment in which failing to make a decision eliminates an important alternative v  If commitments are delayed beyond this moment then decisions are made by default, which is generally not a good approach to making decisions v  This is not be confused with procrastination; in fact, delaying decisions is hard work


235

Tool #9: Making Decisions Depth-first versus Breadth-first problem solving v  Breadth-first problem solving could be thought of as a funnel and involves delaying decisions v  Depth-first problem solving could be thought of as a tunnel and involves making early commitments v  Depth-first is preferred when approaching new problems because it tends to quickly reduce the complexity of the problems v  If there is an expert to make early decisions correctly and an assurance that there will not be changes that render the decisions obsolete, then depth-first is more effective. Otherwise, breadth-first will lead to better results


236

Principle # 4: Deliver as Fast as Possible


237

Exercise 14: The Coins Game Each team, 5 people and 20 coins, has to follow the following rounds: v  The first round: up-side-down 20 coins and pass them to the next person. v  The second round: up-side-down 10 coins and pass them to the next person. v  The third round: up-side-down 5 coins and pass them to the next person. v  The fourth round: up-side-down 1 coin and pass it to the next person.


238

Tool #10: Pull Systems v  For rapid delivery to happen, it must be clear to every person what he/ she should do to make the most effective contribution to the business v  There are two ways to ensure that workers are productive: tell them what to do or set things up so they can figure it out for themselves v  In fast-moving situations, it is more effective to let the workers task themselve


239

Tool #11: Queuing Theory Reduce Cycle Time v  Queuing theory strives to make your wait as short as possible v  The fundamental measurement of a queue is cycle time - the average time it takes something to get from the beginning of a process to the end v  The time spent waiting in the queue is wasted time v  There are two ways to reduce cycle time - look at the way work arrives or look at the way the work is processed v  One way to control the rate of work arrival is to release small packages of work so that the queue is smaller


240

Tool #11: Queuing Theory

v  Once variability has been removed from the arriving work, the next step is to remove the variability in the processing time v  Small work packages allow parallel processing of the small jobs by multiple teams so that if one team is stalled by a problem, the rest of the project can proceed without delay v  Software organizations, like highways, cannot funtion at full capacity v  Having slack in an organization gives the capacity to change, reinvent itself, and marshal resources for growth


241

Tool #12: Cost of Delay v  Often, software teams are told that they must meet cost, feature, and date objections simultaneously. This sends two messages: §  Support costs are not important because they were not mentioned §  When something has to give, make your own trade-offs v  Instead, give the team an economic model which will empower the members to figure out for themselves what is important for business v  Trade-off decisions are easiest to make when they are expressed in the same units v  Economic models justify the cost of reducing cycle time, eliminate bottlenecks, and purchasing tools Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

242

Principle # 5: Empowering the Team


243

Tool #13: Self-Determination v Transfer practices from one environment to another is often an mistake v Let the team design their own working procedures v Remember Management’s role is coach, train, and assist the teams v It is key to understand the fundamentals principals that make up practices, and transform those principles into new practices v Managers need to improve as much as individual workers. A feedback loop is critical going both ways between managers and workers to drive improvement


Tool #14: Motivation Create a sense of purpose at work. People care about a purpose greater then themselves v  It must be clear v  It must be achievable v  The team must have access to customers v  Let the team make it’s own commitments v  Management’s role is to provide support, resources, guidance, and protection


Tool #15: Leadership Respected Leaders v  Nearly every major product development is spearheaded by a champion who is excited and passionate about their work v  They probably wrote the product concept, recruited the team, interpret the vision for the team, and set the pace for development Master Developers v  Exceptional developers exercise leadership through superior knowledge instead of bestowed authority v  It is not essential to identify a master developer at the beginning of every project as more often than not they will emerge as a result of their technical prowess Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

246

Tool #15: Leadership Where do master developers come from? v  They grow into their role through extensive experience in the technology being employed or the domain being addressed by the system v  They also possess exceptional abstraction and communication skills Project Management v  Often the project manager does not have a technical background and is not responsible for developing a deep technical understanding of the product v  They focus on identifying waste, coordinate iteration planning meetings, help team acquire resources, coordinate/ synchronize multiple teams, and provide a motivating environment (among many other things) Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

Tool #16: Expertise Share Expertise v  Promote mentorship and pair programming v  Create communities of expertise §  Identify the technical and domain specific competencies that are critical to an organization's success §  Within these communities create forums for knowledge sharing; monthly meetings, newsletters, guest speakers, etc. Enforce Standards v  Naming standards, coding standards, language standards, check in/out standards, build standards v  Develop standards and practice them v  Lack of standards leads to sloppy work v  Standards develop through experimentation and knowledge sharing


Principle # 6: Build Integrity In


249

Tool #17: Perceived Integrity Focus on keeping customer values at the forefront v  Engineers have a tendency to get lost in the details and lose track of customer values v  To prevent this, visions of perceived integrity should be refreshed regularly through customer feedback or access to groups of users who can judge the system's integrity Model Driven Design v  Construct domain models such that software implementation can flow directly from these models v  These models must be understood and directly usable by the customers and developers v  The models should express all the business rules, business processes, and domain related issues using ubiquitous language that can be understood by everyone


Tool #17: Perceived Integrity Recommended collection of Models v  Conceptual Domain Model: Class model of the basic entities of the system v  Glossary: Defines terms found in domain model and ensures consistent language for the team v  Use Case Model: A dynamic view of the system that captures customers goals for interacting with the domain model and details their expected workflow v  Qualifiers: Details the qualifiers that might be applied to the basic functionality of the system such as number of users, acceptable response time, required availability, projections for growth, etc


Tool #18: Conceptual Integrity Measured by how well a system's components work together as a smooth, cohesive whole v  Components match/work well together v  The architecture allows for a balance between flexibility, maintainability, efficiency, and responsiveness Effective communication is key to achieving conceptual integrity Reuse existing solutions v  If something has been proven to solve a problem in the past and you can make use of it, do it v  This helps to remove degrees of freedom in the development process, reduces the complexity and need for communication Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

252

Tool #18: Conceptual Integrity Employ integrated problem solving practices v  Understand and store the problem simultaneously v  Release preliminary data early and don't wait for the complete answer v  Information is released in small batches v  Information flows in two directions v  The preferred method of communication is face-to-face


253

Tool #18: Conceptual Integrity Without integrated problem solving v  Designers make decisions in isolation and send a large amount of information to those who must make decisions causing a "throw it at the wall approach" With integrated problem solving v  Frequent bilateral communication occurs which produces necessary feedback


254

Tool #19: Refactoring Complex systems have effects that aren't fully understood at design time Architecture must remain healthy as the system evolves v  New features are always being requested by users v  Features can always be added separately; often new features are related and redesigning architecture of system to support feature set is the best decision v  Resist the urge of adding features in a brute force approach and instead adjust the architecture so that system integrity does not degrade


255

Tool #19: Refactoring Maintaining conceptual integrity v  Simplicity §  A simple design is nearly always the best design §  Experienced developers know how to simplify complex designs v  Clarity §  Code must be easy to understand §  Everything should be clearly named and naming conventions and practices should be upheld


256

Tool #19: Refactoring Maintaining conceptual integrity v  Suitability for use §  Every design must accomplish intended purpose v  No repetition §  Repetition should never exist, this is a sign of bad design v  No extra features §  When Code is no longer needed, get rid of it


257

Tool #19: Refactoring

Does refactoring slow down productivity? v  Conventional wisdom suggests that the overhead associated with refactoring would slow down the team - the opposite turns out to be true v  By spending time making sure code does not get out of hand you make further development much easier and more efficient


258

Tool #20: Testing v  Testing proves that design intent is achieved and that the system does what customers want it to do § Whenever developers write code, tests should exist to ensure that the features being developed work as intended v  When developers write code he/she should get immediate feedback about whether or not it works as intended from the existing test code v  Tests should be automated as much as possible and run as part of the daily build v  Tests that cannot be automated or take too long to be run daily have much less value than those that can be run frequently Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

259

Tool #20: Testing Types of tests v  Unit tests (single component), integration tests (multiple components) and system tests (the entire system) v  Developer tests (tests that ensure code does what developer intended) and acceptance tests (also known as customer tests these tests ensure that the system functions how the customer expects)


260

Tool #20: Testing Roles of tests in development life cycle v  Communicate how things are supposed to work v  Provide feedback on whether or not the system actually works how it is supposed to v  Provide the scaffolding for developers to make changes through the development process v  After development tests provide an accurate representation of how the system was actually built


261

Principle # 7: See the Whole


262

Tool #21: Measurements v  Measurements are important for tracking the progress of software development § Example: defect counts are important for gauging software readiness v  People will increase their performance in areas that are measured v  Measurements should motivate the team to collaborate and find better ways to do things


263

Tool #22: Contracts v  A common misconception is that agile development cannot be used in the context contract work in which each firm is expected to look out for itself v  To make it work, we need to change our idea of a contract being method of keeping two parties from taking advantage of each other into something that supports collaboration v  In most cases this means being flexible with regards to scope


264

Tool #22: Contracts Incorporating Lean Development into different types of contracts v  Fixed-Price Contracts v  Time-and-Materials Contracts v  Multistage Contracts v  Target-Cost Contracts v  Target-Schedule Contracts v  Share-Benefit Contacts


265

KANBAN Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

266

What is Kanban?

v  看板 – Kanban literally means “visual card,” “signboard,” or “billboard.” v  Kanban is a method that helps §  Establish a culture of continuos improvement §  Implement and scale Agile §  Enable evolutionary change v  Kanban is a true PULL system implementation in software engineering v  Kanban is a Visual Card


267


268

What is PULL system?

v  There is a queue of work, which goes through a number of stages until it is done v  When work is completed in a stage, it goes downstream to the next stage v  When someone needs new work to do, they pull from upstream


269

Why Kanban is Pull system? WE : v  Don’t build features that nobody needs right now v  Don’t write more specs than you can code v  Don’t write more code than you can test v  Don’t test more code than you can deploy


270

Time-boxed iterative & incremental development has challenges Common problems include: v  Short time-boxes force development items to be smaller and valuable items to be spread over many iterations v  Quality of requirements suffers as analysts & UX designers rush to prepare for upcoming cycles v  Quality of current development suffers when busy analysts and UX designers are unable to inspect software or answer questions during development v  Quality often suffers as testers race to complete work late in the development time-box v  Unpredictable work makes it difficult to plan even a few weeks in advance Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

271

Inside an iteration, effort across roles is uneven

Development work often continues throughout a cycle while testing starts late and never seems to get enough time Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

272

Why Kanban? v  Goal 1: Optimize Existing Processes – Using the visualization and the limiting of work-in-progress (WIP) will catalyze change with minimal disruption. v  Goal 2: Deliver with Higher Quality – Limiting work-inprogress and defining policies for work prioritization will bring greater focus on quality. Policies can also address quality criteria directly. v  Goal 3: Improve Lead Time Predictability – There is a correlation between the amount of work-in-progress, lead time and defect rates. Limiting WIP makes lead times dependable and keeps defect rates low.


273

Why Kanban?

v  Goal 4: Improve Employee Satisfaction – Kanban reduces context switching and pulls work at the rate the team can complete it. Working at a more even, predictable pace, means employees are never overloaded. v  Goal 5: Provide Slack to Enable Improvement – Creating slack in the value chain improves responsiveness to urgent requests and bandwidth to enable process improvement and quality improvement. v  Goal 6: Simplify Prioritization – Kanban enables fast reprioritization to accommodate changes in the market.


274

Why Kanban? v Goal 7: Provide a Transparency on the System Design and Operation – Improved visibility builds trust with customers and managers. It also shows the effects of actions or inactions. As a result, collaboration improves. v Goal 8: Enables Emergence of a “High-Maturity” Organization – As improvements are implemented, organizational maturity improves leading to better decision making and improved risk management. Risk, managed appropriately, brings predictable results.


275

Five core principles enable The Kanban Method Principles 1. Visualize the workflow

Description Represent the work items and the workflow on a card wall or electronic board

2. Limit Work-inProgress 3. Measure & Manage Flow 4. Make Policies Explicit

Set agreed upon limits to how many work items are in progress at a time Track work items to see if they are proceeding at a steady, even pace.

5. Use Models to Evaluate Improvement Opportunities

Agree upon and post policies about how work will be handled Adapt the process using ideas from Systems Thinking, W. E. Deming, etc


276

Focusing on smoothing flow v  平準化 – Heijunka : production smoothing, or the reduction of waste from unevenness v  斑 - Mura : unevenness, inconsistency in physical matter or human spiritual condition


277

KANBAN system

How to set up a simple Kanban system for a software development team ? Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

278

1. Define a work process flow

This simple process flow has the steps: 1. Elabora0on & acceptance criteria 2. Development 3. Test 4. Deployment

v  Look at the typical flow for features, stories, or work packages and describe typical process steps Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

3. Test 4. Deployment

279

2. Lay out a visual Kanban board

EXPEDITE

DONE

GOALS WAITING Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

280

3. Prioritized goals

Having goals visible: •promotes focus •helps us prioritize •helps us manage feature scope & requirements.

A good goal describes the outcome we hope to achieve after software ships. Goals help keep focus on the larger outcome Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

281

4. Limits items in queue and work in progress

Limited Items in queue

A good limit is a factor of the number of people in a role that can work on an item in a given process step. Start with number of people * 1.5 Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

282

5. Place stories or features in queue

Product owner manage the waiting queue

v  Mark on the story or feature card the date it entered the queue. This begins our measurement of cycle time. Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

283

Using a strict Kanban approach drops iteration planning from time-boxed iterations in favor of focusing on continuous flow Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

284

Setting up a simple Kanban system starts to focus the team on the cycle-time of delivered work and give a way to detect and begin to resolve bottlenecks


285

DoD Video demo

1. Intro to Kanban in Under 5 Minutes


286

SCALING AND DISTRIBUTED SCRUM


287

Scaling SCRUM: SCRUM of SCRUMS


288

Scaling SCRUM: SCRUM of SCRUMS


289

Scaling of SCRUM v  Many teams, many backlogs, Chief Product owner, Product Owners, SCRUM Masters. v  Synchronize within the team and across teams. v  Correlate team organization to subsystems or modules with minimal crossover. v  Implement development infrastructure to support the number and locations. v  Develop standards, guidelines, training courses, templates, and framework to minimize the coordination required. v  Ensure each team has sufficient resources carefully considering shared resources. v  Develop common culture across the teams. Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

290

Scaling Impact: Roles


291

Scaling Impact: Agile Practices


292

Scaling Consideration: Infrastructure


293

Scaling Consideration: Tools


294

Scaling Consideration: People


295

Scaling Product Backlog


296



297



298

Distributed SCRUM v Rotate members around. v Invest in tools that provide shared environment. v Establish single global instance of project assets, easily accessible by all. v Try virtual team building (wiki/photos) v Establish known hours, with as much overlapping time. v Develop shared team vocabulary.


299

Distributed SCRUM : Delivery Practices


300

Some Overlapping Period

v  Good part : There is some overlapping here v  Whole team can communicate to team on other side v  Chances of mis-communication is less v  Minimize waste in escalation and follow ups. Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

301

No Overlapping Period

v  Biggest Challenge – Share the pain v  Single point of contact, chances of mis-communication is more v  Less communication between team members v  Need to take proactive approach to minimize waste Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

302

Distributed SCRUM: Best Practices v  Easy and continuous access to resources §  Source code repository §  Continuous Integration Server §  Bug Tracking tool §  Wiki §  Project Management Tool v  Setup infrastructure to support team member communication §  Sprint meetings §  Offline discussions §  Knowledge sharing sessions v  Regular people movement for short periods §  Mixing of people to overcome cultural issues, etc., Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

303

Challenges in Distributed and Scaling SCRUM


304

EXTREME PROGRAMMING


305

What is Extreme Programming?

•  An agile development methodology •  Created by Kent Beck in the mid 1990’s •  A set of 12 key practices taken to their “extremes” •  A mindset for developers and customers •  A religion?


The 12 Practices v  The Planning Game v  Small Releases v  Metaphor v  Simple Design v  Testing v  Refactoring v  Pair Programming v  Collective Ownership v  Continuous Integration v  40-Hour Workweek v  On-site Customer v  Coding Standards Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

1 - The Planning Game

•  Planning for the upcoming iteration •  Uses stories provided by the customer •  Technical persons determine schedules, estimates, costs, etc •  A result of collaboration between the customer and the developers


The Planning Game – Advantages

•  Reduction in time wasted on useless features •  Greater customer appreciation of the cost of a feature •  Less guesswork in planning


The Planning Game – Disadvantages •  Customer availability •  Is planning this often necessary?


2- Small Releases

•  Small in terms of functionality •  Less functionality means releases happen more frequently •  Support the planning game


Small Releases – Advantages •  Frequent feedback •  Tracking •  Reduce chance of overall project slippage


Small Releases – Disadvantages

•  Not easy for all projects •  Not needed for all projects •  Versioning issues


3 – Metaphor •  The oral architecture of the system •  A common set of terminology


Metaphor – Advantages

•  Encourages a common set of terms for the system •  Reduction of buzz words and jargon •  A quick and easy way to explain the system


Metaphor – Disadvantages

•  Often the metaphor is the system •  Another opportunity for miscommunication •  The system is often not well understood as a metaphor


4 – Simple Design

•  K.I.S.S. •  Do as little as needed, nothing more


Simple Design – Advantages

•  Time is not wasted adding superfluous functionality •  Easier to understand what is going on •  Refactoring and collective ownership is made possible •  Helps keeps programmers on track


Simple Design – Disadvantages

•  What is “simple?” •  Simple isn’t always best


6 – Testing

•  Unit testing •  Test-first design •  All automated


Testing – Advantages

•  Unit testing promote testing completeness •  Test-first gives developers a goal •  Automation gives a suite of regression test


Testing – Disadvantages

•  Automated unit testing isn’t for everything •  Reliance on unit testing isn’t a good idea •  A test result is only as good as the test itself


6 – Refactoring

•  Changing how the system does something but not what is done •  Improves the quality of the system in some way


Refactoring – Advantages

•  Prompts developers to proactively improve the product as a whole •  Increases developer knowledge of the system


Refactoring – Disadvantages

•  Not everyone is capable of refactoring •  Refactoring may not always be appropriate •  Would upfront design eliminate refactoring?


7 – Pair Programming

•  Two Developers, One monitor, One Keyboard •  One “drives” and the other thinks •  Switch roles as needed


Pair Programming – Advantages

•  Two heads are better than one •  Focus •  Two people are more likely to answer the following questions: –  Is this whole approach going to work? –  What are some test cases that may not work yet? –  Is there a way to simplify this?


Pair Programming – Disadvantages

•  Many tasks really don’t require two programmers •  A hard sell to the customers •  Not for everyone


8 – Collective Ownership

•  The idea that all developers own all of the code •  Enables refactoring


Collective Ownership – Advantages •  Helps mitigate the loss of a team member leaving •  Promotes developers to take responsibility for the system as a whole rather then parts of the system


Collective Ownership - Disadvantages •  Loss of accountability •  Limitation to how much of a large system that an individual can practically “own”


9 – Continuous Integration •  New features and changes are worked into the system immediately •  Code is not worked on without being integrated for more than a day


Continuous Integration - Advantages •  Reduces to lengthy process •  Enables the Small Releases practice


Continuous Integration – Disadvantages •  The one day limit is not always practical •  Reduces the importance of a well-thought-out architecture


10 – 40-Hour Week •  The work week should be limited to 40 hours •  Regular overtime is a symptom of a problem and not a long term solution


40-Hour Week – Advantage •  Most developers lose effectiveness past 40-Hours •  Value is placed on the developers well-being •  Management is forced to find real solutions


40-Hour Week - Disadvantages •  The underlying principle is flawed •  40-Hours is a magic number •  Some may like to work more than 40-Hours


11 – On-Site Customer •  Just like the title says! •  Acts to “steer” the project •  Gives quick and continuous feedback to the development team


On-Site Customer – Advantages •  Can give quick and knowledgeable answers to real development questions •  Makes sure that what is developed is what is needed •  Functionality is prioritized correctly


On-Site Customer – Disadvantages •  Difficult to get an On-Site Customer •  The On-Site customer that is given may not be fully knowledgeable about what the company •  May not have authority to make many decisions •  Loss of work to the customer’s company


12 – Coding Standards •  All code should look the same •  It should not possible to determine who coded what based on the code itself


Coding Standards – Advantages •  Reduces the amount of time developers spend reformatting other peoples’ code •  Reduces the need for internal commenting •  Call for clear, unambiguous code


Coding Standards – Disadvantages •  Degrading the quality of inline documentation


XP – Advantages •  Built-In Quality •  Overall Simplicity •  Programmer Power •  Customer Power •  Synergy Between Practices


XP – Disadvantages •  Informal, little, or no documentation •  Scalability •  Contract Issues •  Misconception on the cost of change •  Tailoring


Application – Advantageous •  Highly uncertain environments •  Internal projects •  Joint ventures


Application – Disadvantageous

•  Large, complex environments •  Safety critical situations •  Well understood requirements •  Distant or unavailable customer


AGILE FOR MANAGER Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

348

What type of manager are you? Result-oriented (nutritional quality) • Is mainly oriented towards achieving results • Defines objectives, sets priorities, and assigns resources • Makes decision based on facts • Is consistent and actionoriented

Enjoyment-oriented (fun to eat) • Is mainly oriented towards people to achieve results • Defines challenges, promotes autonomy, and provides appropriate support • Makes decision based on emotions • Is emotional and relational


349

A few questions to get to know you True

False

1. In order to get best results, it is better to control the activities of all team members. 2. A process that is not well-defined right from the beginning will always produce suboptimal results. 3. In order to cut productivity loss, it is better to isolate team members in cubicles and use e-mails as a means of communication. 4. A team made up of specialists with extensive skills is more efficient than a multidisciplinary team. 5. The best tools and processes are those chosen by the organization and used by all groups. Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

350

A few questions to get to know you True

False

6. It is generally preferable to comprehensively document what we do even if it reduces our speed. 7. Money is the best way to motivate individuals. 8. It is more important to respect a pre-established plan than to adapt to changes. 9. A signed contract is more important than an informal agreement to obtain cooperation between different departments.


351

Results: Are you an Agile manager? No of Your Agility level ‘False’ 9 Congratulations! You got a perfect score! If you already master the theory of Agile approaches and apply it to your daily activities, you could teach this training course. J 5 to 8 You are almost there! You will feel at ease with most concepts presented during this training course. During the next 3 hours, you will have the opportunity to revise fundamentals on which your management approach is based. 1 to 4 You are up to a good start towards a more Agile management style. Concepts and fundamentals of this training course should help you become a more Agile manager. 0

During the next 3 hours, you could ask yourself many questions arising from the course content. Your current paradigm will most probably be harshly tested but you could be really surprised.


352

Traditional approaches pose many challenges What we hear from business people… v  ‘What we get from IT is not what we need, what we asked for.’ v  ‘There should be more control because project teams often do not respect deadlines and budgets.’ v  ‘What is developed has no value to us.’ v  ‘Applications delivered contain too many bugs.’ v  ‘We have to provide the project team with all documentation required before they begin to work.’ v  ‘Deadlines are way too long. The project must end earlier.’ v  We do not understand the language used by IT, and we often are under the impression that they do not understand ours.’ v  ‘The situation would be better if IT would collaborate


353

Traditional approaches pose many challenges What we hear from IT people… v  ‘Users do not know what they want.’ v  ‘With constantly changing needs, we are not able to respect our deadlines.’ v  ‘We are asked to produce more documents than applications.’ v  ‘Usually projects start slowly, but then we work like crazy at the end.’ v  ‘Nobody has fun in the team. People feel like to go elsewhere.’ v  ‘We do not have much room for manoeuvre. Therefore, we must reduce our costs yet again.’ v  ‘How can we increase collaboration between business representatives and us?’ Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

354

Too few projects are successful

v  Projects’ success rate has not improved since 2000. v  What is the situation like in your organization?

Chaos Report–Standish Group, 2009


355

Larger projects are less likely to be successful v  In spite of technological progress, projects are more and more complex. v  Success is uncertain for larger projects. v  To reduce complexity, projects must be broken up into smaller parts. “To eat an elephant, one has to eat it one bite at a time." – an anonymous savannah hunter


356

Solutions do not meet the user’s needs

v  Return on investment is low. v  Nearly 50% of functions are never used. v  Traditional approaches force users to prepare a comprehensive list of their needs at the beginning of the project. v  The longer it takes to develop functions (that will not be used), the longer it takes to reach the market. Jim Johnson @ XP days–Standish Group, 2002


357

Complexity and change will keep increasing v To remain competitive, organizations must: §  Rapidly adapt to changing markets §  Keep room for manoeuvre regarding resource allocation §  Remain flexible while rapidly making decisions §  Develop and maintain their human capital v When complexity increases, centralized management and control systems rapidly reach their limit. v It is impossible to anticipate every thing in advance.


358

Market trends adoption of Agile approaches “By 2012, Agile development methods will be

utilized in 80% of all software development projects.”–Predicts 2010: Agile and Cloud Impact Application Development Directions, Gartner, December 2009 Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

359

Agile approaches are offered in a variety of forms

Agile Project management (Scrum) Development practices Lean approach


360

Agility means that things will be done differently Agility does not mean... v  To no longer do project management v  To be a chaotic organization that no longer respects its IT governance framework v  To no longer produce documents v  To leave the team to itself v  To do things partially v  To change every thing overnight v  That there will no longer be any problems v  It simply means to do things differently

!


361

Using an Agile approach to increase ROI and employee motivation v  To develop solutions meeting the business needs v  To develop solutions on time and within budget v  To increase efficiency and productivity


362

Delivering value with Agile approaches Agile approaches aim at delivering value by capitalizing on individuals and their interactions v  Applying Agility to all phases of a project means: §  To frequently deliver business value at a sustainable pace §  To maintain a high level of quality §  To encourage the team’s empowerment and accountability as well as collaboration between all stakeholders §  To use an iterative and incremental approach §  To remain open to change requests throughout the project


363

To reach our goal, we must implement a structured approach v Management allowing to reach the vision by delivering tangible added value v Use of an iterative and incremental approach within well- established timeboxes v Implementation of performing teams


364

Agile approaches require a change of paradigm


365

PLAN vs BUSINESS VALUE We do not wish to deliver a ‘plan’, we aim at achieving business results v  To avoid planning everything right from the beginning v  To support an incremental investment model v  To ensure that priority is given to the delivery of added value v  To question ourselves about the relevance of additional functions v  To evaluate progress based on results rather than respecting a plan v  To take care of the quality component throughout the project v  To satisfy our clients early with a useful solution v  To refine the understanding of the client’s needs v  To adapt ourselves to change requests Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

366

Increasing ROI Using an iterative and incremental approach to increase ROI


367

What does it mean to the managers? LEADERSHIP • Definition of the objectives and performance management • Management and leadership style ENVIRONMENT • Work environment and organizational culture PROJECT TEAM • Self-sufficiency and accountability • Collaboration and teamwork • Communication and knowledge sharing • Skills and professional development • Continuous improvement e and organizational learning • Processes and tools Tài liệu được biên soạn bởi Ông Nguyễn Thành Châu theo yêu cầu của Ban quản lý các dự án công nghiệp công nghệ thông tin - Bộ TT & TT

368

Transition from a traditional to an Agile approach v  Transfer authority and responsibility to the team so it can do its work adequately v  Avoid interference and micromanagement v  Promote collaboration and teamwork v  Support learning and not systematically penalize failures v  Review best practices in order to adapt them to changing realities v  Make adjustments to the facilities so the environment facilitates the execution of Agile projects v  Adapt the management style to the context of the team


369

Managers will be supported by organizational coaches As members of the expertise centre, organizational coaches: v  Offer training courses to groups of managers (e.g. Agile for managers) v  Participate in steering committees of pilot projects v  Individually support the managers that are related to pilot projects in order to go from a traditional management style to a more Agile one v  Provide individual or group coaching in order to address fears, challenges, and resistances and to provide appropriate support


370

Conclusion v  A transition from a traditional approach to an Agile one is not an IT project, it is rather an organizational change. v  An Agile approach highly impacts project teams but it also impacts managers and their management style. v  When this type of transition is successful, it gives a competitive advantage to the organization. v  Supporting managers is critical to the success of this type of initiative.


371

Q&A

Tài liệu được biênsoạn soạn bởiNguyễn Nguyễn Châu theo yêu cầu của Tài liệu được biên bởi Ông Thành CThành hâu theo yêu cầu của Ban quản các dự công nghiệpnghiệp công nghệcông thông tin - Bộ TTthông & TT tin/Bộ TT & TT Ban quản lý lýcác dựánán công nghệ

372

Agile Scrum Training

Recommend Documents