Skip to content

Instantly share code, notes, and snippets.

@apetro

apetro/abstract.md

Last active February 15, 2016 15:13
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save apetro/3ccaf7e13ff67cf38798 to your computer and use it in GitHub Desktop.
Save apetro/3ccaf7e13ff67cf38798 to your computer and use it in GitHub Desktop.
Download ZIP
2016-02-15 MyUW Scrum talk
Raw
abstract.md

Abstract

Andrew Petro will share an introduction to Scrum (an agile method) as practiced by the MyUW Infrastructure team, emphasizing project management and product management (rather than development) aspects.

Attendees will gain context on this ongoing Scrum team, opening opportunities to apply this approach to other projects. This talk is at a “survey” level, that is, enough to whet your appetite for a subsequent conversation.

If you come away knowing about some people using Scrum and knowing some useful artifacts, along with answers on follow up questions, that’s success!

Structure: 30 minutes survey of Scrum; 20 minutes discussion.

  • Scale and structure of MyUW (why Scrum is an appropriate fit)
  • Strategic tools for product management (principles, roadmap, card sorting)
  • Tactical tools for product management (product backlog, user testing, feedback)
  • Scrum meetings and interactions for project management
  • Relationship between Scrum team and MyUW service team
  • Process whereby change migrates toward and into production
Raw
outline.md

What is agile?

Big picture

  • The way to figure out how to solve a problem is to solve the problem.
  • Short iterations
  • Potentially shippable software every iteration

Waterfall, planning, and BDUF come from a good place

What do we all want?

Software development is really, really expensive.

Building the wrong thing is sad. Building the right thing too late is sad.

So what are you going to do?

Lots and lots of analysis and planning and Gantt charts... Go slower! Be more careful!

Well, what if we didn't do that...

No seriously, what if we didn't do that?

Just not planning isn't going to be okay, right? So. What do we have to do to make it okay?

  • Priorities
  • Focus
  • Quick feedback
  • Potentially shippable. Not necessarily shipped.

Everyone remember calculus? And micro-econ?

Let's talk about cost

Here's what your project cost looks like.

Under waterfall.

Under agile.

Let's talk about value

Under waterfall.

Under agile.

Agile is about increasing the area under the curve by starting the curve sooner.

Let's talk about diminishing marginal returns

And let's compare marginal returns to marginal costs.

What is Scrum?

  • A specific recipe for practicing agile

Scale and structure of MyUW team

4.75 technologists:

  • 3 full-stack (project-dedicated, staffed from PCS)
  • 1 front-end (staffed from ADI)
  • 0.75 UX (staffed from DoIT Communications)

1 product backlog manager

1 strategic consultant

product manager / service team lead (CAS)

  • (not dedicated)

~5 technologists are expensive

Scrum is an agile framework for focusing and coordinating these efforts.

Strategic tools for product management

Principles

Card sorting

Roadmap

Design sprints

Tactical tools for product management

Product backlog

User testing

Feedback

Scrum meetings

Once you have ~5 technologists, Scrum is justified.

  • Prioritizes and plans efforts
  • orchestrates the iterations
  • brokers communication and coordination within-sprint

Grooming

Sprint planning

Daily standup

Sprint review

Retrospective

How change migrates to production

localhost -> predev --> test --> qa --> production

Infrastructure developers do their development locally, collaborating via Git. (Git is transformative. You should git. But that's not this talk.)

Continuous integration takes change that is accepted, merged via Git, and builds it, deploys it to "predev", that is, the infrastructure tier before other developers get their hands on it.

From time to time versions that look pretty good are tagged and promoted to test, where developers on other teams work.

Tags may (or may not) promote from there to QA and then to production.

Roughly, predev is bleeding edge infrastructure with stable apps, whereas test is bleeding edge apps with stable infrastructure, QA is stable both, and prod is stable both that looked good in QA.

We can accelerate this, but roughly we tag once per two-week sprint, and change takes roughly two weeks to migrate through the tiers.

master is intended to be continually potentially shippable. Reality varies.

Relationship between Scrum team and service team

Scrum team is dedicated, focused effort.

Service team is cross-functional, arms reaching out into the organization.

  • Security
  • Communications
  • ADI, MUMAA
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment