ASM: Agile way of Thinking

Persona Example of John

John software developer living in Manhattan, has apartment in Soho, and loves walking chihuahua in neighborhood and chatting with people, uses Apple Air for programing, often spends day working in Urban Grind coffee shop, loves frsh ground capps, passionate about Agile techniques, active member of local Agile leadership network

Project Related Factors

Project Related Factors: -Agile is acceptable for complex new products where requs are likely to change (B/c of inherent exploratory nature of Agile) -Amount of user facing work in project (the fundamental advantage of incremental project development is the ability to get user feedback) -Costs of iteration EXAMPLE: if working on migration of large system to new platform, theres not much user interface, but costs associated with iteration, not easy to showcase a working system every few weeks, adds overhead "The Cost of Iterating", team needs to reduce cost of iterating before getting value out of Agile -Predictability of Workflow: EXAMPLE: if workflow is work of a maintenance stream where requests may come up ad hawk at any point in time, it may be hard to fit into any lifecycle sprints and iterations, such that LEAN or KANBAN methods may be better used

Planning Large Projects

(Must be planned ahead and insert feeder buffers) -A common basis for estimates should be established, rationalize units, and benchmark stories for common understanding (difficulty if multiple team estimate in ideal time and others in story points) -Hold a release kick-off meeting (difficult for teams to visualize dependencies, different permutations, and combinations that may be encountered in reality, this brings face-2-face discussion) -Each team must prepare a look-ahead planning and identify and plan for bi-directional dependencies (while planning Sprint 1, team needs to also plan ahead and look what needs to be done in Sprints 2 or 3) -At critical dependency junctures, feeder buffers for critical dependencies to protect schedule (EX: if Team A is finishing up feature on March 31, and Team B plans to start building on top of it the next day, build in 2-3 day buffer) -In Scaled Agile, have Shared Team Members or establish Feature Teams and form Integration Teams (organize teams around features not modules, form and disband w/each feature, integration team makes sure all of teams' working parallel integrate work frequently) -Integration teams work with automated tools (end-to-end use cases, and automated use tests)

Testing Pyramid

(base) Unit Tests: 80%-90% of all tests should be Unit Tests and should be nearly 100% automated [once every method and function has past the unit level testing, there is very little chance it will break in acceptance or GUI], they are fast and much more reliable (middle) Acceptance Tests: 5%-15% of the tests should be acceptance tests (top) GUI Tests: User interface test should be less than 5% [automated tests relying on the user interface are slow brittle and very high maintenance,

Balanced Scorecard for Scrum Teams

**Designed by Dr Robert Kaplan & David Norton A performance measurement framework that adds strategic non-financial performance measures to traditional financial metrics. It gives managers and executives a more balanced view of organizational performance Categorize outcomes along- 1.)Financial 2.)Customer 3.)Process 4.)Innovation Mike Cohn suggests these 4 categories to benefit from Scorecard concept: 1.)Operational Excellence 2.)User Orientation 3.)Business Value 4.)Future Orientation

Sample List of Items given in Definition of Done Criteira

**Each team's "Definition of DONE" varies based on maturity and specific circumstances of team -The story is fully implemented or code completed as described -Automated unit tests have been developed w/at least 80% code coverage -Automated unit tests and acceptance teats in the story are passing -High priority test cases have been automated and added to the regression suite

Self-Organization

**Plays critical role in the success of Team's Scrum adoption, self-org doesnt mean carte blanche, subtle ways management can/should influence team, nudge towards solution 1.) Container Idea ... traffic rules and signs... EXAMPLE: if team lacks a certain skill set, assist the team in identifying a member who will help in developing skill sets OR dealing with troublesome member assist in managing situation 2.) Amplify or Dampen Differences: Some teams too homogeneous think in conformity, and teams who think in all sorts of different directions w/out coming to consensus EXAMPLE: management should step in to ask ?'s that creates differences or step in and assist in closing gaps in thinking and help team reach consensus 3.) Manage and Facilitate Exchanges: could be within the members of organization outside the team... EXAMPLE: talking with UX designers, architecture forum, Agile expert group, may need to be facilitated in order to steer team in right direction

Integrating Agile and ITIL Roles

**Service Owner - Product Owner (when a product is deployed it transitions into the delivery of a service into the business, and end-to-end understanding of the lifecycle enables clearer visualization of customer value) **Product Owner - Change Management Advisory Board (CAB) (PO must either be apart of or Lead the CAB, b/c PO is responsible for prioritizing user stories and releases) **Continual Service Improvement (CSI) MAnager - SCRUM Master (To enable continuous learning across the product and service life cycles) (CSIM works to ensure the services linked to the product are also improving) the 2 collaborate to fix issues within value chain

Characteristics of XP Teams

- Self-organizing: teams empower to themselves how they are going to execute the work of the project w/out using up-down management in control) - Cross functional: having generalized specialists as team members (specialize in one area but have enough knowledge to participate in other roles part of a XP team) -Compromise and collaborate

DSDM (Dynamic Systems Development Method)

- created in 1990's -Is a comprehensive method documented in the form of an e-book that is available freely on URL: www.dsdm.org -alt rev version published in 2007 -links well with Project Management techniques like Prince 2 (popular in UK) -good at time boxing and prioritization

A teams average velocity is 10, with a max of 12 and min of 8. The release backlog is sized at 72. How many Sprints should the team commit.

-8 sprints -Considering the # of Sprints needed is 72/10=7.2 -Round to higher whole #

Scrum Master: MUST NOT

-A "line" manager of team -A task master -A technical or design authority -A decision maker -Not do anything to rob team of empowerment or rob team of self organization

Release Backlog

-A subset of the product backlog -Releases support the product roadmap -Each release is populated with user stories Necessary for that release

Sprint's backlog

-A subset of the release backlog -Contains user stories to be developed in the sprint

Connect

-A typical release will include multiple use cases, and each use case will have multiple user stories -User story cards may be arranged in a 2-dimensional way to show the sequence of the business need horizontally, as well as priority of user stories vertically supporting use case -Story maps used to connect dots of various user stories and relationships

Choosing the Right Pilot Project

-Select pilot project carefully, if too small or too short in duration, or unimportant criticize as being mickey mouse pilot -If pick something too large, too long or too critical might end up having too much lime light on you, and any hint of failure may cause a team to abandon method, regardless of causes of failure

Sprint Retrospective (Ceremony 4)

-After conclusion of Sprint Review -Time boxed at 45 minutes/each week of Sprint (ie: if Sprint is 2 weeks duration... retrospective is 1.5 hrs long) -Attended by all scrum team members, but PO is optional -Answer 4 questions: 1. What worked well? 2. What did not work well? 3. What should be done differently? 4. What still puzzles us? -1 or several problem detection techniques should be used -Vital part of continuous improvement -Ends w/ updating team's velocity and projects information radiators

2. Working Software over comprehensive documentation

-Agile Manifesto Documentation doesnt demonstrate progress or value.Therefore emphasis is on working software

Responding to Change over following a plan

-Agile Manifesto Rather than being constrained by an original plan, developers should embrace change in order to meet the dynamic needs of the customer

3. Customer Collaboration over contract negotiation

-Agile Manifesto Rather than create a detail statement of work and then negotiating contracts, developers and customers should collaborate in order to progressively determine the requirements of the project

1. Individuals and Interactions over Processes and Tools

-Agile Manifesto While processes and tools are necessary the emphasis is on individuals and the interactions btwn them

Why is diversity a desirable attribute in Scrum Team?

-To encourage different view points and healthy debate to emerge -Diversity ensures broader perspectives & dissenting view points

How and Why DevOps works?

-Agile teams develop functionality & create value for the business -Operations teams are the interface w/the business, and they take over this functionality from the development team -When functionality is deployed into production - Business value realized

Roadmap/Release level Planning Considerations

-Market demands -Regulatory requs/needs -Existing customer expectations -Determining the Sprint Length -Estimating the Team's initial velocity -Assigning individual user stories to each Sprint ~For each release we will estimate each of the User Stories ~User stories from the Product Backlog will be placed into various Release Backlogs ~User Stories in a Release Backlog will then be selected for Sprints

