Mise en place (Part 1)

My wife is an amazingly organized person professionally. She’s been teaching for 12 years now, and knows how to squeeze more out of a few minutes than I do an hour. If you can remember back to your time in a classroom (or are a parent and look at your child’s schedule), how was it that a single teacher was able to conduct 4-7 disparate lessons a day? Every day? With crafts, or manipulatives, or anything else they needed to make it happen?

It feels like magic, but it isn’t.

In watching my spouse work, she breaks down her day into chunks. Every minute is accounted for, whether it’s a scheduled restroom time, lunch, snack, going to and from other classrooms, lesson times, students with questions, whatever. She puts this into a spreadsheet, and she figures out what will work, and what won’t. Every year (sometimes every semester). This takes her around a full day or so. She looks at the curriculum, and makes adjustments to her planned lessons for the year depending on what has changed in that curriculum. She then breaks her lessons down (if they aren’t already), and thematically adjusts them for the year and the kids she’s expected to get for that year (she’s fortunate to know her students before they come, so with few exceptions she knows what she’s getting).

You’d think that’d be it, right? She’s done? Not even close. Every sunday, she spends about 30 minutes re-adjusting lessons for the week depending on events on the ground. She may spend 5-10 minutes a day if needed to re-adjust nightly if needed; but generally it’s not needed. As a rule at her school lesson plans are due the week prior; and so Sunday is her final chance to make sure it’s done.

Once you see it in action a few times, you become a believer. Teachers have from 8am-3:15pm per day (minus lunch, “specials”, and recess) to teach students. They don’t have the 8+ hour days that we have, and they accomplish much more than we tend to per day (weighed together).

How do they do it?

“excellent time management skills” seems like a cop-out. They’re forced to have those, sure. But the practices I see include a fundamental concept that we can practice in our own work. Mise en place. It’s a term that means “everything in its place”. It relates to cooking as preparing all of the ingredients and their portions before cooking, but it works for other stuff too.

For teachers, Mise en place includes the activities before the year starts, the activities before each week starts, and the preparation of all the items needed for activities before the day starts.

What does it include for us? Next time, We’ll go into how we can adopt that mindset, and what that means in developing software.

Why doesn’t my team get it?

One of the questions I hear often from new Delivery Managers is, why doesn’t my team ‘get it’? Why don’t they understand what’s at stake? Why don’t they understand what the client needs like I do? In fact, in any endeavor, understanding the why is the hardest part. Once you understand the why (if there is one), the How and What become much clearer.

When you’re developing a software product, it’s usually easy to connect the why to what you’re doing. I use the payroll platform Gusto, and their why is pretty easy: To make payroll easy for small businesses. That’s why they exist. If you were a developer for Gusto, you could point to that any time you needed to figure out if you should take course of action A or B. “Does this make payroll easier for small businesses?” If the answer is yes, do it, if not, do something else.

For enterprise software, ‘why’ is a muddier concept, but is still critically important in helping to paint the picture. If your team is struggling to deliver features, or to make visible progress, the first step is to be sure you have a “why”, and that you’ve communicated it, often.

If you struggle with understanding why your team does what they do, or you’re a software developer and you don’t ‘get it’, this talk by Simon Sinek will help.

Invisible Process

How do you feel when someone says the word “process”?

I’ve seen three reactions to it:

  1. Yea, it sucks, but how could we get our work done without it?
  2. Let’s check these boxes so the powers that be are happy
  3. Meh. It doesn’t affect me.

Process is at best a necessary evil to you or it’s how you get work done. It either fills you with dread or you are at best indifferent to it.

The emotional reactions towards process are inversely proportional to its impact.  That is, the right process can keep your team running smoothly where the wrong process causes everyone to cringe and complain during retrospectives.

Scrum attempted to solve this problem by narrowly defining the ‘required’ processes to a minimum and claiming that if you used other processes mixed in with scrum, you were not doing scrum!

Process has become the enemy for all right-thinking software developers; and required for medium to large teams.  

But what if your process was invisible?  What if your entire process were automated?  How would you feel about process then? 

What if the necessary code review requests were automatically sent out to the right people — people with domain knowledge in the area you’re working in?  What if the test suites you’re working on helped send an email with the method signatures and their expected / actual return values? 

What if those reports that you spend a day generating for your clients to show them how much effort you put into your work (never to be used again) were automatically generated for you?

How would you feel about process then?

Why should I care about Git Hooks?

In helping software teams double their productivity, one of the tools that we all use as software developers that gets the least attention is source control. If you’re using git, there are numerous features sitting there, waiting to help you develop software with less friction. One feature that I’m particularly enamored with are git hooks. Git hooks are automation scripts that fire when certain events happen in git, allowing you to automate otherwise manual activities.

Git hooks allow you to do the following:

  • ensure branch names are consistent across individuals
  • separate whitespace commits (formatting) from substantive commits
  • update your ALM’s (JIRA, TFS, Gitlab) status automatically on commits with certain properties (e.g., a commit saying “fixed bug” triggers a workflow move from ‘in progress’ to ‘in review’ for a given bug)
  • trigger checks to ensure copyright/license information is included in commits for new files

and so much more.

If you can write a script for it, you can automate it in git — and due to the nature of git, those hooks stay with the repository, no matter who pulls your code.

Git Hooks to Check Commit Messages for Certain Text

Do you wish you could force people on your team to tie a commit message to a particular work item? Would you like there to be specific text in a commit message to help you tie it to an area of your application?

For some of you this may seem weird — it’s just code, after all. But in some industries and in some work cultures, being able to tell what you affected with each commit is important. It’s for you that the git pre-receive hook provides a solution.

I built this pre-receive hook in 2016, when I worked at a company that had a requirement that commits be tied to work items for “traceability” purposes. It seemed weird to me at the time, but since then I see its value. Developers work at the level of the code and of the commits, and seeing what work items (or “tickets”) a particular commit is tied to gives us a placeholder for that ‘why’ was this done.

Here is a link to that gist I created. In the future I’ll go into what git hooks are, and how you can create your own git hooks, for now, enjoy my rather terrible Python and this rather useful git hook.