Project Management CTC-ITC 310

Fall 2018Howard Rosenthal

Notice� This course is based on and includes material from the text:

A User’s Manual To the PMBOK GuideAuthors: Cynthia Stackpole SnyderPublisher: WileyISBN: 978-1-118-43107-8, Copyright 2013

� It also utilizes general information and figures from the PMBOK: A Guide to the Project Management Body of Knowledge (PMBOK 5TH Edition) Publisher: Project Management InstituteISBN: 978-1-935589-67-9, Copyright 2013 and

A Guide to the Project Management Body of Knowledge (PMBOK 6TH Edition) Publisher: Project Management InstituteISBN: 978-1-628251-84-5, Copyright 2017

� The course also includes and intersperses some materials, most often diagrams, provided by Mr. Wysocki’s PowerPoint slides, at the website:www.wiley.com/go/epm7eAnd the bookEffective Project Management - Traditional, Agile, Extreme 7TH EditionAuthors: Robert K. WysockiPublisher: WileyISBN: 978-1-118-72916-8, Copyright 2014

2

Lesson Goals

� Learn about a variety of Agile methods� Scrum� Kanban� Extreme Programming� Feature-driven development� Dynamic systems development� Scaling frameworks

3

Many Different Lean Methods Are Considered Agile� Often people mean different methods when talking about Agile

� Any method that embraces the the Agile Manifesto and Principle may be considered an Agile method

4PMBOK V6 Agile Fig. 2-4

5

What Is A Scrum?� Scrum is the most widely used methodology for Agile development

� Relatively easy to train and implement� Reflects the truly incremental delivery approach used for in-house

improvements� Keeps the customer satisfied and sold� Not appropriate for new large scale projects

� Scrum is a single-team process framework used to manage product development� The framework consists of roles, events, artifacts and rules that uses an

“iterative” Agile delivery approach to deliver working products within timeboxes of one month or less

� Scrum defines "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal”� It challenges assumptions of the "traditional, sequential approach” to product

development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved

� A key principle of Scrum is the dual recognition that customers will change their minds about what they want or need (often called requirements volatility) � There will be unpredictable challenges—for which a predictive or planned

approach is not suited� Scrum adopts an evidence-based empirical approach—accepting that the

problem cannot be fully understood or defined up front� It instead focuses on how to maximize the team's ability to deliver quickly, to

respond to emerging requirements, and to adapt to evolving technologies and changes in market conditions 6

The Scrum Team – An Overview� Product owner who is responsible for maximizing the value of the product� A cross-functional self-organizing development team that can deliver the

product without other outside help – should include the stakeholders� The development team is responsible for delivering potentially shippable

product increments every sprint (the sprint goal).� The team has from three to nine members who carry out all tasks required to

build the product increments (analysis, design, development, testing, technical writing, etc.)

� Although there will be several disciplines represented in the team, its members are referred to generically as developers

� To avoid potential confusion that this only refers to programmers, some organizations call this a delivery team and its members just team members.

� The development team in Scrum is self-organizing, even though there may be interaction with other roles outside the team, such as a project management office (PMO)

� Scrum Master who runs the Scrum and makes sure that nothing impedes success

7

The Scrum Team Product Owner (1)� The Product Owner represents the product's stakeholders and the voice of the

customer; and is accountable for ensuring that the team delivers value to the business. � Defines the product in customer-centric terms (typically user stories), adds

them to the product backlog, and prioritizes them based on importance and dependencies.

� Scrum teams should have one Product Owner and this person/role should not be combined with that of the Scrum Master� The Product Owner should focus on the business side of product development

and spend the majority of their time liaising with stakeholders and should not dictate how the team reaches a technical solution.

� This role is equivalent to the customer representative role in some other Agile frameworks such as extreme programming

� Empathy is a key attribute for a Product Owner to have—the ability to put one's self in another's shoes. � A Product Owner converses with different stakeholders, who have a variety of

backgrounds, job roles, and objectives� To be effective, it is wise for a Product Owner to know the level of detail the

audience needs. � The development team needs thorough feedback and specifications so they can build a

product up to expectation, while an executive sponsor may just need summaries of progress

� Providing more information than necessary may lose stakeholder interest and waste time. A direct means of communication is the most preferred by seasoned Agile Product Owners

8

The Scrum Team Product Owner (2)� Communication is a core responsibility of the Product Owner

� The ability to convey priorities and empathize with team members and stakeholders is vital to steer product development in the right direction

� The Product Owner role bridges the communication gap between the team and its stakeholders, serving as a proxy for stakeholders to the team and as a team representative to the overall stakeholder community

� Communication tasks of the Product Owner to the stakeholders include� Demonstrating the solution to key stakeholders who were not

present at a sprint review� Defining and announcing releases� Communicating team status� Organizing milestone reviews� Educating stakeholders in the development process� Negotiating priorities, scope, funding, and schedule;� Ensuring that the product backlog is visible, transparent, and clear

9

The Scrum Team Scrum Master (1)� The Scrum Master is accountable for removing

impediments to the ability of the team to deliver the product goals and deliverables and is not a traditional team lead or project manager but acts as a buffer between the team and any distracting influences� The Scrum Master ensures that the Scrum framework is

followed� The Scrum Master helps to ensure the team follows the

agreed processes in the Scrum framework, often facilitates key sessions, and encourages the team to improve

� The role has also been referred to as a team facilitator or servant-leader to reinforce these dual perspectives

10

The Scrum Team Scrum Master (2)� The core responsibilities of a Scrum Master include (but are not limited

to)� Ensuring that the Scrum framework is followed� Helping the Product Owner maintain the product backlog in a way that

ensures the needed work is well understood so the team can continually make forward progress

� Helping the team to determine the definition of done for the product, with input from key stakeholders

� Coaching the team, within the Scrum principles, in order to deliver high-quality features for its product

� Promoting self-organization within the team� Helping the Scrum team to avoid or remove impediments to its

progress, whether internal or external to the team� Facilitating team events to ensure regular progress� Educating key stakeholders in the product on Scrum principles� Coaching the development team in self-organization and cross-

functionality� One of the ways the Scrum Master role differs from a project manager is

that the latter may have people management responsibilities and the Scrum Master does not. Scrum does not formally recognize the role of project manager, as traditional command and control tendencies would cause difficulties

11

The Scrum Master Is A Servant-Leader

� As a servant-leader, the Scrum Master is responsible for:� Setting up Scrum as a servant process, not a commanding

process� Guiding the Development team towards self-organization� Leading the team through healthy conflict and debate� Teaching, coaching and mentoring the organization and team

in adopting and using Scrum� Shielding the team from disturbance and external threats� Helping the team make visible, remove and prevent

impediments� Encouraging, supporting and enabling the team to reach their

full potential and abilities� Creating transparency by radiating information via e.g. the

product and sprint backlog, daily Scrum, reviews and a visible workspace

� Ensuring a collaborative culture exists within the team

12

The Scrum Framework

13

The Scrum Process Is Built Around Daily Standups and Rapid Delivery Of New Capabilities

14

What Is A Sprint?� A sprint (or iteration) is the basic unit of development in Scrum

� The sprint is a timeboxed effort; that is, it is restricted to a specific duration

� The duration is fixed in advance for each sprint and is normally between one week and one month, with two weeks being the most common

� Each sprint starts with a sprint planning event that aims to define a sprint backlog, identify the work for the sprint, and make an estimated forecast for the sprint goal

� Each sprint ends with a sprint review and sprint retrospectivethat reviews progress to show to stakeholders and identify lessons and improvements for the next sprints.

� Scrum emphasizes a working product at the end of the sprint that is really done� In the case of software, this likely includes that the software has

been fully integrated, tested and documented, and is potentially shippable

15

Sprint Planning� At the beginning of each sprint, the Scrum team holds a sprint planning event

to:� Mutually discuss and agree on the scope of work that is intended to be done

during that sprint� Select product backlog items that can be completed in one sprint� Prepare a sprint backlog that includes the work needed to complete the selected

product backlog items� The recommended duration for planning is four hours for a two-week sprint

(pro-rated for other sprint durations)� During the first half, the whole Scrum team (development team, Scrum Master,

and Product Owner) selects the product backlog items they believe could be completed in that sprint� Looks at the scope of the work, and availability of human and physical resources

� During the second half, the development team identifies the detailed work (tasks) required to complete those product backlog items; resulting in a confirmed sprint backlog� As the detailed work is elaborated, some product backlog items may be split or put

back into the product backlog if the team no longer believes they can complete the required work in a single sprint

� Once the development team has prepared their sprint backlog, they forecast (usually by voting) which tasks will be delivered within the sprint

16

What Is The Daily Scrum (1)� Each day during a sprint, the team holds a daily Scrum (or

stand-up) with specific guidelines:� All members of the development team come prepared. � The daily Scrum:

� Starts precisely on time even if some development team members are missing

� Should happen at the same time and place every day� Is limited (timeboxed) to fifteen minutes

� Anyone is welcome, though only development team members should contribute

� During the daily Scrum, each team member typically answers three questions:� What did I complete yesterday that contributed to the team meeting

our sprint goal?� What do I plan to complete today to contribute to the team meeting

our sprint goal?� Do I see any impediment that could prevent me or the team from

meeting our sprint goal?

17

What Is The Daily Scrum (2)� Any impediment (e.g., stumbling block, risk, issue,

delayed dependency, assumption proved unfounded) identified in the daily Scrum should be:� Captured by the Scrum Master and displayed on the