Product Backlog

-Master container Of all the user stories in the project -Continuously prioritized So that maximum value is delivered to the customer -responsibility of PO -contains User Stories (non-technical or nonfunctional as well, or risk or defect related user stories) -must be continuously groomed (process of adding/removing US's based on needs of customer)

User Story

-Use Case -Template -Requirement -Connect -User -Stories

The best way to divide a large Project Team into smaller Scrum Teams is

-Around features that need to be developed -Do not align members around components or specialties, and mix Senior and Junior devs

What would the Scrum Master do when the Team's estimates in a Planning Poker do not converge?

-Ask Team to come to an agreement -They may choose to go w/average or highest or continue discussing, but SM needs to wait for them to agree

After the start of a Sprint, the PO wants to add one more story to the Sprint backlog. How should the Team respond to this?

-Ask the PO to wait until the next Sprint -After completion of Sprint Planning, once team has made commitment, the Sprint Backlog can't be changed. -B/c Sprint is short time window, it's better to wait than to dilute the team commitment

Stories

-Backlog: contains User Stories and Epics -Epics : Large, low priority user stories; eventually dis-aggregated into smaller user stories -User Stories : lightweight mechanism to capture requs, also acts as an agreement btwn customer and team members to discuss detail requs about a Sprint

Pillars of Scrum - Adaptation

-Based on the observations made during inspection, make process changes to avoid problem reoccurrence and improve delivery position

Scrum Events/Team Practicies

-Be flexible and open to new options -Decide whether to synchronize the start and end dates or stagger (Staggering may lead to no point in project life cycle where all teams are done) (Synchronizing sprints may mean teams working on 2 week sprints or 4 week sprints) -Sprint planning may be challenge due to dependencies across teams (EX: team A may say cant commit to doing feature if Team B doesnt provide them with a particular API -Can be resolved by ~staggering planning by a day (allows PO and CPO to attend multiple planning sesions throuout day) ~ or create big room where all teams gather for planning effort (first CPO would address everyone and explain overall goals of the product, then Teams would breakout into individual planning sessions, where PO's can walk over and ask if they have ?'s or dependencies) -Form communities of practices across different teams (EX: virtual architecture team, UI team, or Test Team) ~enables share practices and templates that assist in standardizing consistency and making integration easier ~could be virtual or formally structured teams depending on the situation and org

Waterfall

-Big planning upfront to determine the detailed scope of project, and establish project's performance base lines. -Once executing begins, results compared to baselines to determine health of project -Best with project management -logical; however, change is cumbersome and expensive

Selecting the Product Owner

-Can the Product Owner position be Part Time? NO, not recommended, demands on PO increase with time, 1 PO for each development team -Can a team of Product Owners be formed to serve multiple development teams? YES, possible for large projects with high level complexity, and for redundancy, if PO isnt avail this helps -Can a PO be remote located? YES, for distributed teams it is necessary, must be clear in processes that they must be avail even during non-normal working hours, Sprint planning and reviews

Selecting the Scrum Master

-Can the Tech Lead be the SM? YES, must take tech decision making hat off when SM though, shouldnt become the go2 person for all tech matters of project. -Can Scrum Master role be part-time? YES, Its intense, needs a lot of commitment, but with time may decrease, but scrum master must give highest priority to his SM duties -Can Scrum Master duties be rotated? NO, not a good idea, as SM needs to have some soft skills, done to create learning opportunities for others wanting to transition, or if SM gets Manager role and cant be servant leader

3 C's of a User Story

-Card : Each user story should be written on an index card of about 4x6" in size -Conversation : User Story should be the starting point of conversation btwn the team and PO -Confirmation : User Story must also provide acceptance criteria to help the team understand the requs

Osmotic Communication

-Communication that flows through currents, through overhearing, and often through non-linear channels -This kind of communication is good b/c it multiplies collaboration, and hence the productivity of the team

Story Card

-Could be physical card -Or if team is distributed a Virtual card

Other XP Practices

-Creating a coding standard for the project -Collective code ownership -Pair programming -Establishing a sustainable pace forever - Creating a system metaphor to increase communication effectiveness

XP Team members

-Customer -Coach -Programmer -Trackers -Testers

Use Case

-User actions/functions required by system -Supported by multiple user stories

DSDM Planning Philosophy

-DSDM (flipped upside down from Trad): schedule and budget are fixed, scope is variable (the project will end once schedule and budget constraints have been met) 80-20 rule used to guarantee there will be a minimum subset of features, and additional work can be done only if there is left over time and capacity -Traditional Planning Approach: the scope is fixed and the schedule and budget is variable

Scrum Values

-Decision making framework -during course of scrum project the team needs to make sure the decisions are in line with the values of scrum C-FORC -Commitment: to success (b/c scrum teams are empowered to self organize and have control over their destiny) -Focus: on excellent work (b/c Scrum teams only focus on a few things at a time they work well together and produce excellent work, deliver valuableitems sooner) -Openness: about the concern (as a scrum team works together they express how they are doing, whats in their way and what their concerns are so they can be addressed) -Respect: by sharing success and failures (teams come to respect and each other and gain worthiness of mutual respect) -Courage: to undertake great challenges (working together as a team they feel supported and have more resources at their disposal)

Project Management Office (PMO): Potential Roles

-Developing training plans -providing coaching -assist with reporting or compliance -be a gatekeeper for projects -provide and maintain tools -assist in collecting data -identify and reduce waste -establish communities of practice

DevOps

-Emerging discipline fast becoming a critical element of Agile Methods -Science of moving code from development to testing, to production, or in general, from one n to another in an automated and efficient manner (Agile teams cannot do this w/out strong support from DevOps) -Related to strong tool set related to build and deployment management systems -Agile and Scrum techniques have to be complimented by DevOps processes so that in order to ensure that the value developed can be deployed quickly and seamlessly

Pillar of Scrum - Transparency

-Ensure Project Visibility (all aspects of the process or project must be visible to those responsible for the outcome) -Use information radiators for project progress (the team will use these in which key info like the product backlog, sprint backlogs, impediments, risks, and project progress are made transparent to all stakeholders) -Document and publish a "Definition of Done" (so that everyone knows that when a particular sprint or project is completed)

A part-time Scrum Master was working on a critical development activity when another team member asked for help. What should the Scrum Master do?

-Explore best way to help team member -SM must be fully committed to role even if part-time assignement

Identify the criteria to select the right Agile pilot project

-Medium size, Medium duration, Medium Business Criticality, and High Visibility -you want to pick a project not too small or big, not too short or long, not too critical and not too insignificant, and preferably high in terms of visibility and business sponsorship.

Scaling Scrum to large projects

-Multiple teams required to work in parallel -Huge product backlog hence requires multiple PO's -Multiple teams need to work in parallel to complete the themes, epics, and stories involved in a large-scale project (results in dependencies at functional team and technical level) -Larger teams will have a greater need for specialization -Requirement of User Interface Designer to ensure interfaces are standardized and use similar style sheets -Governing of data related policies to ensure that the data integrity concurrency and performance are guaranteed across the board -When and how nonfunctional requs are developed becomes more critical and if not managed well can compromise the system

Crystal Method

-developed by Alistair Cockburn -Designed for projects ranging from small teams developing low critical solutions to large teams developing critical solutions -strong on communication

Agile Scaling

-For Small projects with small teams -Co-location and face-to-face interaction -Not really design for distributed teams, dealing with dependencies, and non-functional requs -But, can be scaled for larger scale projects, but make it work, doesnt happen automatically

Lean Software Development

-Genesis in Lean Manufacturing -Originated w/Toyota Production System -Tom and Mary Poppindieck applied lean manufacturing to software dev (focuses on elimination of waste, irregularities, overuse)

Kanban

-Genesis in Toyota Production -Japanese term for "Signal Board" -Used to manage the Throughput of a process by: **Identifying bottlenecks **Setting work in process limits **Displaying the status of the entire process in 1 view -Value Chain/Steps in the Process are represented by columns (items are pulled left - right in a just in time manner)

All In as agile adoption pattern

-Has the advantage of time (you dont have to wait for the pilot project to be completed and then convince everyone that it was successful -Quicker transition -Lower cost transformation -Learn from other team's experiences from similar issues -Require more Top-down buy-in support -Assists in making changes

Checklist for SCRUM adoption

-Has the investment in SCRUM paid off? -What is our next area of improvement -Should we continue with SCRUM? -Are we better off than before? -Are we reproducing better products? -Do our products have fewer defects? -Are we able to ship faster than before?

Agile and IT Service Management

-IT services are managed and delivered through IT Service Management, governed by ITIL practices -Agile and Scrum also link to IT Service Mgmt b/c the products are ultimately tied to business services supported by IT Operations

The PO wants a feature urgently, and the team's estimate for the feature was 3 sprints. What is best course of action for SM?

-Organize team meeting to explore options of meeting the requs in time -SM must facilitate a discussion to explore options -It may be possible to reduce breadth or depth of feature to achieve @ least a portion of it within the expected timeline

Values and Practices shared by all Agile methods

-embracing change -light weight or lean documentation -Daily Stakeholder collaboration -Incremental delivery -Continuous improvement

INVEST (Good user stories)

-Independent : must be independent of each other & deliverable as an individ. unit -Negotiable : must be negotiable in terms of implementation -Valuable : must create value for the customer -Estimable : should be clear enough for the team to estimate the work involved with accuracy -Small : story must be small enough to be completed within a single Sprint (sprint may have multiple stories, but US cant span multiple sprints) -Testable : for correctness and acceptance

Common Failure Modes (Anti Patterns) for Product Owner

-Ineffective delegation of decision making authority: EXAMPLE- when PO doesnt make decisions, and delegates to business analysis or team leads, and then 2nd guesses them, confusing team... if needs to be delegated the decision they cant be involved -Making unreasonable demands: cant be aggressive or push team to work too hard on behalf of customer, this violates Scrum trust, pace, etc... requires intervention of Scrum Master -Advocating Cutting Quality: in order to get desired features. Can result in mounting technical debt, reduced velocity, and could lead to product failure... Scrum Master will need to intervene if Team and PO cant agree on how best to ensure quality

Parking Lot Chart

-Invented by Jeff Deluca -Communicating Progress part of feature development -Each of user visible functions are broken down into subfeatures -Meaning of colours: ~White : not started ~Yellow : work in progress ~Green : completed ~Red : attention needed

Identify what is wrong with this scenario: As a teller

-It does not clearly describe what the need is; it sounds more like an acceptance criteria

Starting Small as agile adoption pattern

-Less risky -pick the most suitable team for transition -have energy to focus exclusively on a few teams -guarantee a successful transition -defer the radical change -likely encounter less initial resistance

How to connect ITIL lifecycle connects with the Development lifecycle?

-Product Owner brings up product requirement that must become part of the overall IT service strategy. (in the form of an improved user story or epic with a business case) -Transition of the features into the Sprint backlog must be aligned with the Service Design ( as Agile teams is developing the feature, the service transition plan must be in place...) -Service transition plan must be formulated to integrate developed feature into operations smoothly

Scrum Lifecycle (Agile project using Scrum)

-Product Owner owns the product backlog and collaborates with the team to develop User Stories or requirements for the project -Product Backlog is prioritized with higher priority items occupying the top -In collaboration w/the PO the Team decides how to group the User Stories into Releases based on the Product Roadmap -After Release planning is completed the User Stories are selected from Release Backlog and moved to Sprint Backlog -Duration of Sprint will be 2-4 weeks -Once Sprint Backlog has been dtermined the team disaggregates each User Story into Tasks -During each Sprint the User STory is put into Backlog Items, and as code is written it is integrated into the System through Iterations, and Daily Scrum Standup Meetings are heald -End of Sprint there is a Sprint review where working software is demonstrated and presented to Customer for Acceptance -Team conducts a Sprint Retrospective, looking at 3 ?'s -Team's visibility and velocity is updated, and info radiators updated which shows progress -Project repeats itself til completed

Advantages of Affinity Estimation

-Quick and Easy -transparent decision-making process -creates a positive experience rather than creating a confrontational one

Scrum Master: Atrributes

-RESPONSIBLE : for enabling the team & maximizing the team throughout (remove anything that impacts team's ability) -HUMBLE : Able to let the team get the glory w/out letting ego get in the way (able to work in the background & us "WE" statements) -COLLABORATIVE : Creates a culture of collaboration in the team (encourage conversations with team members and stakeholders) -COMMITTED : Show 100% commitment to the team even if they are not full-time Scrum Masters -INFLUENTIAL : Be able to create influence w/out any authority (natural communicators and convince other approaches) -KNOWLEDGEABLE : Experts in Scrum w/an understanding of the technical enviroment

Ideal Time

-Rather than using story points -Estimate by ideal time -the amount of time it takes to complete a piece of work -Estimation is challenging b/c its tough to estimate distractions, meetings, and interruptions, and vary from individual -Only considers actual work time, not distractions -time estimates have to be converted into elapsed time depending on the amount of time spent working and on distractions

Cultivating Culture of Whole Team Responsibility

-Reduce reliance on specialist -Everybody should be able to perform a little bit of everything in every Sprint (keep everyone busy by having them do a little bit of everything) -To give time to the testers we should try and finish before end date of the Sprint -Concept of Team Learning should be encouraged then share the knowledge across the team to develop more generalists to help -Teams will develop and come together better when given a challenge which will motivate them, and must remove the fear of failures, achieve this by building the team with diversity -Team must be allowed to create their own sustainable pace which includes providing time for Reflection, Introspection, and Innovation

Output of Release Planning

-Release Planning involves determining how many required Sprints to complete user stories and release backlog -Sprints to Release Planning Meeting to Release Plan to Iterations -Planning Horizon will be about 3 Sprints into the future with subsequent Sprints (4-7) planned in detail leter as the project progresses {Rolling Wave Planning}

Product Owner: Roles and Commitments

-Responsible for the project success -Establishes project Vision: sharing the vision and gaining consensus, creating and maintaining the product backlog (Pruning is prioritizing and re-prioritizing, grooming is keeping it current and relevant by progressively elaborating User Stories, and adding/removing US) -Defining project boundaries (defining market Window and Timeline for project, defining minimal market feature set, or MVP): creates release plan according to product roadmap, sets expectations with respect to non-functional requs (setting expectation should load w/in 3 milliseconds, or certain security guidelines should be followed) and establish acceptance criteria for project, and more minutely on each US -Not done in isolation, Scrum values interaction and collaboration

Agile Methods

-Scrum -Kanban -Feature Driven Development (FDD) -Crystal -Lean -Extreme Programming (XP) -Dynamic Systems Development Methodology (DSDM)

Expectation Management

-Set the right expectations for Agile -Dont promise moon it will cause disillusionment -Dont promise too little Promise it is beneficial, but their will be roadbumps along the way -In the beginning most teams have a tendency to over estimate and under deliver -the will need about 3-4 sprints to establish baseline velocity

Managing Product Backlog

-Should have no more than 150 stories at a time (just add more details to the stories sooner, so that there is more User Stories ready for Sprint) -Stories and Epics should be grouped in themes (1 PO per Team, maybe 2 teams) -Hierarchy of PO's should be established on larger projects -Above PO's establish Product Line Owners (an ERP system may be done along Modules being implemented) and place Chief Product Owners at the highest level

Scrum Master: Roles and Commitments

-Skilled "servant leader"; has little formal authority; helps achieve outcomes w/out interfering with team's autonomy -A facilitator of Scrum events (ie: Sprint planning, Daily Standup, Sprint review, Sprint Retrospective) -An impediment remover -A "process Coach"

Factors affecting Sprint duration

-Stability of the backlog (Once Sprint begun the duration is never changed, nor User Stories added or removed or altered ...If many changes expected, shorter Sprint duration best... if backlog stable then longer Sprint is best) -Overhead Costs(Every Sprint will have planning meeting, review, and retrospective ... if team lowers costs by automated testing, continuous integration, etc costs will be absorbed more easily, making shorter sprints best... or if costs are high then longer duration sprints best)

User Stories and Epics

-Starting point for planning is defining requs --In Agile projects: requs are captured as Product Backlog

Info on a Story Card

-Story Identifier and the name (short name (top LHS) and unique identifier (top RHS) -Story description (a sentence or 2 describing a feature in the end users term) -Story Type (indicator as to origin of the user story... from customer domain, technology, or defect (bottom LHS)) -Estimated Work Effort (rekative effort used to complete story, expressed in story points (bottom LHS)) -Estimated Value Points (Realtive value of the user story from PO's point of view) -Acceptance Tests ( the test used to verify success criteria has been met (put with description)) -If Virtual Tool used (may contain additional info, info of persons and attachments... exploration factor indicating uncertainty)

Pillars of Scrum - Inspection

-Team regularly inspects progress towards project goal, problem areas, and deviations from plan

XP-introduced Standard Practices

-Test driven development (where the team writes the test before developing the code) -Continuous Integration (the practice of regularly integrating new code into the system, and using automated testing to determine the status of the integration) -On-site customer (essentially made the customer part of the team, on-site, and participate w/the team on a daily basis) -User stories (quick and effective way to capture customers requs and make sure there is an agreement btwn the customer and developers regarding whats to be developed)

Velocity used to Calculate

-User stories in a given Sprint -How many Sprints are going to be required to complete a Release (EXAMPLE: if Team completes 5 User stories in a Sprint, and points for each of those users stories are 5, 3, 8, 13, 2... the velocity of the Team would be 5+3+8+13+2= 31) -Incomplete User Stories get no credit (Team only completed 10 of 13 points for the 4th User Story, when calculating the Velocity they are not considered, incomplete user stories deliver no value to customer)

Who should determine duration of the Sprint in Scrum?

-The Team should determine the Sprint duration that they are most comfortable with, given the stability and the cost of iterating. -Its recommended duration shouldnt be more than 4 weeks

Definition of DONE

-VIP artifact for Scrum Team -Primary reporting mechanism for team members -"Def of Done" at various levels: for a feature or user story, for a Sprint, for a release -A checklist of activities that adds verifiable or demonstrable value to the product -Created by Scrum Master in consultation with the team

Story Points

-are relative -The team will assign story points for user stories based on comparing stories to each other -EXAMPLE: Triangulation Approach- small=1 , medium =5 , large =13; these become benchmarks against all other stories compared; if team thought US has value of 11 points, then they would use 13 -More accurate than measuring things in absolute values -the points assigned to a user story cover the complete effort of user story completion, it's not broken into components

A team completed 8 out of 10 stories planned in a Sprint. What should be done about the remaining 2 stories?

-They should move back to the Product Backlog for re-prioritization -Extension to the Sprint is not recommended -no guarantee that they will be automatically selected for the next sprint

Scott Ambler

-Thought Leader of Agile -"is an iterative and incremental evolutionary approach project development appraoch to project dev... collaborative manner in self organizing teams...produce high-quality software in cost effective & timely manner...meets changing needs of stakeholders."

Daily Scrum (Ceremony 2)

-Time box is 15 minutes - FIXED - All scrum team members attend -Each development team member individually answers 3 ?'s: 1. What did I do yesterday? 2. What am i going to do today? 3. What are my impediments?

Sprint Planning (Ceremony 1)

-Time boxed at 2 hr/week (ie: if sprint is 2 week duration then time box is 4 hours... if 4 weeks duration, time box is 8 hrs) -All scrum team members should attend -VIP: team's capacity and definition of DONE -Select User stories: 1. Team Velocity 2. Commitment -Team buy-in is critical, and Goals of Sprint should be clear and desired Outcome clearly articulated w/def of DONE

Sprint Review (Ceremony 3)

-Time-boxed at 1 hour for each week of the Sprint (ie: Sprint is 4 weeks duration... Sprint review meeting is 4 hours) -All scrum team members including interested stakeholders should attend -Purpose of review is to demonstrate working software and obtain feedback (feedback range= full acceptance to complete rejection)

Between Sprints 4 and 5, the bottom of the Burn Down Bar Chart for Release moved up above the horizontal axis. What might have caused this?

-Work might have been removed from scope -Work getting added or removed is indicated by the movement of the bottom of the bar

How should the performance evaluation process change as the Team embraces Scrum?

-You need to put a lot more emphasis on Team Work. -Retrospective is a time to analyze the process and Not the individual performance. -Scrum Master and PO feedback should be considered, they do not do evaluation

Estimation Cone of Uncertainty

-cone looks like a funnel lying on its side, with LHS opening being very large, and narrowing going to RHS as project progresses and uncertainty is reduced -Understand the cone of uncertainty, which is an ESTIMATE or GUESS. Being accurate is neither possible nor advisable; being predictable is good enough.

User Stories

-features -functions -requirements that deliver value to the customer -provides mechanism for gathering basic info about end user experience, capturing high level requs, development work estimates, and defining acceptance tests -Must be small enough to be completed in 1 Sprint -If too large needs to be dis-aggregated into smaller user stories -Once selected for Sprint, dis-aggregated into tasks, only when tasks are completed it will be marked complete and incl. into teams velocity

Advantages of Planning Poker

-fun and fast -gets whole team involved -whole team comes to understand more and more about user story -each team member has the opportunity to contribute expertise -discussions help to offer clarity, direction, approach, and design

benefits of SCRUM

-higher productivity and lower development costs (by reducing waste and irregularities by only developing what is absolutely essential for customer) -Improved stakeholder (customer) satisfaction (by collaboration btwn dev/cust to help with changes and needs) -Higher quality software (using techniques like test driven development, continuous integration, exceptance test driven development, and refactoring can lead to nearly defect free software) -improved employee engagement and job satisfaction (by empowering a team to be self-organizing, the team can determine how they are going to deliver value to customer and establish a sustainable pace) -Faster time to market and early ROI (by incrementally delivering value/software to customer in short iterations, working software can be deployed sooner to customer)

SCRUM evolution

-introduced in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka -a new approach to increase speed and flexibility

Scrum

-most popular Agile Methodology -a new approach to increase speed and flexibility -provide value to the organization in the form of higher productivity, reduced costs, better quality, and more engaged and satisfied employees -relies on frequent feedback and experimentation resulting in better predictability and flexibility -always tests and measure actual results of scrum adoption

Product Owner

-responsible for keeping product backlog updated -Pruning backlog: prioritizing and re-prioritizing

Agile Manifesto

-signed by 17 leading software devs in Feb 2001 "We are in covering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working Software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is while there is value in the items on the right, we value the items on the left more."

SCRUM features

-simplicity and proven results -encompasses agile engineering techniques -emphasizes small teams and team empowerment -welcomes changes to requirements -allows working from a source of prioritized work items -daily status meetings -offers team commitment to shippable software at end of each sprint

Scrum Estimation is not necessarily more difficult...

... however, Scrum exposes bad estimates sooner, which is good thing -leads to ability to improve accuracy of the estimates

Overestimation and Underestimation...

... is present in a process; however, underestimation is more prevalent and more dangerous. -Deliberately overestimating/padding Not acceptable in project

Only Estimates that Matter...

...is the one given by the Team in collaboration with PO. -"Nothing is impossible for the man who does not have to do it himself."-A.H. Weiler -In Scrum the Team does the estimating, others may have an opinion, and may even doubt estimates, but they dont do work -Team decides hoe to complete user stories and satisfy customer -Dont push estimations from top down to Team (would be counterproductive)

Crystal levels of criticality

1. Comfort 2. Discretionary money 3. Essential money 4. Life -Depending on the level of criticality in project there may be additional need for verifications validations and trace-ability measures)

Examples of Distributed Teams

1. Development team in the US and Test team in India OR 2. Some developers and some testers in US and India BEST: in both places mix, b/c encourages dialogue and eventually team bonding is more superior

Lean Principles

1. Eliminate Waste: anything that does not add value to the customer is considered waste 2. Amplified Learning: by using short iterations refactoring, integration testing, and frequent customer feedback sessions 3. Decide as Late as Possible: best way to manage uncertainity is by gaining info, minimizing assumptions, defer commit to last responsible moment, and breaking dependencies btwn components 4. Deliver as Early as Possible: short iterations or small batches provide valuable feedback oppportunitties and allow for decision making 5. Empower the Team: the team the source of decision making and management turns to the team to understand the best options and their costs 6. Build Integrity Within: make sure there is quality in the system by ensuring there is automation of testing through builds, installs and contin integration

Crystal Key Principles

1. Frequent Delivery 2. Focus 3. Reflective Improvement 4. Ease of access to experts 5. Personal Safety 6. Technical Enviroment 7. Osmotic Communication

Waterfall Approach : Software Development Life Cycle

1. Initial - collect all of the requirements necessary 2. Design - determine software structure 3. Implementation - develop software 4. Verification - test software for correctness and acceptance 5. Maintenance - after software has been deployed

DSDM key Principles

1. Involvement is necessary to develop the right business solutions 2. Requirements may evolve, however timescale fixed (the concept of time boxing) 3. Early delivery because it results in early ROI from the value created 4. Implemented based on 80-20 Pareto Principle (in this context is that 80% of the value is going to come from 20% of the features) 5. Nothing is built perfectly the first time (rather the best solutions are solved through iterative development)

DSDM Core Techniques

1. Iterative Development: evolutionary approach to software dev, founding concept in Agile 2. Time Boxing: the technique where the amount of time for the duration of an activity, a meeting or an effort is fixed (EX- iterations are time boxed, so when its time has been established it is NEVER changed) 3. MoSCoW prioritization 4. Facilitated Workshops (a collaborative event in which the participants focus on creating correcting or documenting solutions or deliverable, primarily for planning efforts) 5. Modeling (discovery technique used to create best solution for the requ or feature)

Nonlinear Scales Used for Values of User Stories

1. Modified Fibonacci Series (1, 2, 3, 5, 8, 13, 20) 2. Doubles (1, 2, 4, 8, 16)

Scrum Roles

1. Scrum Master - Assists Development team and PO, works to maximize ROI; empowers development team by fostering creativity, removing impediments, and coaching/mentoring as apprapro 2. Product Owner - responsible for project success by defining project vision, requs, & priorities; needs to resist temptation to manage team or add more important work after starting of Sprint; needs to make hard decisions during Sprint plannning 3. Development Team - has 5-9 self-organized members w/mixed roles; should independently self organize & plan to meet the PO's goals

Scrum Ceremonies

1. Sprint planning meeting 2. Daily Scrum 3. Sprint review 4. Sprint retrospective

9 Principles of Scaled Agile

1. Take an economic view - org must have robust framework to evaluate the economic consequences of decisions made (dev costs, cycle time, value delivered, risk being, even cost of delaying decisions) 2. Application of Systems Thinking - Enterprise scale dev. requires a system built by design, not happen automatically, team must be organized 3. Assume Variability; preserve options - change is inevitable, our design practices and decision making processes must prepare for this 4. Build incrementally with fast, integrated learning cycles - allows for frequent and planned integration point so learning is holistic and not isolated to specific teams 5. Base milestones in project or program should be on objective evaluation of working systems - should be evidence based, demonstration of certain # of features working together in integrated system, dont have artificial milestones 6. Visualize and limit Work In Progress (WIP), reduce batch sizes, and manage queue lengths - reducing bottlenecks, and build up of queues contained and managed 7. Apply cadence, synchronize with cross domain planning - beneficial to have a predictable rhythm, in cycles, sync with planning across domains, assess where we want to be and what needs to be accomplished in next cycle 8. Unlock the intrinsic motivation of knowledge workers - team's work rely on knowledge, important to understand the drivers of motivation among knowledge workers, understand roll of compensation, economy, a higher purpose, respect roles 9. Decentralize Decision Making - centralize only strategic decision making, enables you to leverage the knowledge of those on the ground

Kanban Steps

1. Visualize workflow by creating columns for each step 2. Manage flow by minimizing the work in progress 3. Improve process by applying Kaizen principles

2 main approaches to managing projects

1. Waterfall 2. Agile

Attributes of Product Owner

1.) Available: need to be present at Scrum meetings, events, and reviews... must be present to answer ?'s about priorities and clarify requs 2.) Business Savvy : understand of the business or domain of the product (EXAMPLE: if product is in telecom domain, they need to understand it or cant create viable roadmap) 3.) Excellent Communicators : skilled listeners, need to engage with stakeholders, skilled at knowledge sharing (sales to analyst hat) 4.) Decisive : development team cant wait for decisions to be made, cant appoint committees for every decision, must be willing to make difficult choices during Sprint planning meeting 5.) Empowered : necessary power to make decisions and be accountable for decisions made, not refer to higher authority every time

5 Attributes of Succesful SCRUM Adoption (ADAPT)

1.) Awareness: that the current approach/process is not working and change is necessary 2.) Desire: adopting Scrum can require a significant change in and organization's culture, there must be a clear desire to adopt and confidence that will result in the improvements desired 3.) Ability: the team must be willing to make the effort necessary to actually implement Scrum, incl. coaching mentoring and potentially working w/ Senior mgmt to gain support for effort 4.) Promote: Likely that team will have to share successes & wins w/result of scrum adoption with senior mgmt in order to have their contin. support 5.) Transfer: transferring/spreading advantages of Scrum throughout the company

Questions to ask to know when to Apply Agile

1.) Clarity of Goal - 2.) Clarity of Solution - Waterfall makes sense when the Solution as well as the Goal are Clear (in chart bottom left) Agile Project MGMt is a good fit when the Goal is Clear, but the Solution is NOT Clear (the iterative and adaptive Lifecycles of agile allow us to try different approaches until we discover the best solution) in bottom right of chart Extreme Project Management very into Agile Mgmt with very short stints of exploration that take us step by step closer to understanding solution and Goal

