Goals

• Produce a potentially consumable solution
• Address changing stakeholder needs
• Move closer to a deployable release
• Maintain or improve upon existing levels of quality
• Prove architecture early

• Fulfill the project mission
• Grow team member skills
• Enhance existing infrastructure
• Improve team process and environment
• Leverage existing infrastructure
• Address risks

Construction Iteration Overview

Scrum Process Overview

Artifacts & Terms

• Product Backlog
• Product Backlog Item (PBI)
• Sprint Backlog
• Epic, Feature, PBI, Task, (Bug)

Essential Meetings

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
• Backlog Refinement

2-week Sprint

Iteration Planning

Decide on and plan the work necessary to successfully construct an increment of the project

Who:

Team + Product Owner

When:

Before Sprint begins

Why:

To negotiate which PBI's to include in the Sprint and to do JIT planning for their implementation

Facilitated by:

Scrum Master

How long?

Timeboxed

Sprint Planning Meeting

Summary: Scrum Reference Card

Sprint Planning using DevOps

DAD Version

• Plan team availability
• Select a work item
• Elicit work item details
• Model a potential solution
• Decompose work item into tasks
• Sign up for tasks
• Update estimate
• Sanity check of planned work
• Obtain commitment to the planned work

Backlog Refinement

Prepare the Backlog for the upcoming Sprint

• Large vague items are split and clarified (both in the business and technical sense)
• Goal: identify "thin vertical slices" of work that still have business value
• Goal: identify rigorous definition of done that includes testing

Daily Scrum and Typical Day

• 15 minute max standup meeting
• Sprint Backlog and Task List
• Sprint Burndown Chart

"The majority of the day is spent collaborating together to evolve the solution, and ideally the day ends with a stable build that is potentially consumable by others."

Sprint Task List

DevOps Task board

Scrum and XP from the Trenches

Sprint Burndown Chart

DevOps Sprint burndown

Building a Solution

Avoid Technical Debt

"Technical debt is the accumulation of defects, quality issues (such as difficult to read code or low data quality), poor architecture, and poor design in existing solutions." (p. 322)

Technical Debt Quadrant

Build High Quality Solutions

1. Test-driven development (TDD)
2. Test after development
3. Code now, fix later

Use processes that prevent defects rather than relying on those that try to find them

Validate the Integrated Solution

• Acceptance test-driven development (ATDD)
• Continuous integration
• UI testing
• Integration testing
• ...
• Testing is the focus of CS 462, so more later

Configuration Management

"Configuration management (CM) is the discipline of identifying the configuration of a system at distinct points in time for the purpose of systematically controlling changes to the configuration and maintaining the integrity and traceability of the configuration throughout the system life cycle. -SWEBOK"

SWEBOK, Chapter 6

Some Important Features

• Management of access and changes to code by multiple teams and actors
• Versioning, baselining, history, tracking, cataloging, tagging, documenting
• Developer "sandboxes", branching and merging
• Handle ALL work products: requirements, tests, data, database configuration, management plans, documentation, ...

• Auditing, Reporting, Metrics and Analysis
• Defect tracking
• Build and release management, automation
• Reporting

What are we doing right?

What are we not doing right?

One hint: what are our Change Management processes and tools?

Continuous [Testing | Integration | Deployment]

What

"CI is the practice of regularly integrating and testing your solution to incorporate changes made to its definition. Such changes include updating the source code, changing a database schema, or updating a configuration file. Ideally, when one or more changes are checked into your configuration management system the solution should be rebuilt, retested, and any code or schema analysis performed on it." -DAD

Figure 15.10 DAD

Source: Markos Rendell

Why?

Continuous Deployment (CD)

"With [CD], every change that passes all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed test will prevent a new change to be deployed to production. Continuous deployment is an excellent way to accelerate the feedback loop with your customers and take pressure off the team as there isn't a Release Day anymore. Developers can focus on building software, and they see their work go live minutes after they've finished working on it."

CI vs. CD (Atlassian)

"By regularly deploying into more complex environments -- to your project integration environment from your individual environment, from your project environment to your demo or independent testing environments -- you put yourself in a position to receive more meaningful feedback. CD requires you to have the discipline to have multiple environments, to work with people external to your team (such as stakeholders and independent testers), and to seek and act on their feedback."

DAD -- Ch. 21

Figure 15.11 DAD

Sprint Review

Who:

Team + Product Owner + Stakeholders + end users + ...

When:

At conclusion of Sprint

Why:

To demonstrate all the features constructed during this iteration

Facilitated by:

Product Owner

How long?

Timeboxed, perhaps 1 hour

• Live demo of working, tested product increment
• Identify all items done
• Send items not done back to the Product Backlog
• Elicit stakeholder feedback, new items, priorities
• Demonstrate value that meets expectations, not code (you're showing a finished room, not wiring and plumbing)

Sprint Retrospective

Who:

Only the Team!

When:

At conclusion of every iteration

Why:

To reflect on the process and improve it for future iterations

Facilitated by:

Scrum Master

How long?

Short

• Consider starting with a Safety Check to gauge the safety of the participants
• Do something to improve the safety or carry on if it's good
• Encourage everyone to express themselves
• What went well?
• What went wrong?
• What could we do differently to improve?
• No blaming. Keep it positive & constructive
• Scrum Master condenses it into action items that everyone agrees/votes to implement or support

Prime Directive of Retrospectives

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." --Norm Kerth, Project Retrospectives: A Handbook for Team Review

Safety Check

1. I'll smile, claim everything is great and agree with everyone else
2. I'm not going to say much, I'll let others bring up issues
3. I'll talk about some things, but I don't want to talk about other things
4. I'll talk about almost anything; a few things might be hard though
5. No problem, I'm comfortable talking about anything

Use sticky notes anonymously then plot in a histogram.

• Safety is HIGH : we should be able to talk about many issues and make progress with retrospective activities
• Safety is MEDIUM: some folks do not feel comfortable talking about some issues; we'll have to take this in mind for how we conduct this meeting. We'll try some activites that may help, or be careful with some topics.
• Safety is LOW: this meeting will likely not be very effective; instead we'll work on some activites to try to increase the safety level.

Ideas

• Team Playbook
• Effective Sprint Retrospectives
• Agile Retrospective Resource Wiki

Observations

Healthy Construction Patterns

• The team can be reliably depended on to demonstrate increments of software at the end of each iteration
• Team members finish their tasks ahead of schedule and ask to help others with their tasks
• Iteration (Sprint) dates never move
• Any stakeholder can walk into the common work area and request to see a demonstration of the working software as it currently sits

Construction Anti-Patterns

• A work item list (Sprint Backlog) that is too big to easily manage and comprehend
• Inattention to risk mitigation
• Assuming that the architecture will work without proving it with code
• Assuming that an iterative approach alone ensures that you will build the right solution in an effective manner
• One or more of your team members are working on other projects in addition to yours

Anti-Patterns con't

• A work item isn't done (during the Sprint)
• Last iteration we planned for X points but delivered Y
• During the iteration we missed some tasks when iteration planning
• During the iteration we realized we missed a requirement that another depends on
• During iteration planning sessions, the product owner is trying to decide whether new items should be added to the work item list, or be reprioritized
• Defect counts are increasing in each iteration

CS 461/2 Anti-Patterns

• Failure to plan for the Sprint
• Not understanding work committed to
• Team members "disappear" for 1 or more days
• Team members delay work until the end of the Sprint
• Interpersonal conflicts
• Team members unwilling to do difficult work
• Team members unable to do difficult work
• Team members drop the class → groups reformed