team's Scrum board or on a shared risk board� Have an agreed person designated to working toward a

resolution (outside of the daily Scrum)� No detailed discussions should happen during the

daily Scrum

18

Sprint Review And Sprint Retrospective� At the end of a sprint, the team holds two events: the sprint review and

the sprint retrospective.� At the sprint review, the team:

� Reviews the work that was completed and the planned work that was not completed

� Presents the completed work to the stakeholders (a.k.a. the demo)� The team and the stakeholders collaborate on what to work on next� Guidelines for sprint reviews:

� Incomplete work cannot be demonstrated� The recommended duration is two hours for a two-week sprint

� At the sprint retrospective, the team:� Reflects on the past sprint� Identifies and agrees on continuous process improvement actions

� These are very important to companies wanting to maintain the highest quality ratings

� Guidelines for sprint retrospectives:� Two main questions are asked in the sprint retrospective: What went well during

the sprint? What could be improved in the next sprint?� The recommended duration is one-and-a-half hours for a two-week sprint� This event is facilitated by the Scrum Master

19

20

Much of the information in this section comes from: https://www.atlassian.com/Agile/kanbanhttps://kanbantool.com/kanban-board-examples

The Kanban Method

� The Kanban method was originally used in inventory control systems� Introduced the concept of just-in-time (JIT)� Promoted by Toyota in Japan as a way to reduce excess

inventory and reduce costs – remember when you carry inventory that is sunk money

� Kanban today is built around the concept of visualization of the flow of work through cards� Allows for a continuous flow of work and deliveries, without

specific timeboxes� Still limits work in progress� Is a bit less prescriptive than a Scrum

21

Key Kanban Features (1)� Flexibility

� Teams are not bound by timeboxes and will work on the highest priority items in the backlog first

� The Product Owner is free to reprioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team

� As long as the Product Owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business

� Savvy Product Owners always engage the development team when considering changes to the backlog

22

Key Kanban Features (2)� Shortened cycle times

� Cycle time is the amount of time it takes for a unit of

work to travel through the team’s workflow–from the

moment work starts to the moment it ships and is a key

Kanban metric

� By optimizing cycle time, the team can confidently

forecast the delivery of future work

� Overlapping skill sets lead to smaller cycle times

� When only one person holds a skill set, that person becomes a

bottleneck in the workflow

� Teams employ basic best practices like code review and

mentoring help to spread knowledge

� Shared skills mean that team members can take on

heterogeneous work, which further optimizes cycle time

� It also means that if there is a backup of work, the entire team

can swarm on it to get the process flowing smoothly again

� For instance, testing isn't only done by QA engineers.

Developers pitch in, too 23

Key Kanban Features (3)� Focus on continuous delivery

� Continuous delivery (CD) is the practice of releasing work to customers frequently–even daily or hourly. � Kanban and CD beautifully complement each other because both techniques focus on

the just-in-time (and one-at-a-time) delivery of value.� Teams are focused on flowing work through the system to completion and not

beginning new work until work in progress is completed� Increased productivity and quality

� Productivity and quality are increased by limiting work in progress and multitasking, which kills efficiency

� The more work items in flight at any given time, the more context switching, which hinders their path to completion

� A key tenet of Kanban is to limit the amount of work in progress (WIP)� Work-in-progress limits highlight bottlenecks and backups in the team's process due to

lack of focus, people, or skill sets.� For example, a typical software team might have four workflow states: To Do, In

Progress, Code Review, and Done. � They could choose to set a WIP limit of 2 for the code review state which may seem like

a low limit, but there's good reason for it: � Developers often prefer to write new code, rather than spend time reviewing someone

else's work� A low limit encourages the team to pay special attention to issues in the review state, and

to review others work

24

Key Kanban Features (4)� Increased efficiency with fewer bottlenecks

� Checking each task to make sure it is adding value� before raising their own code reviews. This ultimately

reduces the overall cycle time� Team member focus

� Limited work in progress allows for greater focus on work in progress

� Reduction of waste� Transparency through the boards makes it easier to

remove wasteful activities

25

Defining Principles and Properties Of Kanban

26

PMBOK V6 Agile Fig. A3-3

Implementing Kanban� The work of all Kanban teams revolves around a Kanban board, a

tool used to visualize work and optimize the flow of the work among the team� While physical boards are popular among some teams, virtual

boards are a crucial feature in any Agile software development tool for their traceability, easier collaboration, and accessibility from multiple locations.

� Regardless of whether a team's board is physical or digital, their function is to ensure the team's work is visualized, their workflow is standardized, and all blockers and dependencies are immediately identified and resolved.

� A basic Kanban board has a three-step workflow� To Do� In Progress� Done

