Workflow

Lesson 1: The Theory of Constraints and the Seven Wastes

The theory of constraints, developed by Dr. Eliyahu Goldratt, teaches us that, in optimizing any production process, we must focus only on the constraint, or the step in the process that is the bottleneck. We must pace all other work to match the speed of the bottleneck, and any efforts we make at improvements must be directed to the bottleneck.

Read more on the theory of constraints.

The Seven Wastes

A key source of Software Engineering ideas is the Toyota Production System. In particular, the people at Toyota thinking deeply about production identified seven wastes that should be eliminated in any production process:

  1. Overproduction: Don't produce more than the customers need at present! Such overproduction may never prove useful. The system you are building might possibly come to include, say, the ability to feed the data it produces to a neural network. But is any customer asking for this? No? Then wait until they are asking to produce it!
  2. Inventory: Do not pile up partially done work. The aim of production is to deliver finished work to the customer. Partially done work is continually at risk of being rendered otiose by changes in circumstance. Furthermore, all partially done work is a constant drain on the scarce attention of the workers involved: a worker with one partially finished task can focus on that task. A worker with ten partially finished tasks will wind up "thrashing" between those tasks.
  3. Waiting: Avoid having people (or products) lying idle waiting for someone else to finish some work. If each work station along the way in some process works in small batches, that minimizes the amount of waiting likely to occur at other work stations.
  4. Motion: A production process should minimize the movement of producers and products: for example, don't make programmers fork a repo, work on it, and submit a pull request, if you can trust them to contribute directly to the repo.
  5. Transportation: If a programmer can directly ask the end user if their work is OK, don't instead make them go through approval by the project manager, the CIO, the user's manager, and the user's nanny, to see if they can release it.
  6. Rework: Get the work right the first time! A key to this is to work in small batches. Trying to make five major changes to a system all at once, in order to "save time", is only likely to result in amounts of subsequent rework that will more than wipe out the supposed "time savings" of the all-at-once approach.
  7. Overprocessing: The waste of doing things the customer does not need to have done, for instance, building high-level security into an app that no is trying to hack into.
Lesson 2: Work in Small Batches

An essential part of the Toyota Production System was to work in small batches. That allowed Toyota to respond rapidly to changing customer demand, because it did not have huge inventory backlogs it had to get rid of before changing course. Eric Ries, entrepreneur, tech executive, and coder, writes:

It turns out that there are tremendous benefits from working with a batch size radically smaller than traditional practice suggests. In my experience, a few hours of coding is enough to produce a viable batch and is worth checking in and deploying.

My experience completely agrees with Eric's: I often check in code, and deploy it into production, once an hour. Why are small batches so important? Let's look at the reasons Eric lists:

  • Small batches mean faster feedback.
  • Small batches mean problems are instantly localized.
  • Small batches reduce risk.
  • Small batches reduce overhead.

But please read Eric's full article! This is a very experienced developer, telling us our batch size should be radically smaller than most people believe.

Lesson 3: Kanban

The key points to understanding Kanban:

  • Kanban serves to make work visible.
  • Kanban acts to limit work-in-progress (WIP).
  • Kanban is a pull system.
  • Kanban enables us to visualize workflow.
  • Kanban allows us to see work bottlenecks.
  • Simply having a card system is not Kanban: card systems may not support one or more of the properties of Kanban.
Why limit work-in-progress?

For more on Kanban, please read Altassian on Kanban .

Lesson 4: Scrum
"I'd like to institute an organizational system called scrum."
Copyright: Scrum.org/medium.com

Scrum is a method of managing software development where a team divides its work into sprints of roughly a couple of weeks, during which progress is evaluated in a daily stand-up meeting called a daily scrum. Here is the Wikipedia article on scrum.

The Scrum Framework below is implemented in the Online DevOps project for Fall 2018:

Scrum Roles

Product Owner

Prof. Eugene Callahan / Akshay Tambe

  • Build and manage the product backlog.
  • Ensure the team to everyone understands the work items in the product backlog.
  • Give the team clear guidance on which features to deliver next.
  • Decide when to deliver the product.

Scrum Master

Akshay Tambe

  • Works as a facilitator-in-chief.
  • Schedule the needed resources (both human and logistical) for sprint planning, stand-up, sprint review, and the sprint retrospective.

The Scrum Team

Denis Petelin / Shawn Widjaja / Jeff Cui / Mandy Kong / Felix Angel Baez

  • Drives the plan for each sprint (Implementation).
  • Forecast how much work they believe they can complete over the iteration using their historical velocity as a guide.
  • Updates and shows concerns to the Scrum-master frequently about the work progress.