Specific measures for Operational Excellence benefited by Balanced Scorecard for Scrum Teams

1.) Define Predictability metrics - (EXAMPLE) Did the project end at the desired Sprint or did it require extra Sprints? 2.) Define Productivity measures - (EXAMPLE) Functionality delivered per release or features developed per developer 3.) Measure quality metrics such as defects found in internal tests, continuous integration tests, or those that are detected by customers

Common Failure Modes (Anti Patterns) for Scrum Master

1.) Inappropriate Selection - having wrong person as SM, either by self-appointment or natural progression by team... team will not be as affective w/out SM help, they will need coaching to understand duties 2.) Scrum Master doubling as Developer- they will get sucked into their own tasks and neglect SM duties (EXAMPLE: even if busy w/own tasks, should never say I am Busy) 3.) Scrum Master deciding for the team- cant assume decision making authority, honor teams ability to self organize, and assume accountability for the commitments and decisions that the team makes... Patience is a virtue, wait til team feels comfortable

More Approaches for conducting Agile transformation

1.) Make a public display that demonstrates commitment more and is more likely to execute OR 2) keep it low-key and work in stealth mode reduces the initial resistance and allows choosing when to go public

Specific measures for User Orientation benefited by Balanced Scorecard for Scrum Teams

1.) Measure downtime experienced by users in the field 2.) Find measure of user satisfaction through survey or Net Promoter Scores

