Chris Lucian

After reading the Checklist Manifesto, I started creating a number of checklists that I thought were useful. I want to begin publishing them here. The goal was to keep each one about 6 items long. I intend to add to these checklists over time. If you would like to see more of these, please contact me on twitter.

 Single Piece WIP

 Scout Rule

 Known Unknows Evaluated

 Red Green Refactor

 Properly Triangulated

 Released to Production

Hopefully these are straight forward. 

Single Piece WIP is simply are we practicing Kanban correctly? 

Scout Rule refers to "Did we leave the camp site nicer than we found it?" Specifically did we improve the maintainability of the code rather than damage it?

Known unknowns evaluated refers to getting known gaps in our knowledge eliminated. There will always be known unknowns but its easier to run small safe experiments before getting started on the production code. 

Red Green Refactor simply refers to test first development. Creating an automated test before writing production code.

Properly Triangulated refers to the idea that one unit test wont cover all edge cases etc.. of a specific implementation. Like triangulating GPS signals we need to write tests to prove things like boundaries and special cases are covered.

 Lean

 Psychologically Safe

 Technically Safe

 Documented

 Automated 

This checklist is more for process design than anything but also could be used to evaluate existing processes.

Lean refers to "Lean Software Development" eliminating the 7 deadly wastes and creating high density value delivery! 

Psychological Safety refers to creating a team environment that fulfills the research done by Amy Edmonson on Psychological Safety.

Technical safety refers primarily to automated tests, builds, releases. Self documenting errors, and high cycle time work. When an error happens it is as easy as possible to eliminate it because automated systems catch it or it gets discovered soon after release.

Documented might be counter intuitive here but I put this one in primarily to fulfill legal documentation not traditional software documentation. Systems in place should automatically document a variety of things including information used in audits and legal investigations.

Automated refers primarily to automated testing, deliver, and feedback loops.

 Cycle Time

 Bug Count

 Product Owner Happiness

 Lofty Goals

 Appreciations

 Lean Coffee

This is a checklist I run through weekly with each mob.

Cycle time in this context is the time from "next most important thing" to production.

Bug Count here refers to #BugsZero or ZarroBoogs. No bugs in production. Automated tests around all bug fixes.

Product Owner Happiness is a loose metric. This is the relationship the PO has with the team. The team should feel safe taking on technical tasks outside the priority features but also should deliver often enough that the PO does not notice. If a PO feels like they are not being listened to, it is a red flag and gets more discussion.

Lofty Goals is a reminder to review the teams lofty goals and make sure they either change or are being followed.

Appreciations are exactly what they sound like. Some times people on teams dont get the chance to tell each-other they did a great job. 

Finally a general lean coffee to get everything out in the open related to the team and talk the most important parts through.

 Review Prior Goals

 Timeline Retro

 Force-field Retro

 360 Feedback

 Create Goals

 Ask for Feedback

This is the checklist I use for bi-annual goal setting. Once again very simple but implies a lot gets done in the process.

Reviewing prior goals. This is fairly direct. Go over recent goals that were completed or abandoned.

Timeline refers to a timeline retrospective where the individual charts events since the last goal setting. 

Forces refers to a force field diagram to identify what is pushing the individual forward and what is holding them back.

360 Feedback refers to the feedback from peers, reports, and leaders. 

Create goals, one from timeline/forces and one from 360 feedback. Think of it like a introspective goal and a goal imposed by others.

Model the important of asking for feedback by asking for (and acting on) feedback yourself.

I hope this list of checklists is helpful for you. Please share these with people who you feel need them!