Blood, Sweat, and Pixels, ch. 4: Diablo III
“After a decade of turbulent development, Diablo III had finally gone live, but nobody could play it” (87)
"”I remember being in the meetings leading up to that, people saying Are we really ready for this? OK, let’s double the predictions let’s triple the predictions.’ And even those ended up being super conservative”” (88)
“Diablo II was widely considered one of the best games ever made. Now, in May 2012, the rocky launch of Diablo III had associated the Blizzard logo with something that the company had never experienced: public failure” (90)
“How could Blizzard make the endgame as addictive as it had been in Diablo II, where players spent hours and hours fighting through demons and hunting for gear even after they’d already finished the story?” (92)
“If you didn’t want to bash your head against the wall in Inferno mode, you could dish out real money for better gear, which was the exact opposite of what most players wanted to do” (92)
“people were more interested in gaming Diablo III than they were in playing it, a problem that would take serious investment to fix” (93)
“the people who worked on Diablo III some of whom had been on the game for nearly a decade wouldn’t get a break” (94)
"”What makes it really hard is you can build a game, you can test a game, and you can think you know the know the game—until you release it,” said Mosqueira. “Within the first day, probably more people have spent more hours playing the game collectively than [in] the entire development up to that point. So you’re going to see things you never intended. You’re going to see players reacting to things…. They’re playing with it, they’re engaging with it, they’re interacting with it. And really, what makes it hard is learning the discipline and the rigor to know how to react to that”” (97)
“Mosqueira’s theory was this: Diablo III’s issues were a direct result of a development team haunted by the beloved Diablo II” (97)
Kevin Martens: “We shaved the rough edges off randomness. We made randomness work for the player instead of against them” (101)
“Josh Mosqueira and his team realized that the way to keep players happy was to give them the edge” (101)
“In June 2012, over a year after Blizzard had hoped to ship StarCraft II’s first expansion, Heart of the Swarm, [Dustin] Browder spoke to me about the game’s progress. “We are ninety-nine percent done,” he said, “but that last one percent’s a bitch.” Heart of the Swarm wouldn’t come out until March 2013. That last one percent took nearly a year” (105)
"”The thing that makes scheduling challenging is iteration,” said Rob Foote. “You have to allow for iteration if you want to make a great product.” Iteration time was the last one percent. Blizzard’s producers tried to leave blank slates at the end of their schedules so that their development teams could push, tug, and polish every aspect of their game until they felt like they had something perfect” (105)
"”Diablo is best experienced when, as a result of slaying monsters, you get better items that allow you to make your character more powerful,” said Wyatt Cheng. “And if the activity that I do to make my character more powerful does not include killing monsters… then that’s not a good place to be”” ((108))
“It also proved a point that would influence numerous game developers in the years to come, including but not limited to the makers of The Division and Destiny (whom we’ll meet in chapter 8): every game can be fixed” (111)
PsychOdyssey, eps. 10-12
Episode 10: Bittersweet Gravity
James finds his footing with the team and the first Psychonauts 2 mental landscape takes shape. —Episode Description
“Imagine this was great… for the section” —James Marion
“I get the impression that… we don’t want to show this kind of stuff to Tim until it looks like something that will get him excited about the level” —Marion
“We are just about leaving pre-production. We don’t have as much done as I’d like to have done. But that’s kind of always the case. We didn’t have enough programming resources early on during pre-pro, so we are not through as much of the core gameplay as I’d like to be for production. But prioritized all the player moves stuff, so that we’ll be able to build levels properly” —Zak McClendon
“I am pretty inspired by Zak’s breadth of knowledge when it comes to games. It seems like he has played and understands every game in existence. Which I don’t understand. Because I consider myself well-read when it comes to games. But even so, Zak seems to know pretty much everything. I aspire to have that kind of breadth of knowledge as well.” —Marion
“Zak is one of those developers who is really good at having a project focus. He can internalize pretty quickly a lot about what is good and bad about a given style of game, or a given kind of gameplay, and help represent that outwards really, really well” —Ryan Mattson
“it was a lot of fun to make. But then, watching someone else play, and realizing how hard and terrible– I kind of was like: ‘Maybe… oh, shit! I don’t know if I’m good at this or not’” —Jeremy Mitchell
“We are building the railroad as the engine is going down it. We are laying the tracks in front of the engine” —Mattson
Episode 11: Not Doing the Typical
Despite the previous breakthrough, the team struggles to impress Tim, who pushes for even stronger concepts. Meanwhile, Amnesia Fortnight draws near. —Episode Description
“I think the concept was underdeveloped, and so they took the only details they had and they made a whole level out of that. I feel like we should at least provide a rich thing. And then they could have a choice of things to develop” —Tim Schafer
“So, we can’t have scale things. I think I need to axe that. So, the thing is that, the idea that everyone is actually much bigger than Raz, it introduces a technical challenge that we don’t necessarily need… If we don’t absolutely need it, we shouldn’t use it…” —Anna Kipnis
“A lot of the stuff for Psychonauts 1 was done intuitively. And it was also thrown away in production, like, seven times. We are trying to avoid that by doing more of this work upfront … We are trying to figure out how to articulate what makes some ideas good and some ideas bad. And we are figuring that process out together” —McClendon
Episode 12: Amnesia Fortnight
It’s time for Amnesia Fortnight, a two-week game jam meant to invigorate the studio. —Episode Description
“everybody in the office has an idea” —Schafer
“creativity is this endless process you should do every day of your life. I just figured out that Amnesia Fortnight is the best thing ever by saying that out loud” —Schafer
“I don’t think it would be as interesting of a concept to prototype if we knew it was going to work” —Devin Kelly-Sneed
“Sometimes you don’t figure it out. You can’t just rely on, like: ‘Oh, you know, well, everything just comes together at the last minute.’ It’s like: ‘Well, no, sometimes it doesn’t come together at the last minute’” —McClendon
“It’s crazy! It’s really, really, really hard to scope. You can know that you have two weeks and have a sense of what it means to simplify, but… this is the part where my inexperience is catching up to me” —Asif Siddiky
“It’s interesting what you end up with when you just… get a bunch of dudes with different skillsets together and put a time pressure on them. You don’t have time to nitpick anything. You just have to kind of go with what you come up with. And hopefully it’s cool, and… You know, luckily, here it is” —Gabe Cinquepalmi
“Generally you don’t want to– You don’t want to crunch, right? It’s a little different when it’s AF and it’s over a really short period of time. Overall, crunch doesn’t make for a better product” —Kee Chi
“Man, we made a video game, you guys!” —Chi
“I don’t really know… how to feel about… not working on this anymore. And going back to not working on a game. It’s a good thing and a bad thing. Because this is also extremely stressful. I don’t know how people manage it over longer periods of time with other people’s money at stake” —Siddiky
Essential Kanban Condensed
Foreword
“Kanban is a method that shows us how our work works” (v)
Kanban is about “becom[ing] more predictable” and “work[ing] at a more sustainable pace” (v)
Kanban focuses on “managed commitment” and a “balanced flow of work” (v)
This dual focuses “leads to greater agility” (v)
The authors call Kanban the “Alternative Path to Agility” (v)
Preface
The Kanban Method “is concerned with the design, management, and improvement of flow systems for knowledge work” (vii)
Flow systems are systems “in which intangible work items move through different stages, eventually resulting in value” (vii)
Caricatures include: “Scrum without timeboxes” and “A Waterfall rather than Agile method” (viii)
What is Kanban?
Kanban “is based on making visible what is otherwise intangible knowledge work” (1)
To do this, Kanban “limits the amount of work in progress (WiP) by using visual signals” (1)
The basic structure of a kanban system is a “pull system” wherein work is “pulled” when “capacity becomes available,” and not “pushed” when “new work is demanded” (1)
Kanban Values
Kanban is “values led” (3)
Chief among these is “respect” (3)
The full set is a set of nine:
- Transparency: “sharing information openly improves the flow of business value” (3)
- Balance: “different aspects, viewpoints, and capabilities all must be balanced for effectiveness” (4)
- Collaboration: “Working together” (4)
- Customer Focus: “Knowing the goal for the system” (4)
- Flow: “work is a flow of value, whether continuous or episodic” (4)
- Leadership: “inspir[ing] others to action through example, words, and reflection … needed at all levels to achieve value delivery and improvement” (4)
- Understanding: “Primarily self-knowledge (both of the individual and of the organization)” (4)
- Agreement: “commitment to move together toward goals … dynamic co-commitment to improvement” (4)
- Respect: “Valuing, understanding, and showing consideration for people” (5)
Kanban Agendas
Kanban has three “agendas” or “compelling calls to action” that are “Based on organizational need” (7)
These are:
- The Sustainability Agenda: pace and focus (7)
- The Service Orientation Agenda: performance and customer satisfaction (7)
- The Survivability Agenda: competitiveness and adaptation (7)
Sustainability is “inward” focused and concerned with “balanc[ing] demand with capability” (8)
This is where you start, because “making intangible work visible and reducing overburdening in the servicing of the work” is where immediate impacts on production will be seen (8)
Service is “outward” focused and concerned with “provid[ing] services to customers that are fit for purpose” (8)
This is a values-oriented way of doing business, rather than focusing on profits.
Survivability is “future” focused and concerned with how the “organization survives and thrives in times of significant change” (8)
This is a change-welcoming position: “safe-to-fail, continuous improvement; encouraging diversity in processes and technology,” and we should add, diversity in team, “and respect and engagement for all stakeholders” (8)
The Foundational Principles of Kanban
Kanban has six “foundational principles” organized in two groups: “change management” and “service delivery” (9)
These are:
Change Management Principles
- “Start with what you do now” (9)
- Current processes in actual practice
- Respect existing roles, responsibilities, titles
- “Agree to pursue improvement through evolutionary change” (10)
- “Encourage acts of leadership at every level” (10)
Service Delivery Principles
- “Understand and focus on your customers’ needs and expectations” (10)
- “Manage the work; let people self-organize around it” (10)
- “Evolve policies to improve customer and business outcomes” (10)
When it comes to service delivery, the work is often obscured, or even invisible. Managers then obsess over the workers: “Are they always busy? Are they skilled enough? Could they work harder?” (11)
Kanban emphasizes focusing on the “consumers of the service and the value they receive from it” (11)
I would shift the focus here on to the workers, too, and the inextricable connection between the labourer and their labour.
Describing Flow Systems
Kanban is used for “knowledge work,” and the deliverable of knowledge work is “information in various forms” (13)
As such, the “processes” of knowledge work are “defined as a series of knowledge-discovery steps and their associated policies” (13)
A kanban board makes these steps visible.
For a flow system to be a kanban system, there must be signals to “limit work in progress” (13)
Signals derive from cards, limits, and activity types.
These signals are organized further by commitment and delivery points (13)
Commitment is the agreement that 1) “the customer wants an item,” and 2) “the service will produce it” (14)
Delivery is the point where said items are complete.
Lead time is the time between commitment and delivery (14)
Lead time distinguishes between system lead time (explicitly between commitment and delivery) and customer lead time, which is the wider frame from “request to receipt” (14)
Kanban distinguishes between request and commitment (14)
This distinction is called “deferred commitment” (14)
Work in progress is the “collection of items that are within the system under consideration at any point in time” (14)
Delivery rate is calculated “from the reciprocal of the time between the latest delivery and the previous one” or by “dividing the number of deliveries by the length of the time period” (14-15)
Little’s Law: Delivery rate = Work in Progress/Lead Time
If the “end of the process under consideration is not the delivery point” then Throughput is used instead of Delivery rate. The formula is then:
Little’s Law (T): Throughput = Work in Progress/Time in Process
Where Time in Process is the “period an item is in the process under consideration” (15)
The authors do some further math, and from Little’s Law make the key point: “in order to optimize the Lead Time for work items, we must limit the Work in Progress” (16)
The General Practices of Kanban
There are six (17):
- Visualize
- Limit work in progress
- Manage flow
- Make policies explicit
- Implement feedback loops
- Improve collaboratively, evolve experimentally
Visualize
These six practices involve “seeing the work” and “improving the process” (17)
To visualize work with a kanban board, flow is organized with commitment and delivery points and limits are maintained through the display of WiP Limits (18)
Making “work and policies visible … is the result of an important journey of collaboration” (18)
Limit Work in Progress
By introducing and respecting limits, the work system becomes a pull system (19)
In a pull system, “new items are not started until work is completed (or on rarer occasions, aborted)” (19)
“Having too much partially complete work is wasteful and expensive and, crucially, it lengthens lead times, preventing the organization from being responsive to their customers and to changing circumstances and opportunities” (19)
Bad management tries to limit idle time (20). Good management visualizes the work and allows people to self-organize.
Manage Flow
Flow management is about 1) delivering value, 2) minimizing lead time, and 3) being predictable (21)
These points can conflict! So, “empirical control” is required, which depends on “transparency, inspection, and adaption” (21)
Empirical control identifies bottlenecks and blockers (21)
Bottlenecks are sites “where flow is constrained by one particular sub-process” (21)
Blockers are sites where “there are dependencies on other services” (21)
Cost of delay is a key for understanding flow management, consisting of two elements (21):
Delay cost is the “amount of an item’s value that is lost by delaying its implementation by a specified period of time” (21)
Urgency is the “rate at which the value changes (the delay cost per time period)” (21)
Kanban has four “archetypes” that describe value change through delay: “expedite, fixed date, standard, and intangible” (21)
These archetypes are useful for “ordering work items” or defining “different classes of service” (21)
Expedite and fixed date are the most urgent: expedite is a steep slope, indicating significant value loss; fixed date is an instant chunk of value loss if the date is not met.
Standard and intangible are less urgent: standard is a steady curve, while intangible is a minute upward curve, potentially trending toward infinity.
Understanding these archetypes can allow developers to manage service levels with their customers. These include:
- “Service Level Expectation what the customer expects” (22)
- “Service Level Capability what the system can deliver” (22)
- “Service Level Agreement what is agreed with the customer” (22)
- “Service Fitness Threshold the service level below which the service delivery is unacceptable to the customer” (22)
Make Policies Explicit
A process is workflow + policies, which “creates constraints on action” (22)
Having such defined processes is actually “empowering within the constraints” (22)
Policies must be “sparse, simple, well-defined, visible, always applied, and readily changeable” by workers (22)
Policies serve the work and the value. For this reason, there must be a “visible and straightforward mechanism to question and change policies when they are considered counter-productive or are found not to be applied” (22-23)
Policies include: WiP Limits, capacity allocation, completing work, and replenishment (23)
Implement Feedback Loops
Feedback loops are important for (23-24):
- Strategy alignment
- Operatinal coordination
- Risk management
- Service improvement
- Replenishment
- Flow
- Customer deliveries
Kanban has seven opportunities for feedback called “cadences” (24)
Cadences are “cyclical meetings and reviews that drive evolutionary change and effective service delivery” (24)
Cadence is also the “time period between reviews” (24)
The seven cadences are (25):
- Strategy Review: “selection of the services to be provided” and “sensing” of the “external environment”
- Operations Review: “balance between and across services”
- Risk Review: “understand and respond to risks”
- Service Delivery Review: “examine and improve the effectiveness of a service”
- Replenishment Meeting: “moving items over the commitment point”
- The Kanban Meeting: “daily coordination, self-organization, and planning” in “stand-up format”
- Delivery Planning Meeting: “monitor and plan deliveries to customers”
Replenishment and Kanban are “baseline” for a Kanban implementation (25)
At “a smaller scale, a single meeting may cover more than one cadence” (26)
Improve Collaboratively, Evolve Experimentally
Kanban is an “improvement method” (26)
“There is no endpoint of such changes processes” (26)
“Organizations cannot opt out of evolution” (26)
Introducing Kanban to Organizations
Systems Thinking Approach to Introducing Kanban (STATIK)
The Systems Thinking approach follows these steps (28):
Zero: Identify services
For each service . . .
- Understand what makes the service fit for purpose for the customer.
- Understand sources of dissatisfaction with the current system.
- Analyze demand.
- Analyze capability.
- Model workflow.
- Discover classes of service.
- Design the kanban system.
- Socialize the system and board design and negotiate implementation.
The Kanban Litmus Test
This test asks four questions (29):
- Has management behavior changed to enable Kanban?
- Has the customer interface changed, in line with Kanban?
- Has the customer contract changed, informed by Kanban?
- Has your service delivery business model changed to exploit Kanban?
Managers must respect the deferred commitment, pull system approach, and must respect WiP limits (29-30)
The customer interface must establish clear commitment and delivery points (30)
The customer contract must respect agreed upon service levels based on observed lead times and delivery rates (30)
The business is improved through classes of service, capacity allocation, demand shaping, and differential pricing (31)
Kanban Roles
There “are no required roles in Kanban” and Kanban “does not create new positions” (33)
However, there are two roles that have “emerged from common practice” (33):
- The Service Request Manager (product owner) understands “the needs and expectations of customers” and facilitates the Replenishment Meeting
- The Service Delivery Manager (flow manager) understands the “flow of work in delivering selected items” and facilitates the Kanban Meeting and Delivery Planning
Forecasting and Metrics
Kanban uses “probabilistic forecasting” (35)
Effort-plus-risk approaches have “proven spectacularly unsuccessful on all sizes of projects” (35)
Kanban systems forecast based on “the observed flow of value” (35)
Probabilistic forecasting requires some prior data: item size variability, lead times, and delivery rates (35)
Flow managers must have data on “Lead Time, Delivery Rate, WiP, and cost (usually primarily the effort in person-days consumed by the service)” as a “minimum starting point” for forecasting (36)
The authors show “several important types of graphs for displaying flow systems data” (38)
Expanding the Application of Kanban
Kanban can be scaled width-wise, height-wise, and depth wise (41-42)
Width-wise scaling expands the scope of workflow modeling.
Height-wise scaling applies Kanban at every level.
These applications are possible because Kanban is “scale-free”—it has “the same principles and general practices … whatever the size of the work item, even though the nature of work at the different scales entails very different systems and policies” (42)
Four specific levels:
- Personal for individuals or small teams (42)
- Team
- Product is work beyond the team level that is “generally recognizable by a customer” (43)
- Portfolio is “aligned with managing financial portfolios,” thus determining which projects need investment. This is a completely different discipline from project management (43).
Depth-wise scaling penetrates the “full set of services required by the organization to deliver value” (43)
Though Kanban is scale-free, it is important “not to carry over assumptions from one scale to a larger one” (44)
Learning More about Kanban
Misc resources
Glossary
Activities take work items from one state to another (47)
Cards are visual representations of work items (48)
Aborting vs. discarding: aborting is after the commitment point; discarding is prior to the commitment point (50)
Policies are explicit descriptions of expected behaviours or process constraints (such as WiP limits) (54)
Services are 1) one or more people collaborating to produce work products for a customer, or 2) the work product that the service delivers (55)
States are the overall conditions of work items (55)
Work items are deliverables or components thereof that will be worked on by the service (58)