Specific measures for Future Orientation benefited by Balanced Scorecard for Scrum Teams

1.) Measure employee satisfaction in terms of complaints or employee satisfaction scores... indicate how the organization is positioned for future success 2.) Measure understanding and maturity of Scrum the key indicatore being attendance and participation in Scrum Ceremonies

Specific measures for Business Value benefited by Balanced Scorecard for Scrum Teams

1.) Measure how frequently incremental value is delivered to customer 2.) Measure substance of releases in terms of their user visible features

5 Parameters of Cultural Differences

1.) POWER-DISTANCE INDEX (PDI): the capability of team members to Reconcile on even distribution of power... extent to which less powerful members accept unequal distribution of power (Some cultures or hierarchial, and others are flatter than do not recognize authority) 2.) UNCERTAINTY AVOIDANCE INDEX (UAI): Refers to the ability to live with uncertainty and ambiguity, tolerance of 3.) LONG-TERM ORIENTATION (LTO): Refers to whether you like to work for long-term benefits or instant gratification 4.) ACHIEVEMENT ORIENTATION (ACH): Looks at how some cultures focus on visible indicators of success while others respect the work and the journey of one end goal 5.) INDIVIDUALISM (IND): Looks at the preference to Work is individuals as opposed to working in teams

Following an Iterative Adoption Process - Agile transition for organization can be managed these ways:

