Note: to download when you cannot get to YouTube online, put “ss” in front of YouTube in the address.

• Simulating Agile Execution with the Ball Point Game
• Simulating WIP Effects with Balls and a Banana

• 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.
• Wake up in the morning game - Simulation or game to help people understand story mapping.

Also videos of games:

• Airplane game
• Ball Point Game

• 12 Principles of Agile Development by Julien Henzelin
• VersionOne "State of Agile" Survey (9th Edition). You need to register to get it - my version.
• Help answer question "What does a Scrum Master do?"
• 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.
• Role of Product Management from Pragmatic Marketing framework
• 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.
• Alistair Cockburn etc on Communication including richness chart and the implications of this richness.
• 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.”
• Discussion on roles beyond PO, SM, and team basics
• Advice on Running Scrum-of-Scrums meeting from Mike Cohn.
• 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
• Adaptive Leadership Accelerating Enterprise Agility - Jim Highsmith. Talks about the way we need to bring the agile mindset to the enterprise.
• 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.”
• WIP: why limiting work in progress makes sense (Kanban) - Good illustration of the use of WIP limit to optimize both number of customers served (business benefit) and time to service each customer (customer benefit)
• 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.
• Article - Sliding Toward Success and related tool Project Success Sliders Tool - Mike Cohn's approach to working trade-offs between the various constraints on a project.
• This American Life - NUMMI and how America is slowly learning the lean lesson from Toyota.
• Systems Thinking in a Digital World - Peter Senge - the title says it all. Pete is the author of “The Fifth Discipline”.
• Software Development Performance Index. My copy whitepaper-sdpispecifications-v1.pdf. This is work that came originally from Larry Maccherone while working with Rally. Ideas is to use performance, quality (release ability), predictability, and responsiveness. For example:
  • Release ability - if team worked on nothing else but close out bugs how long
  • Responsiveness - how long to get in a bug
  • Performance - thought put - closed work items
  • Predictability - how consistent is our delivery (versatility)
• Discussion of remote vs co-location: Martin Fowler with a nuanced discussion on the trade-offs of remote vs co-located people.
• The Impact of Agile Quantified - A set of data looking at all types of metrics from a dataset of thousands of Teams
• Agile Doesn't Work Without Psychological Safety - HBR article with some practical ideas on how to encourage psychological safety.
• The Most Common Cognitive Bias - How to get information out of a system.