A list of videos I've come across over the years that help get concepts across.
Don Reinertsen - Second Generation Lean Product Development Flow. Talks about some of the content of his book. As usual a very “dense” pitch with a lot of information. If you want to understand impacts of things like queuing theory, lean, and why variability should be preserved for new product development (hint: Black Scholes option pricing model) then this is the video for you. See My notes for more information.
“Uncle” Bob Martin - The Principles of Clean Architecture. Great anecdotal story at the beginning, as always. Then discussion around how architecture should reflect the domain - what the application does.
Sinek’s Ted Talk - Start with Why - To understand how to communicate with people especially as you introduce something new. Bit from 1:35 to 5:15 relevant for product owners, for example, when explaining “vision”.
Steven Johnson - Where Good Ideas Come From - On understanding how innovation works - requires a collision of half ideas (the slow hunch) that have been fermenting in the background for a while. So idea is to provide an environment to connect. “Chance (of innovation) favors the connected mind.”
The Backwards Bicycle - Great video to understand how its hard to unlearn what we know, that knowledge isn’t the same as understanding, to learn you have to practice, practice, practice, and that you have biases and are unaware of them. See more at Why Is Agile So Hard - The Backward Bicycle?
Leeroy Jenkins - What happens when 1 person doesn’t consider the rest of the team. From World of Warcraft.
Agile Manifesto Explained - Quick 3 minute video on the basics of the Agile Manifesto, including a bit of history.
Are we in Control of Our Decisions: Behavioral economist Dan Ariely, the author of Predictably Irrational, uses classic visual illusions and his own counterintuitive (and sometimes shocking) research findings to show how we’re not as rational as we think when we make decisions.
Coordination Chaos: Good video to help explain why the old way of working no longer works as the organization grows.
To help people understand small vs large batch processing (the ideal of one piece flow in manufacturing world) when you cannot run something like the penny game:
The Resource Utilization Trap: Henrik Kniberg's excellent demonstration of the problem of focusing on resource utilization in bringing value to our customers
Design Thinking - Introduction to the basic ideas. While it is presented as a “linear” process, and misses notions of divergent and convergent thinking, it is a good start.
The Lucky Iron Fish - Helps people understand why we need to do “gemba” (go and see) when trying to understand the requirements of the product.
TEDTalk on How the Lucky Fish Can Treat Anemia - Useful video that expands on the discussion above to look at a complete process of making a product “fit for purpose” including the design of the product, the implementation of the product, and the delivery of the product.
Russ Ackoff on Systems Thinking - ever wondered what it means to do systems thinking? This is a short video explaining what Systems Thinking is and why you cannot just decompose the system into parts and expect improvement overall.
10 Reasons Estimation and Planning Fails and What to Do About It by Troy Magennis. Great pitch. Love the basics here. Main message is “a lot of bad things happen in projects which increase utilization into the 'non-linear' (when lead-time graphed over utilization - above 80% utilization leads to exponential lead time) zone and so make estimating useless and forecasting difficult.” Key learnings include:
If you are in the non-linear region of utilization for your project (i.e. greater than 80% utilization) then estimation will always fail.
Sometimes you need just enough information to decide what not to do, and perhaps toss a coin for remaining options (if they really are close enough).
If we only have a high utilization system and we cannot change this, then estimating using points etc doesn't make sense. For high utilization systems we need to track system level impediments to the flow.
Top 10 list (portfolio level): (BTW why this project won't finish on time is because of last project - and no amount of estimating is going to help)
Don't start on time. Eg delay in previous project
No team (no one to do the work).
Partial team. Eg on prior project. Half strength team → over utilization
Partial body substitution. Similar to above.
Missing skills sets. Variation on a theme. Are we producing useful stuff. Look busy but don't know whether we are making progress. See “capability matrix” based on level of capability - novice and learner (but will to learn), do / maintain and so able to modify (and make small additions), teacher / creator (able to do work and show others). Help actively develop your T-shaped people.
Over-stated parallel effectiveness. Adding teams / people to make it faster does not scale linearly. Limited by whatever serial processes you have in place. Variation on Amdahl's but applied to people. Spend 8x the effort but only 3x additional capability. Need to invest in independents and tools (eg continuous deployment)
Dependency and friction. Tracing through how work was actually done. How many levels of dependency. 1.5X the Sprint length is the fastest you could move through the system (as sometimes it doesn't get delivered in the Sprint expected.) Need to understand the dependencies you have. Every dependency you can remove from your delivery stream doodles your chances of delivering on time. This could mean, for example, having merged larger teams to reduce the number of dependencies.
Carried over defects and debt.
Ship stoppers. There are always these. If you ask the question “if I double the team would this help”. Often answer is “no”. Tried to find these out early eg by surveys every week “would you ship this tomorrow …”
Splitting. Rate the we finish items and the rate that we arrive are never the same, because we split. We need to take into account that we are splitting items as we do work.
Use these “assumptions” to understand whether the project is on track. Don't really need status reports if these assumptions are not met.
Games
Zin Obelisk Game - Fun game to experience and examine the sharing of information in team problem solving and how leadership, cooperation, and conflict issues effect team problem solving.
Scrum Master vs Project Manager Game - Useful game which helps folks understand how the responsibilities of a traditional project manager are moved to both the Scrum Master, the Product Owner and the Team when applying agile approaches.
Base approach to splitting stories. Additional thinking at from Bill Wake 20 ways to split stories. These ideas are to help to get to a minimal, end-to-end solution present which usually has high value, from which you can thin then fill in the rest of the solution in subsequent iterations.
The Burning Platform metaphor by Daryl Conner. Idea is to have the resolve to make the change happen. Resolve can come from current or anticipated problems or current of anticipated opportunities, not necessarily as a result of “peril” (which is “current problem” classification.
James Coplien on the Borland Quattro Pro development which some say was the most productive ever recorded. To quote the abstract “The project assimilated requirements, completed design and implementation of 1 million lines of code, and completed testing in 31 months. Coding was done by no more than eight people at a time, which means that individual coding productivity was higher than 1000 lines of code per staff-week. The project capitalized on its small size by centering development activities around daily meetings where architecture, design, and interface issues were socialized. Quality assurance and project management roles were central to the development sociology, in contrast to the developer-centric software production most often observed in our studies of AT&T telecommunications software. Analyses of the development process are “off the charts” relative to most other processes we have studied.”
What Google Learned From Its Quest to Build the Perfect Team by Charles Duhigg (New York Times article). Article which points out how little team composition (in terms of the A team, for example) really points to an effective team and that instead the “conversational turn-taking” and “average social sensitivity” on teams (supporting “psychological safety”) is what predicts team performance best. Other factors were also recognized as important - like making sure teams had clear goals and creating a culture of dependability. To support the “safety” aspect “What Project Aristotle has taught people within Google is that no one wants to put on a 'work face' when they get to the office. No one wants to leave part of their personality and inner life at home. But to be fully present at work, to feel 'psychologically safe,' we must know that we can be free enough, sometimes, to share the things that scare us without fear of recriminations. We must be able to talk about what is messy or sad, to have hard conversations with colleagues who are driving us crazy. We can’t be focused just on efficiency. Rather, when we start the morning by collaborating with a team of engineers and then send emails to our marketing colleagues and then jump on a conference call, we want to know that those people really hear us. We want to know that work is more than just labor.” “Sakaguchi’s experiences underscore a core lesson of Google’s research into teamwork: By adopting the data-driven approach of Silicon Valley, Project Aristotle has encouraged emotional conversations and discussions of norms among people who might otherwise be uncomfortable talking about how they feel”. And “It’s easier to talk about our feelings when we can point to a number.” My version what_google_learned_from_its_quest_to_build_the_perfect_team_-_the_new_york_times.pdf
Work Characteristics and Work Performance of Knoweldge Workers: What Goes Hand in Hand? - Research paper on knowledge work and importance of various characteristics of the work on the performance of knowledge workers. From abstract “The aim of the paper was to investigate the interplay among a wide range of work characteristics and knowledge workers’ performance outcomes. Specifically, we examined the nature of relationships between various task-, knowledge- and social characteristics of work design and both task and contextual performance. Using an adapted Work Design Questionnaire and applying PLS-SEM modelling technique, we analysed cross-sectional and cross-occupational sample of 512 Croatian knowledge workers from 48 organizations. Our findings confirmed the existence and importance of interaction between work characteristics and work outcomes. However, the results suggest that only knowledge characteristics of work design exhibit a significant effect on both distinct dimensions of work behaviour, while task and social characteristics showed different effects on task and contextual performance, respectively.”
QSM Study on Effectiveness of Small Teams vs Large Teams - presented in the context of “adding team members late in the project” but also captures specific case comparing result on schedule and cost of work with teams ⇐ 5 vs teams >= 20. Result is that you get little schedule compression with large teams, but this is at massive change in cost (5 people vs 20 people). Their conclusion is that it perhaps has something to do with the amount of defects produced - much more from large teams.
Create your own project cartoon - remember that picture - what customer asked for, what project management understood, etc. Here you can create your own.