1.) Seek and influential sponsor who is committed to the project - must be able to walk political tight rope, and must be passionate or committed to project 2.) Build an Enterprise Transition Committee (ETC) - consists of evangelists who will initiate the change, assist teams, encourage stakeholders, etc... also identify potential issues and org, committees around them (ie: Test Automation committee) 3.) ETC should lead the Creation of product backlog process and track project's progress/identify specific milestones, set up Sprints and committ the closing of these items

Approaches to Growing Agile Tribe

1.) Split and Seed - split the first successful team and assign them to sow the seeds of Agile (slower but gives a deeper indoctrination) OR 2.) Grow and Split - grow an entire team in Agile doctrines and then split into other teams organically (faster b/c you get multiplier effect

Approaches to Technical implementation of Agile

1.) Technical Practices Early (almost Simultaneously) - significant success with early adoption, can almost instantly see benefits (pair programming, or continuous integration) OR 2.) Technical Practices Stages - anticipates significant resistance and watch how the team acts initially

12 guiding Principles that support Agile Manifesto (first 6)

1.Our highest priority is to Satisfy the customer through early and continuous delivery of valuable software 2. All the welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout project. 5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Backlogs

3 Backlogs used in Scrum: 1. Product Backlog 2. Release Backlog 3. Sprint Backlog

