Mise en place (Part 2)

In my last blog post, I talked about how my wife, a teacher, is able to pack so much into her day. How she’s able to reach students in 4-7 disparate lessons per day and do so in the the time she has. The biggest enabler is Mise en place. In this segment, I want to talk about how we can adopt that mindset for our work — knowledge work, that is by itself sometimes unknowable.

First off, let’s look at how our days are structured:

1. Get into work (8:00-8:10)
2. Check Email, respond to any issues (8:10:8:30)
3. Open up IDE, text editor, pull code (8:30-8:35)
4. Get distracted, open up browser (8:35-9am)
5. Look at work items in JIRA or TFS (9:00am-9:15am)
6. Find right files, and start working (9:15-9:20am).

Your day probably looks more or less about this; but let’s be realistic. More often than we care to admit, we waste a full hour and a half at work before we do what we are judged on — what software features and outcomes we can deliver. What would this look like if we practiced Mise en place — everything in its place?

First off, we’d probably spend the previous day’s final 15-30 minutes getting ready for work the next day. It’s not often we’re productive in the final 15-30 minutes away; and so this is a good time to prepare for the next day.

One important outcome when preparing for the next day is ensuring that you feel as productive as soon as possible. Email releases the endorphins when you’re able to respond, but is it the most productive use of your time? Probably not. (unless you’re a manager type). If you know you’ll be working on a new feature tomorrow, go ahead and create the branch today. It doesn’t matter what branching methodology your team uses, creating branches in git is free and helps segment your work. (And if you’re not yet using git, use your source control’s analogue, if it has one). Typically you’re not going to be assigned new work overnight, and so you can already pick tomorrow’s first work item today. Go ahead and move it into in-progress before you leave, and assign it to yourself. Get your workstation set up so that when you come in, you’re able to start working on it immediately.

Do you need some research to be able to start on that work? Go ahead and pull it up. Look over the work item, and make sure you can get started with it. That’s what’s important — ensuring your next 4 hours or so are covered and that you won’t have to pause work to get something to be able to be productive.

That’s all we’re going to focus on for right now — ensuring that your next day’s work is able to be started as soon as you walk into the office. Only worry about the first few hours for now, later, we’ll talk about strategies for increasing your productivity window.

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.