Keeping the iteration length fixed gives the development team important feedback on their estimation and delivery process, which in turn makes their forecasts increasingly accurate over time.

Components of Scrum

Sprint planning

  • A team planning meeting that determines what to complete in the coming sprint.
  • In our process, the normal Sprint will run for 2 weeks.
  • An estimated 5-6 sprint iterations will follow after our 1st sprint.
  • The Scrum Team estimates Stories to commit in an Epic.
  • The Scrum Team also calculates Story points for each story.

Epic

Large body of work that can be broken down into a number of smaller stories.

Story

Small body of work (modules)/ Actionable item which is a part of epic.

Task

Decomposed parts of a story that address how the story will be completed.


Daily Stand-up

  • Also known as a daily scrum, a 15-minute mini-meeting for the software team to sync.
  • As this is an Online Course, students are required to give updates everyday on Slack.

Sample Format:

  • What you worked on yesterday?
  • What are you planning to work on today?
  • Any Blockers/Concerns?

Weekly Stand-up

  • A 20-minute Zoom Conference every week by Scrum-master to discuss about project.

Sprint Demo

  • A sharing meeting where the team shows what they've shipped in that sprint.
  • This meeting will occur mostly on before Sprint Ends. (10-minute working demo by Scrum Team)

Sprint Retrospective

  • A review of what did and didn't go well with actions to make the next sprint better.
  • Happens on last day of Sprint or during the planning of next Sprint.

Sample Format:

  • What went well?
  • What went wrong?
  • How can we do better in next Sprint?

Estimation of LOE in JIRA Tickets

Story Point Estimation

  • Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.

Fibonacci Series Format to estimate LOE:
1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144…

Mostly used Story Points:
0 → Story is not counted in Velocity/Capacity
1 → Can be done within a day
2 → Can be done within 2 days
3 → Can be done within 3 days
5 → Can be done within a week
8 → Requires more than a week
13 → Requires complete iteration

Sprint Iterations in DevOps Coursework

*** Estimated Cycles, may vary over the coursework


Sprint Cycle: 2 Weeks
*** Exception: Sprint 1
*** Might Cut-off 1 Sprint due to Mid-Season Holidays

Iteration # Period
Sprint #1 (Short) 10th September - 18th September (1 day extension)
Sprint #2 19th September - 2nd October
Sprint #3 3rd October - 16th October
Sprint #4 17th October - 30th October
Sprint #5 31st October - 13th November
Sprint #6 14th November - 27th November
Sprint #7 28th November - 11th December
Sprint #8 12th November - 25th December

SCRUM Documentation: Sprint Planning for Fall 2018

Other Readings
Quiz

    Having to much work in progress is likely to lead a knowledge worker (like a programmer) to...?

    1. "thrash," or move from task to task without getting anything done
    2. "crash": have to take many days off
    3. "smash": want to destroy the kanban board
    4. get a promotion
    5. become a better engineer

    The theory of constraints works...?

    1. only for manufacturing plants
    2. only in rare cases
    3. in service industries as well as manufacturing
    4. only in agriculture

    To eliminate the waste of over-production, we should...?

    1. build all things we think the customer might want in advance
    2. stop have meetings
    3. only build an MVP at first, and then see what more is needed
    4. avoid having any inventory

    In scrum, the product owner has what role?

    1. making all technical decisions
    2. being the voice of the customer
    3. garnering the profits from the release of the product
    4. being the only one allowed to speak at daily scrums

    As opposed to Toyota, American car manufacturers often used a _____ system of production.

    1. scrum
    2. push
    3. pull
    4. waterfall

    The small batch principle of faster feedback would recommend what practice?

    1. only show your work to the customer once you are sure it is completely correct
    2. show early work stages to your team members, but never outside the team
    3. make your work visible as early and as often as possible
    4. none of the above

    Working in small batches, per our article, means releasing work...?

    1. every few years
    2. every few hours
    3. every few months
    4. every few weeks

    A good approach to preventing the waste of re-work would be...?

    1. punish all errors severely
    2. add tests right from the moment you start coding
    3. have an extensive QA process once you have completed all programming
    4. have a form so that users can report bugs

    By limiting work-in-progress, kanban helps to eliminate the waste of...?

    1. nonsense
    2. inventory
    3. rework
    4. transportation

    Transportation waste of production prevents programmers from...?

    1. accessing development tools in a timely manner
    2. directly communicating with the customers
    3. getting to the office
    4. shipping the software to the operations team