XP Roles

3 Categories: - Customers: Business experts-product managers, domain experts, interaction designers, business analysts (ideally there will be 2 for each 3 programmers) -Programmers: implementation experts and generalizing specialists (ideally 6-10 on a team) -Testers: quality experts focused on- Unit Testing, Integration Testing, Acceptance and Exploratory Testing (ideally 1 for each 6 developers)

Prioritization Models for Backlog

3 Models for prioritization: 1. Value Based Prioritization 2. Kano Model 3. Relative Weighting

Pillars of Scrum

3 Pillars of Scrum: 1. Transparency 2. Inspection 3. Adaptation

Retrospective

3 Questions: 1. What went well? 2. What did not go well? 3. What should be done differently going from here on out?

12 guiding Principles that support Agile Manifesto (last 6)

7. Working software is the primary measure of progress. 8. Agile processes promote sustainable Development. The sponsors, developers, in users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design it enhances agility. 10. Simplicity, the art of maximizing the amount of work not done, is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Interpretation of 80-20 rule used in DSDM or Atern

80% of the value is delivered from 20% of the work -the trick is to know what is 20% so we can prioritize work accordingly

See the Whole

A Lean principle - encourages team to focus on big picture, think beyond the moment. and figure out the larger ramifications in the context of the entire process in the long term

Facilities

A Scrum team's workspace should be redesigned to Encourage open communication and collaboration Book " Agile software development: A cooperative game" by Alister Crockburn -may be resistance to give up private space, so create Caves, Team Room/War Room = Comments -Team space must accommodate information radiators (ie: product and sprint backlogs, burn down charts, other feeddback devices, LED Screens etc) -some food and drink avail/ mini bar / coffee bar

Affinity Estimation

A technique used by teams to estimate a large number of user stories in story points 1. Silent relative sizing 2. edit the wall 3. Place items into relative sizing buckets 4. product owner challenge 5. store the data (large # of user stories can be quickly categorized with small on LHS, and large on RHS) -use t-shirt sizes (XS, S, M, L, XL)

Agile

An iterative, incremental method for developing products... -Project Management Approach -For complex and uncertain projects -no heavy detailing upfront -Evolves as short increments are completed -Evolved from a family of light weight, quality driven approaches to software dev

Tracking Releases

Burndown bar chart tracks the progress of a release or a Sprint (vertical axis is Story Points and horizontal axis is Sprints) -Helps to visualize work that gets added or removed from the scope of the release or Sprint -Length of the bar indicates the overall work remaining in the project -the movement at the top of the bar indicates completion of work by the team -The movement at the bottom of the bar indicates work getting added or removed from the release

Authority to remove a Team member

Cannot be given to Team -b/c even though self organizing, the hr people will need some Scrum training so they may make these decisions

Velocity

Capacity of the Team to complete value and to track value delivery to the customer -Amount of user story points that can be completed by a Team in an individual Sprint -NOT an estimate or prediction, its an observation

XP practice enbaled through Pair Programming

Collective Code Ownership- pair programming ensures that every line of code has been seen by at least 2 developers, hence it directly compliments the practice of collective code ownership

Forming Scrum Teams

Considerable factors while deciding Teams: -Feature Teams over Component Teams (best not to put just UI dev together, or API or service devs; b/c each feature/user story with require all components) -Assemble the right people(mix on senior and junior roles, diversity in gender, personality traits etc) best to preserve whole team, and not mutli-project members -Distributed Team (should be co-located in same room)technology processes and ground rules put into place

If a build breaks and tests failed mostly due to cross-team issues, what should be done about the daily integration process?

Continue daily integration process - investigate the causes of the failures and fix them.

Relative Weighting

Created by Carl Weigers (thought leader Agile) technique is based on premise that features that provide the highest benefits after adjustments for cost, risks amd penalties should be given the highest priority a. A features Priority is directly proportional to value it provides, and inversely proportional to its cost and risk associated with its implementation {Priority = Value/(Cost + Cost Benefit + Risk + Risk Benefit)} b. each category uses scale of 1-9 {Calculate Value = Benefit + Penalty} -Benefits : reflect value each feature will provide -Penalties : reflect negative effect the customer will experience if the feature is not present -Risk : reflects the uncertainty involved in implementing the feature -Cost : reflects actual cost of implementing the feature STEP 1 - rank benefits of feature from 1-9 STEP 2 - rank the penalty for each feature from 1-9 STEP 3 - calculate total value and value % STEP 4 - determine relative cost of each feature and cost % STEP 5 - determine relative risk of each feature and calculate risk % STEP 6 - calculate priority of each feature dividing the value % by sum of cost % and risk %

Distributed Agile

DO NOT ASK: is distributed agile better than co-located agile? ASK: is distributed Agile better than distributed waterfall? deliver something of value over a few weeks, and give chance to review and deliver its much superior than traditional development in distributed enviroment when implementing a distributed Agile team environment DECIDE: if you want separate teams divided along functional, or feature lines collaborating across the globe, or teams that are deliberately distributed

DO's and DONT's of a distributed Team

DO's: -Communicate shared vision for the project (not easy across time zones, but it can amplify team's productivity) -Spend time to build trust among the teams and showcase progress of the teams -(If you have budget)Pay for travel among sites and face time among team members (increases understanding and cultural awareness) -Invest money necessary to make available tools for high-bandwidth and lateral communication -Enable team members to communicate w/each other whenever required, including video communication for personal touch -Schedule meetings considering splitting up Scrum rituals to suit the circumstances of the team (plan meetings around time zones, Sprint planning meeting, Sprint reviews and Sprint Retrospectives could be 4 hours OR split into 2 calls on different days w/some work being done offline) DON'T's: -Creating artificial barriers like appointing a single point of contact for communication -Exclude team members from ceremonies by having only 1 or a few representatives attend

Waterfall Approach - Challenges

Dealing with Change -Expensive (ie: if you discover critical design flaw in verification, or if requs change during implementation) -Leads to rework Change if resisted compromises customer collaboration

Sprint Goal

Deliver Working Software -End of each Sprint the team should be able to deliver new released or potentially shippable software -not easy with an existing product with a lot of legacy features -Can be done with appropriate technical practices and mature development processes

Who should be the representative of your team for the Scrum-of-Scrum meetings?