� However, depending on a team's size, structure, and objectives, the workflow can be mapped to meet the unique process of any particular team.

27

The Basic Kanban Board

� A basic board consists of in queue tasks, work in progress and completed work

� Good for new teams and small projects

28

The Time Driven Kanban Board� The time driven Kanban board is a schedule based take on a basic workflow� Suitable for teams, whose work is organized by certain, planned events in time� Perfect for people and organizations, that have an extensive backlog and slice it

into a soon - very soon - now manner, without more specific dates

29

The Event Driven Kanban Board� In the event driven Kanban board, the columns are created with

accordance to certain events, that will determine further development of tasks

� For example - after an external event (such as an approval) occurs - a user decides to move a task to another column, to visualize that this task is ready to be worked on next

30

The Product Development Kanban Board� The product driven Kanban board can be used as a base for product

development process� It encompasses a whole range of necessary activities associated with a product

development process � Gathering, assessing and analyzing information� Development stages� Quality assurance steps� Multi-leveled verification.

31

The Sales Pipeline Kanban Board� The sales pipeline Kanban board is a base for describing and managing a sales

pipeline. � Provides great visibility if you wish to keep track of who you need to contact

and with regards to what exactly� This is a completely different use of the board

32

Comparing Scrum and KanbanFactor Scrum Kanban

Cadence Regular, fixed length Continuous flowRelease Methodology

At the end of each sprint, after approval by Product Owner

Continuous delivery

Roles Product owner, Scrum Master, development team

No fixed roles aside from Product Owner

Key Metrics Velocity Cycle timeChange Philosophy

Don’t change forecast during a sprint

Change can happen at any time

33

� Scrumban is an Agile approach originally developed as a way to transition from Scrum to Kanban� The work is still organized in small sprints� Kanban boards are used to visualize the work and enforce work in progress limits� Daily standups� When work in progress is below planned level a trigger is activated to alert the team� Team roles are more flexible

34

What is Extreme Programming

� Extreme Programming� A software development philosophy based on frequent

cycles� Used when the goal is not clear and the solution may or

may not be clear – this sometimes happens when basic research, or even technology is invented before understanding how it will be used

� 10% of all projects� Example – The internet – was created with hardly any

idea of how it would ultimately be used� Example – Cure the common cold

35

Key Extreme Programming Practices

36

PMBOK V6 Agile Table A3-2

Features Of Extreme Programming (1)� Incremental planning

� Requirements are recorded on Story Cards and the Stories to be included in a release are determined by the time available and their relative priority

� The developers break these stories into development "Tasks”� Small Releases

� The minimal useful set of functionality that provides business value is developed first. Releases of the system are frequent and incrementally add functionality to the first release

� Simple Design� Enough design is carried out to meet the current requirements and no more

� Test first development� An automated unit test framework is used to write tests for a new piece of

functionality before functionality itself is implemented� Refactoring

� Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior

� Refactoring improves nonfunctional attributes of the software� All developers are expected to refactor the code continuously as soon as possible

code improvements are found. This keeps the code simple and maintainable

37

Features Of Extreme Programming (2)� Pair Programming

� Developers work in pairs, checking each other’s work and providing support to do a good job

� Collective Ownership� The pairs of developers work on all areas of the system, so that no islands of

expertise develop and all the developers own all the code. Anyone can change anything

� Continuous Integration� As soon as work on a task is complete, it is integrated into the whole system. � After any such integration, all the unit tests in the system must pass

� Sustainable pace� Large amounts of over-time are not considered acceptable as the net effect is

often to reduce code quality and medium-term productivity. � On-site Customer

� A representative of the end-user of the system (the Customer) should be available full time for the use of the XP team.

� In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation

38

Advantages And Disadvantages Of The Extreme Model (1) � Advantages

� Robustness� Leverages the power of simplicity. � The design resembles a jigsaw puzzle with developers working on many small pieces or iterations

with the combination of such iterations giving the end product.

� Creates working software faster with very few defects.� Regular testing at the development stage ensures detection of all bugs

� The use of customer approved validation tests determine the successful completion of a coding block, ensuring that only what the customer wants and nothing more is implemented.

� Allows for cost estimates-based software features instead of developer activity. � Customers make intelligent decisions on what needs inclusion and what needs exclusion

depending on the budget. By selecting the important requirement first, the customer obtains maximum value with the least amount spent

� Resilience� Requirements keep changing either because of emergence of new business opportunities or simply

because the initial requirement-gathering phase was incomplete

� Extreme programming accommodates such changed requirements by getting user stories at the start of iterations, and through feedback during the course of iterations.

� Cost Savings� Trims unproductive activities to reduce costs

� Developers to focus on coding instead of wasting time on needless paperwork and meetings

� The cost of making changes increases as the software advances in its life cycle, with the cost of making changes after delivery anywhere between 5 and 100 times more than the costs of making a change at the design stage.

� Conventional programming methods make changes based on customer feedback at the end of the product lifecycle, whereas Extreme Programming allows changes at the development stage.

� Lesser Risks� Conventional programming depends a lot on individual ‘superstars’ or critical members in the team

while extreme programming, spreads the risk and reduces the dependence on any one architect, project manager, or individual coder. 39

Advantages And Disadvantages Of The Extreme Model (2) � Disadvantages

� Programming is hard to do. � You may have difficulty getting developers to accept the Extreme Model, and it takes a

lot of discipline to follow the model consistently. � Your customers may not like the idea of so much involvement. � Management may also find problems with so many dynamic changes during the project

life cycle.� XP team does not believe the idea of fixed price, fixed scope – rather it is

incremental and is based on the concept of continuous change.� Other processes are more likely to encourage the creation of detailed planning from the

beginning.� XP is code centric rather than design centric development.

� The lack of a design concept may not be serious for small programs, but it can be problematic when programs are larger than a few thousand lines of code or when many people are associated with the project.

� XP does not measure or plan the quality aspect of development. � Managers of big projects believe that quality planning helps properly trained teams

produce high-quality products.� It is hard to design today’s software products, which are very large and complex

by nature, using XP’s incremental approach. � Refactoring may not be that important all the time and can be a waste of time

rather than being productive in positive sense.� Some developers fall in love with perfecting their own software

� Traditional programming enables testers to find defects more easily because the test cases are well documented and tied back to the requirements.

40

41

Feature Driven Development Overview� Feature-Driven Development (FDD), invented by Jeff De Luca, is one

of the Agile processes not talked or written about very much as it is most often applicable on larger programs� Scrum and Extreme Programming approaches use a small team of

skilled and disciplined developers� It remains a significant challenge to scale these approaches to larger

projects and larger teams� FDD was designed from the ground up to work for a larger team that

present different challenges� A small team of disciplined and highly skilled developers by definition

is likely to succeed regardless of which Agile method they use� In contrast, it is unrealistic to expect that everyone in a larger team is

equally skilled and disciplined� There are six primary roles in FDD

� Project manager� Chief architect� Development manager� Chief programmer� Class Owner and/or� Domain expert

42

Feature Driven Development Overview (2)� FDD starts with the creation of a domain object model

in collaboration with Domain Experts� Using information from the modeling activity, and

from any other requirements activities that have taken place, the developers go onto create a features list

� Then a rough plan is drawn up and responsibilities assigned

� Small groups of features through a design and build iteration that lasts no longer than two weeks and is often much shorter, sometimes only a matter of hours

� The first three of these processes are often referred to as iteration-zero processes

43

Feature Driven Development Project Life Cycle

44

PMBOK V6 Agile Fig. A3-4

FDD Process #1 – Develop an Overall Model� Typically large, upfront analysis and design phases is associated with traditional project

management.� In FDD, however, the building of an object model is not a long, drawn-out, activity

performed by an elite few using expensive CASE tools� The modelers do not format the resulting model into a large document and throw it over

the wall for developers to implement.� Building an initial object model in FDD is an intense, highly iterative, collaborative and

generally enjoyable activity involving ‘domain and development members under the guidance of an experienced object modeler in the role of Chief Architect� The idea is for both domain and development members of the team to gain a good, shared

understanding of the problem domain� It is important that everyone understands the key problem domain concepts,

relationships, and interactions. In doing so, the team as a whole learn to communicate with each other and start to establish a shared vocabulary,

� The object model developed at this point concentrates on breadth rather than depth� Depth is added iteratively through the lifetime of the project. The model is, therefore, a living

artifact� Throughout the project, the model becomes the primary vehicle around which the team discusses,

challenges, and clarifies requirements.� The result of the process is the object model which includes

� Class diagrams focusing on model shape.� That is, what classes are in the domain, how are they connected to one another and under what

constraints� Methods and attributes identified are placed in the classes� Sequence Diagram(s), if any� Model notes to capture why a particular model shape was chosen and/or what alternatives

were considered45

FDD Process # 2 – Build a Features List (1)� With the first activity being to build an object model, some

may conclude FDD is a model-driven process. It is not� While the model is central to the process, an FDD project is

like a Scrum or eXtreme Programming project in being requirement-driven

� Small, client-valued requirements referred to as features drive the project while the model merely helps guide

� Formally, FDD defines a feature as a small, client-valued function expressed in the form: <action> <result> <object> � Small, means a feature typically takes 1-3 days to implement,

occasionally 5 days but never 10 or more days to implement.� Example: calculate the total of a sale

