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.
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:
- 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!
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
For more on Kanban, please read Altassian on Kanban .
Lesson 4: Scrum
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:
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.
- 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
- 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.
Large body of work that can be broken down into a number of smaller stories.
Small body of work (modules)/ Actionable item which is a part of epic.
Decomposed parts of a story that address how the story will be completed.
- 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.
- What you worked on yesterday?
- What are you planning to work on today?
- Any Blockers/Concerns?
- A 20-minute Zoom Conference every week by Scrum-master to discuss about project.
- 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)
- 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.
- 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
|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