Depends on Team decision They would in turn decide based on who is most informed about the interfaces w/other teams and issues that are likely to be discussed at a particular meeting.

Test Strategies

Design tests carefully, and then test early, Test Often -Common fallacy is to rely too heavily on the test done at the interface system -Many teams even Select automated testing tools based on the capacity to support the GUI of the system being built

Attributes of Scrum Team

Desirable characteristics: -Small and nimble (no less than 3, no larger than 9) improves productivity, removes "Social Loafing" -Self-sufficient and cross-functional (ie: if need user interface development skills, daatbase and service expertise, all skills must be present on the team) generalizing specialists, Scrum favors features teams over component teams -Autonomous and Self-organizing (teams choose for themselves how they are going to organize and meet goals of PO) team decided w/PO about product direction and Pros/Cons

Rolling Wave Planning

Detail story planning for the near-term in tandem; high level planning for future stories -Relatively short planning concept b/c Agile projects are relatively uncertain and changing

Separate exceptions or cross-cutting concerns (Example)

Develop the main path first, then develop exception paths -Defer other considerations, like access restrictions, logging, air handling, concurrent users and performance tuning

Correctness

Did the team develop the code correctly?

Acceptance

Does the code meet the success criteria?

Split across data boundaries (EXAMPLE)

Enter balance sheet data: -In large org. data can be easily translated into 100's of data items aggregated at different levels -Start by having a story for entering Just a summary information -Then use a subsequent use our story used to create the functionality to enter additional data at a more granular level

Scaling in Scrum

Even if multiple teams only 1 Product Backlog

After deciding to continue w/daily integration process giving highest priority to fixing any issues. It helped but was time consuming tasked and reduce velocity. There were issues due to differing design approaches and assumptions made by teams in isolation. What is best way to resolve this?

Form a virtual team of developers drawn from different teams to ensure clearly defined interfaces and attend to integration issues promptly. We can ensure the issues will be addressed in timely manner either by force or intense negotiations.

Which of the following organizational factors is most detrimental to the adoption of Agile?

Geographical Spread: In the context of Agile adoption, the geographical spread is the most unsuitable for Agile adoption. Responsiveness to customer needs is helped by Agile, Complexity of projects and technically capable teams are also in favor of Agile.

Product Roadmap

Helps to define sequence in the time frame for Releases

Split along Operation Boundaries (Example)

If a travel agent wants to be able to manage reservations, this could be split into stories like: - making, canceling and modifying reservations -for data related operations it could be termed as CRUD Operations 1.Create 2. Retrieve 3. Update 4. Delete

Splitting Stories

If user story is too large: -Disaggregation : larger user story divided into smaller ones 1. Split across data boundaries 2. Split along operation boundaries 3. Separate exceptions or cross- cutting concerns

Sprint

Iteration in Scrum -Sprint duration: determined by Team during project initiation (usually 2-4 weeks) -Agile projects favor shorter duration sprints -Scrum Master: must coach and mentor Team so it can reduce waste, irregularities and over use to make sprint shorter -Sprint will end at duration time whether team has met goals or not -Begins with Sprint planning Meeting and end with Sprint Retrospective

Culture Sensitivity

In distributed team be aware and Avoid being... -Ethnocentric: the tendency to believe one's culture is superior to others -Work to diminish its consequences -Learn and respect other cultures

Organizational Related Factors

Influence Usability of Agile -Maturity of organization and ability to collaborate among teams and stakeholders -The org and customer must be willing to support incremental and iterative methods, and team must be willing to try it

Organizational Factors: Human Resources

Interface w/Human Resource department plays an important role in Scrum transition -Change titles to reflect roles (ie: SM should not have reporting authority over team, not report from Product Owner) : EXAMPLE- Project Manager = SCRUM Master, Analyst = Product Manager -Performance Evaluation Process : might have been recog individual brilliance, and now team work related factors reflected in job descriptions and scorecards so team members to pull weight , and assisting others valued more in valuation process -Increasing Review Frequency : including input from broader range of stakeholders and Not just line manager ... EXAMPLE: PO might say how well a team member is able to demonstrate a feature, a Scrum Master emphasizes team work by each indiv

Physical Progress Chart

Kanban/task board features: -Uses columns to represent the development process steps {To Do, Doing, Done} -Referred to as value chain, where each link in the value chain is a column or step in the development process -Just in Time/Pull vs Push approach -As capacity becomes available in the column, items are pulled from Left to Right -Items are user stories or tasks (depending on whats being tracked) -colors of cards/post it notes are representative of type of user stories or tasks being tracked) -An information radiator -Effective in assisting stakeholders and team members in understanding current status of a Sprint or Release

Lean

Lean Software Development def: -Think big -Act Small -Fail fast -Learn rapidly

Patterns of Agile Adoption

MOST IMPORTANT POINT: whether we should start SMALL (pick a few projects) to pile it before expanding OR whether we should do a full blown ALL IN type of transition

Scrum of Scrums

Mechanism established to coordinate the work of multiple teams working on the same project (may be scaled up recursively with a Srcum of Scrum Scrums, or Scrum of Scrum Scrum Scrums) -Attended by reps of each Team (usually member of dev team) -Not a daily meeting, once every 3 days -Purpose is to solve problems requiring collaborative effort across multiple teams (agenda is to have each attendee provide quick update of what has happened since last meeting, and accomplishments to do b4 next meeting) -Focus on teams to discuss their problems which require (maintain issues backlog for these meetings)

Overcoming Individual Resistance

Mike Cohn: How they Resist and Why they Resist -Active -Passive 1.)Diehards: Active/Like Status quo TL - they dont believe in the method, they have been confronted with data proves opposite of achieving results due to status quo, address their fears, and why they dont want to be apart of existing approach, basically waiting it out until new efforts or fad 2.)Saboteurs: Active/Dont like Scrum TR - those that actively oppose transition, they will need to be dealt by reinforcing the organization is committed to change, provide data of success stories, etc... cannot wait forever for them to come around b/c over time they will sabotage efforts, eventually may need to remove from project/company 3.) Followers: Passive/Like status quo BL - 4.)Skeptics: Passive/Dont like Scrum BR- adopted Scrum but did so b/c they had no choice, over time provide with data references or actively encourage them , hear them out, build awareness

Planning Onion

Multiple Levels of Planning: HIGHEST - Vision or Strategy Level -Business Goals and Strategic Direction of company (things decided by executive leadership of org.) 2ND LEVEL - Roadmap -Planning that takes the strategic or vision level strategies of company and creates product roadmaps in order to support and implement those strategies 3RD Level - Release Level Planning - Considers deliverables and features required for each release that in turn support the Product Roadmap 4TH LEVEL - Sprint Planning - Considers the tasks that need to be completed in order to transform a User Story into working tested Software (takes place at Sprint Planning meeting) 5TH LEVEL - Daily Planning -Consists of Daily Scrum and actual work activities

Cancellation of Sprint

PO determines whether to cancel or not -if significant changes in priorities -or mid course correction made render sprint backlog invalid

The Sprint backlog was rendered useless due to a major change

PO should consider cancelling the Sprint b/c entire work would be wasteful

The PO wanted to add high priority item to the Sprint backlog

PO should wait ti the next Sprint to make change

The PO felt one of the Sprint Backlog items was no longer needed

PO should wait umitl next Sprint to make change

Agile Project Management Tooling

PROJECT MANAGEMENT TOOLS requs: -Capture Product Backlog (inclu. creating epics, User Stories, acceptance criteria etc) -Maintain heirarchy of stories (namely themes, epics, stories, substories, tasks, etc) -Create releases and sprints w/specific time durations and assign assign user stories to those time boxed events -Facilitate ability to assign tasks to team members allowing them to capture task related data -Create virtual information radiators (like burn down charts, burn up charts, kanban charts etc) TOOLS: Simple - Microsoft Office Robust open source agile mgmt tools

User

Persona: -Used to identify use cases and related user stories -Imaginary representation of a typical user -Used to identify use cases and then user stories

The Scaled Agile Framework looks at different levels of scale, Team, Program and _______?

Portfolio: Scaled Agile Framework looks at the scaling issue from the perspective of the Team, the Program, and the Portfolio, the last being the strategic perspective.