� Unlike Scrum and eXtreme Programming that use a flat list of backlog items or user stories, FDD organizes its features into a three level hierarchy that is called the feature list� Larger projects/teams need this extra organization to help

manage the larger numbers of items that are typically found on an FDD features list than on a Scrum-style backlog.

46

FDD Process # 2 – Build a Features List (2)� To define the upper levels in the feature list hierarchy, the team derives

a set of domain subject areas from the high-level breakdown of the problem domain that the domain experts naturally used during the object modeling session� Then within these areas, the team identifies the business activities of

that area and places individual features within one of those activities� Therefore, in the features list we have areas containing activities that in

turn contain features.� In practice, building the features list is a formalization of the features

already discussed during the development of the object model� For this reason, lead developers or Chief Programmers can perform this

task using the knowledge they gained during the modeling � Other members of the modeling team including the domain experts

provide input to, and verification of the list as necessary.� The result of the process is the Features List which includes

� A list of subject areas� For each subject area, a list of the business activities within that subject

area � For each business activity step, the feature to satisfy the step

47

FDD Process # 3 – Plan By Feature (1)� The third and last of the iteration-zero-style FDD processes involves constructing an

initial schedule and assigning initial responsibilities. � The planning team initially sequence the feature sets representing activities by relative

business value� Feature sets are also assigned to a Chief Programmer who will be responsible for their

development� At the end of this process, each Chief Programmer effectively has a subset of the features

list assigned to them� For a Chief Programmer this is their backlog or ‘virtual inbox’ of features to implement.

� The planning team may adjust the overall sequence of feature sets to take into account technical risk and dependencies where appropriate� In larger development efforts, the dependencies that have an impact on the sequence may

be purely technical in nature but are just as likely to revolve around which feature sets are assigned to which Chief Programmers, and which classes are owned by which developers

� FDD also departs from traditional Agile thinking, in that it chooses not to adopt collective ownership of source code� Instead, it assigns individual developers to be responsible for particular classes during this

planning process� The advantages of individual class ownership include:

� There is someone responsible for the conceptual integrity of that class. As enhancements are made, the class owner ensures that the purpose and design of the class is not compromised

� There is an expert available to explain how a specific class works. This is especially important for complex or business-critical classes

� The class owner typically implements a required change faster than another developer that is not as familiar with the class

� The class owner has something of his or her own that he or she can take personal pride in

48

FDD Process # 3 – Plan By Feature (2)� There are issues with code ownership

� We do not want delivery of features held up because one developer is waiting a long time for other developers to make changes

� However, instead of allowing any pair of developers to edit any source code files whenever they think they need to, FDD address the problem differently� First, in FDD class ownership implies responsibility not exclusivity and a class owner

may allow another developer to make a change to a class they own. � The big difference is that the class owner is aware of, and approves of, the change and is

responsible for checking that the change is made correctly� The other strategy that FDD uses to enable effective feature-by-feature development

with individual class ownership is the idea of dynamically formed feature teams � As with other Agile planning approaches, in FDD the planning team reviews

and modifies the assignment of feature sets to Chief Programmers and classes to developers as often as necessary throughout the project

� The result of the process is the Development Plan which includes� Business activities with completion dates (month and year)� Chief programmers assigned to business activities� Subject areas with completion dates (month and year) derived from the last

completion date of their respective business activities� The list of classes and the developers that own them (the class owner list)

49

FDD Process # 4– Design By Feature� Design By Feature

� Programmers produce a design package for each feature with a chief programmer selecting a group of features that should be developed within a two-week period

� The chief programmer also establishes detailed diagrams for each feature while refining the model

� When this is complete, prologues are produced and a design inspection is carried out

� The result of the process is a successfully inspected Design Package. The design package comprises� A covering memo, or paper, that integrates and describes the design

package such that it stands on its own for reviewers� The referenced requirements (if any) in the form of documents and all

related confirmation memos and supporting documentation.� The Sequence diagram(s)� Design alternatives (if any)� The object model with new/updated classes, methods and attributes� The generated output for the class and method prologues created or

modified by this design� Calendar/To-Do task-list entries for action items on affected classes for

each team member

50

FDD Process #5 –Build By Feature� Build By Feature

� Once design inspections are complete, designers plan an activity for each feature and develop the code for their respective classes

� When the inspection is complete and a unit test carried out, the feature is then pushed to the main build

� The result of the process is� Class(es) and/or method(s) that have been successfully

code inspected� Class(es) that have been promoted to the build� The completion of a client-valued function (feature)

51

52

Dynamic Systems Development Method� Dynamic systems development method (DSDM) is an Agile project delivery

framework, initially used as a software development method� First released in 1994, DSDM originally sought to provide some discipline to the

rapid application development (RAD) method� The DSDM Agile Project Framework was revised and became a generic

