Thursday, September 10, 2020

Checklists, Mobbing, and Software Development

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.

Software Development Checklist:  Single Piece WIP,  Scout Rule, Known Unknows Evaluated,  Red Green Refactor,  Properly Triangulated,  Released to Production


Software Development Checklist

 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.


Process Checklist:  Lean,  Psychologically Safe, Technically Safe, Documented,  Automated

Process Checklist

 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.

Team Coaching:  Cycle Time,  Bug Count,  Product Owner Happiness,  Lofty Goals,  Appreciations,  Lean Coffee


Team Coaching

 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.

Individual Coaching:  Review Prior Goals,  Timeline Retro,  Force-field Retro,  360 Feedback, Create Goals, Ask for Feedback


Individual Coaching

 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!


0 comments:

Post a Comment

 

Follow