Planning Poker

Quick fun way to estimate that brings whole team together 1. Select Team involved (ideally also doing work) 2. Give a deck of cards w/Fibonacci scale to each member 3. PO - reads story, explains it, and answers the team's query 4. Team - discusses each story, then after discussion each team member holds up the card reflecting the user story size (if outlyers then team discusses why team member is so different) 5. Process continues until team agrees on consensus of size www.planningpoker.com

Tasks for Scrum Master

Responsibilities of SM: - Be servant leader; put team before themselves and assist the team (ie: set up/ensure Scrum ceremonies are carried out) -Ensure smooth flow of info; w/in and outside team, collaboration, spirit of shared decision making -Should be problem solvers (remove impediments) -Protect the the team and be peacemaker (by encouraging parties to face issues and resolve quickly) -Be the process coach of the team and ensure Agile principles are followed

Agile Software Engineering Tooling

SOFTWARE ENGINEERING TOOLS requs: -Test automation tools and framework -Tools related to building automation -Continuous integration -Tools that assist w/maintaining software hygiene (static code analyzers, unit test frameworks, etc) Its better to spend more time selecting software engineering tools b/c they will allow for a multiplier effect on teams productivity

Scaled Agile Framework (SAFe)

Scaled Agile combines iterative and incremental techniques of working with Lean and Kanban principles to create a compelling process framework scaledagileframework.com Levels of Scale: 1. TEAM - Solutions are developed iteratively and aligned w/release focusing on quality 2. PROGRAM LEVEL: Epics are achieved by creating agile release trains combining the teams' output 3. PORTFOLIO LEVEL: Multiple release trains aligned with the objectives in portfolio vision

A project Manager in an organization wants to try Scrum. What is most important to ensure success of the pilot?

Set reasonable expectations b/c at this moment only the project manager is interested.

Who is most likely to succeed in fostering Team responsibility?

Someone who is willing to help out others when he is done with his tasks -team work is fostered by enabling team collaboration, helping each other, and sharing the learning.

Burn Up Chart

Staying in control -Tracks the project's progress -Vertical assess : story points -Horizontal Access : Sprints -similar in making forecast like Earn Value Management -Blue line : expected completion rate -Red line : Actual completion rate -Red Dotted Line : area at the end of the planned number of Sprints

Ideal Time vs Story Points

Story Point Estimation: 1. difficult to explain outside the team 2. Greater chance of converging estimates 3. Low time for estimation 4. Estimates are not comparable across Teams 5. Helps drive cross functional behavior 6. Story Point estimates never decay Ideal Time Estimates: 1. Easier to explain outside the Team 2. Converted estimates will differ across teams b/c converted into elapse times 3. Easier to estimate at the projects initial stage 4. Helpful in understanding the wasted time 5. Takes more time

Estimation

Successful planning depends on proper estimation of stories -Estimation as a process often viewed w/suspicion and trepidation

Complaints Expectation Management

TEAM- CONS:time spent in meetings, planning and reviews / retrospectives PROS: you are now an insider and have a say with what goes on within the team, better than having someone onsite for you, and waiting to hear anything about what you delivered, over time they will learn to manage meetings better and get more done with time TESTERS- CONS: testing intermediate unfinished stuff, even if not delivering anything at end of Sprint PROS: the potential releasable product should be developed at the end of the Sprint, it will build quality and prevent mad rush at end when discovering issues too late STAR PERFORMERS - CONS: worrying about focus shifting from them and onto TEAM PROS: OLD SCHOOL - CONS: Little documentation is produced and system failure effects PROS: CUSTOMERS - CONS: Why so much time spent explaining requirements, providing feedback, discussing approaches, watching demos and giving feedback PROS:

Organizational Factors with HR: Career Path

The Career path defining process should be Scrum friendly - Career path for SCRUM Master: Handle challenging projects, join a Scrum Master center for excellence etc.

The team reported that they were way behind schedule in the Sprint

The team should request the PO to re-prioritize Sprint backlog

Demands on Product Owner and Scrum Master

This is how the Team's requs of time from the Product Owner and Scrum Master evolves over time in "Succeeing with Agile" by Mike Cohn -As the team becomes more mature, able to resolve impediments on their own, and rely less on the Scrum Master -As productivity improves, the y ill have greater need of PO, as they try new ways pf implementing features, ask more quality ?'s, and provide more input of project's direction

Burndown Bar Chart

Tracking Sprint Progress -vertical axis is sum of tasks remaining expressed in Ideal hours -horizontal axis, sprint timeline expressed in days -blue line amount of ideal tasks remaining -orange line actual tasks remaining -Burndown chart is info radiator that would have to be updated daily

Which of the following should be primary focus of testing on a large, complex Agile project?

Unit Test: Should compromise 80-90% of total tests written in a system

Value Based Prioritzation

User Stories are classified as a. High Risk High Value (first) we deliver high value to customer & we are also derisking the project early b. Low Risk High Value (2nd) c. Low Risk Low Value (last) d. High Risk Low Value (not done)

Kano Model (Prioritization)

User Stories are classified into 4 categories a. Threshold/must haves (features that must be present in order for product to be successful) b. Linear/performance requs (stories that help gain customer satisfaction by fulfilling more of stated requs, and improve customer satisfaction linearly) c. Exciters and Delighters (features that are not required to make product viable but increase customer satisfaction, could be Value-Add Items or included in premium version of product) d. Indifferent (the features least important to customer and add no business value)

Requirement

User stories aka: requirements, features, or function User Stories: -Customer describes functional requs -Development team describes non-functional requs -deals w/risks and defects

Determine a Value or ROI

User stories in product backlog need to be prioritized based on customer value considerations

Template

User story description in meta language format: As a <role>, I want <goal/desire/feature>, so that <benefit> Followed by bulleted list of points: -Reference list -Acceptance list

Different Forms of Waste

Waste can constitute up to 90% of a process -Over production (looks like extra features) -Excess inventory (partially completed work) -Unnecessary Processing (looks like extra processes) -Unnecessary Movement of goods (looks like task switching) -Unnecessary Movement of People (endlessly splitting resources across teams) -Waiting times -Defects

Waterfall Approach - Effective

When projects want to migrate features or products from one platform to another -Both the problem and solution must be clear

4 Considerations Regarding Value or ROI

Work provides value by: 1. New Revenue - ROI from new customers 2. Retained Revenue - Retaining customers who would otherwise leave the product or service 3, Incremental Revenue - Customers buying new or additional products or services 4. Operational Efficiency - Reducing the cost of operations or improving its efficiency of operations in order to increase earnings

Evolution of Different Team Roles

Work to Acquire new knowledge and Skills -Project Manager + Scrum Master: Abandon top down approach and Embrace servant Leadership and learn about Scrum and serve the Team -Architect/UED/Tester + Programmer: Need to give up dedicated silo-specialist roles and become generalizing specialists. Participate in technical architecture development and collaborate w/developers to achieve goals -Analyst/Product Manager + Product Owner: Work w/out hindering team's empowerment and autonomy. Focus on "WHAT" and leave "HOW" to the team

Extreme Programming (XP)

XP objectives: -Respond to high cost of changing requs -Establish strong, robust engineering practices **EX: if testing is good, lets perform all types of tests (unit testing, integration testing, and acceptance testing) If design is good lets do design all the time ( and retrospectives at the end of each iteration) If simplicity is good, lets do the simplest possible thing (eliminate anything that does not add value) If review is good , lets perform reviews (continuously improve by making sure we do reviews and retrospectives at the end of each iteration) If communication is good, lets encourage communication (make sure our team space/tools encourage face to face and osmotic communication) If using short iterations is good, lets perform shortest possible iteration (get regular stakeholder feedback in order to improve the quality of our software and make sure we are delivering the value costumer wants by doing shortest possible iterations)

MoSCoW prioritization

items in backlog are prioritized where: -Must - must haves -Should - highly desirable -Could - nice to have -Won't - do not add value software will not be developed

Progressive Elaboration

the process of describing User Stories in increasing detail as they rise in priority