approach to project management and solution delivery rather than being focused specifically on software development and code creation and could be used for non-IT projects

� The DSDM Agile Project Framework covers a wide range of activities across the whole project lifecycle and includes strong foundations and governance, which set it apart from some other Agile methods.

� The DSDM Agile Project Framework is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement.

� Unlike traditional approaches DSDM fixes cost, quality and time at the outset � In DSDM there are eight principles that directs the team in the attitude they

must take and the mindset they must adopt in order to deliver consistently.� Focus on the business need� Deliver on time� Collaborate� Never compromise quality� Build incrementally from firm foundations� Develop iteratively� Communicate continuously and clearly� Demonstrate control

53

DSDM Fixes Cost, Time and Quality On The Iron Triangle

54

PMBOK V6 Agile Fig. A3-5

The functionality is constrained by the other factors

Scaling ScrumObtaining The Advantages Of Agile In Large Scale Environments

55

Information in this section comes from the following additional sources:https://www.scaledAgileframework.com/what-is-safe/

Scrum Of Scrums� The Scrum of Scrums is a technique to scale Scrum up to large groups

(over a dozen people), consisting of dividing the groups into Agile teams of 5-10� Each daily Scrum within a sub-team ends by designating one member

as "ambassador" to participate in a daily meeting with ambassadors from other teams, called the Scrum of Scrums

� Depending on the context, ambassadors may be technical contributors, or each team's Scrum Master, or even managers of each team

� The Scrum of Scrums proceeds otherwise as a normal daily meeting, with ambassadors reporting completions, next steps and impediments on behalf of the teams they represent� Resolution of impediments is expected to focus on the challenges of

coordination between the teams� Solutions may entail agreeing to interfaces between teams, negotiating

responsibility boundaries, etc.� The Scrum of Scrum will track these items via a backlog of its own,

where each item contributes to improving between-team coordination

56

Scrums Can Be Organized In Hierarchies

57

Large Scale Scrum (LeSS) � LeSS is Scrum applied to many teams working together on one product

� Large-Scale Scrum (LeSS) isn’t new and improved Scrum nor is it Scrum at the bottom for each team, and something different layered on top

� Rather, it’s about figuring out how to apply the principles, purpose, elements, and elegance of Scrum in a large-scale context, as simply as possible

� Like Scrum and other truly Agile frameworks, LeSS is “barely sufficient methodology” for high-impact reasons

� LeSS is a scaled up version of one-team Scrum, and it maintains many of the practices and ideas of one-team Scrum. In LeSS, you will find:� A single Product Backlog (because it’s for a product, not a team),� One Definition of Done for all teams,� One Potentially Shippable Product Increment at the end of each Sprint� One Product Owner,� Many complete, cross-functional teams (with no single-specialist

teams),� one Sprint.� In LeSS all Teams are in a common Sprint to deliver a common

shippable product, every Sprint58

What Is Different In LeSS (1)

� Sprint Planning Part 1:� In addition to the one Product Owner, it includes people from all

teams. Let team members self-manage to decide their division of Product Backlog Items. Team members also discuss opportunities to find shared work and cooperate, especially for related items.

� Sprint Planning Part 2� This is held independently (and usually in parallel) by each Team,

though sometimes for simple coordination and learning two or more Teams may hold it in the same room (in different areas).

� Daily Scrum:� This is also held independently by each Team, though a member of

Team A may observe Team B’s Daily Scrum, to increase information sharing.

� Coordination between parallel Scrums� May require separate daily meetings with representatives from each

Scrum

59

What Is Different In LeSS (2)� Overall Product Backlog Refinement (PBR )

� There may be an optional and short overall Product Backlog Refinement (PBR) meeting that includes the one Product Owner and people from all teams

� The key purpose is to decide which teams are likely to implement which items and therefore select those items for later in-depth single-team PBR. It is also a chance to increase alignment with the Product Owner and all teams.

� Product Backlog Refinement� The only requirement in LeSS is single-team PBR, the same as in one-team

Scrum� A common and useful variation is multi-team PBR, where two or more Teams

are in the same room together, to increase learning and coordination.� Sprint Review

� In addition to the one Product Owner, it includes people from all teams, and relevant customers/users and other stakeholders

� For the phase of inspecting the product increment and new items, consider a “bazaar” or “science fair” style: a large room with multiple areas, each staffed by team members, where the items developed by teams are shown and discussed.

� Overall Retrospective� This is a new meeting not found in one-team Scrum, and its purpose is to

explore improving the overall system, rather than focusing on one Team� The maximum duration is 45 minutes per week of Sprint. It includes the

Product Owner, Scrum Masters, and rotating representatives from each Team.

60

The LeSS Framework

61

The Scaled Agile Framework (SAFe)Obtaining The Advantages Of Agile In Large Scale Environments

62

Information in this section comes from the following additional sources:https://www.scaledAgileframework.com/what-is-safe/

What Is The Scaled Agile Framework (SAFe) (1)

� The Scaled Agile Framework (SAFe®) helps businesses address the significant challenges of developing and delivering enterprise-class software and systems in the shortest sustainable lead time� It is a freely revealed, online knowledge base of proven success

patterns, for people building the world’s most important software and systems

� SAFe synchronizes alignment, collaboration, and delivery for multiple Agile teams� Scalable and configurable, SAFe allows each organization to

adapt it to its own business needs� It supports smaller-scale solutions employing 50 – 125

practitioners, as well as complex systems that require thousands of people

� An extensive body of knowledge, SAFe describes the roles, responsibilities, artifacts, and activities necessary to implement Lean-Agile development

63Copyright © Scaled Agile, Inc.

What Is The Scaled Agile Framework (SAFe) (2)� SAFe focuses on detailing practices, roles and activities

at the portfolio, program and team levels with an emphasis on value streams that focus on providing continuous value to the customer

� SAFe has evolved on real-world projects as a proven approach for developing complex systems and software in a Lean-Agile manner and draws from three primary bodies of knowledge: � Agile development� Systems thinking� Lean product development

64Copyright © Scaled Agile, Inc.

What Is The Scaled Agile Framework (SAFe) (3)� SAFe was developed to help enterprises answer the following types of

questions:� How do we align the company toward its business and technical goals?� How do we make better decisions to improve our economic outcomes? � How do we deliver new value on a predictable schedule so that the rest of the

business can plan and execute? � How do we improve the quality of our solutions and delight our customers? � How do we scale Agile practices from the team to the program and business

unit, and across the enterprise, to deliver better results? � How do we organize people around value so that our programs deliver it

effectively and avoid the delays and bureaucracy inherent in a traditional, hierarchical structure?

� How do we manage and minimize dependencies between teams, programs, and Value Streams?

� How do we create an environment that fosters collaboration, innovation, and relentless improvement?

� How do we unlock the intrinsic motivation of the people who do this work? � How can we change our culture so that it tolerates failure and rewards risk-

taking and continuous learning? � How can we help our teams improve without getting in the way? � How do we know what our Agile teams are doing and measure how well they’re

performing?

65Copyright © Scaled Agile, Inc.

What Is The Scaled Agile Framework (SAFe) (4)� SAFe focuses on the following principles

� Always look at the economic view� Uses systems wide thinking

� Systems wide thinking is a holistic approach to analysis that focuses on the way that a system's constituent parts interrelate and how systems work over time and within the context of larger systems

� The systems wide thinking approach contrasts with traditional analysis, which studies systems by breaking them down into their separate elements.

� Systems wide thinking can be used in any area of research and has been applied to the study of medical, environmental, political, economic, human resources, and educational systems, among many others

� System wide thinking� Assumes variability and changes, so preserve options� Builds incrementally using an Agile methodology� Bases milestones on objective evaluation of previously developed

systems� Visualizes and limit work in progress� Unlocks and motivate workers (we discuss this in a later lesson)� Decentralizes decision making

66Copyright © Scaled Agile, Inc.

SAFe Supports Multiple Development Environments (1)� Essential SAFe

� Essential is the simplest starting point for implementation� It’s the basic building block for all other SAFe configurations and

describes the most critical elements needed to realize the majority of the Framework’s benefits.

� Together, the Team and Program Levels form an organizational structure called the Agile Release Train (ART), where Agile teams, key stakeholders, and other resources are dedicated to an important, ongoing solution mission

� Large Solution SAFe� The Large Solution SAFe configuration is for developing the largest and

most complex solutions that typically require multiple Agile release trains and Suppliers, but do not require portfolio-level considerations

� This is common for industries like aerospace and defense, automotive, and government, where the large solution—not portfolio governance—is the primary concern

� The Solution Train organizational construct of the Large Solution Level helps enterprises that face the biggest challenge for building large-scale, multidisciplinary software, hardware, and complex IT systems

� Building these solutions requires additional roles, artifacts, events, and coordination

� Enterprises that build largely independent systems or those that can be built with a few hundred practitioners may not need this configuration.

67Copyright © Scaled Agile, Inc.

SAFe Supports Multiple Development Environments (2)

� Portfolio SAFe� The Portfolio SAFe configuration helps align portfolio

execution to the enterprise strategy, by organizing Agile development around the flow of value, through one or more value streams

� It provides business agility through principles and practices for portfolio strategy and investment funding, Agile portfolio operations, and Lean governance

68Copyright © Scaled Agile, Inc.

Essential SAFe®

69Copyright © Scaled Agile, Inc.

Full SAFe®

70Copyright © Scaled Agile, Inc.