Pull Request

Pull Request (1)

I’ve been around software guys for years and have heard the phrase pull request long enough that I was embarrassed I didn’t exactly know what it meant.  I had a general idea, but not one that was clear in my mind.  I also knew that this was one of those technical questions where I would grok it better if I talked to someone in person.   So, I found one of the smartest guys in the building when few people were around, drew out a kanban board (above) and asked him how a pull request was done.

I got my answer, but to my surprise when I searched for images none of them had anything to do with kanban boards.  They viewed pull requests as off-track activities that needed to get pulled back into the main branch.

That’s interesting, I thought, because that understanding means that items on the main branch wouldn’t go through the review process that is a pull request.  That doesn’t jive with the reality that I’ve heard pull requests being used on main branches and appendages of software development for some time.  I think the definition needs to be updated, and the diagrams need some competition.  So, here’s my contribution.  It’s a kanban board view of a pull request.

Illogical Behavior ≈ Illogical Measurements

Tell me how you measure me and I’ll tell you how I behave.  If you measure me illogical way. . . do not complain about illogical behavior.

This past week I got to meet someone who I’d instantly consider a friend of mine.  She works as a continuous improvement engineer for a potato manufacturing company in China.  She was communicating her observations of the behavior of the workers in the plant and how it impacted production.  As I was listening (which I’m still not as good as I’d like to be) I remembered this quote from Eliyahu Goldratt’s book, The Haystack Syndrome.

The behavior she was describing was illogical and while there’s not a direct correlation between illogical behavior and measurements, Goldratt is generally correct that there is a correlation!  I asked her what her mepotatoes fun knife forkmeasurements were and she explained that each shift is currently measured on their output.  Output is defined as the amount of product produced during their shift.

Output and throughput are two different things.  Output is the amount of product regardless of quality.  Throughput is the amount of value of the product to the business as determined by the customer.  Customers tend to care about quality, and so while a shift may have high output if that output is of a lower quality than customer specifications it will not meet throughput requirements.  It is wasted effort.

It’s easy to see how this happens, the measurements are designed to encourage a particular type of behavior, but that behavior doesn’t translate to added value.

One way to expose this is to ask yourself if the work your doing is value added or if the work you’re doing is simply to satisfy a measurement?  If you’r work is value add, great!  Keep going.  If it’s to satisfy a measurement then please, question the assumptions of the measurement.

Notice I said, question the assumptions of the measurement, not the calculations.  Generally, people get the calculations right (with some exceptions), but it’s the assumptions that are really dangerous.  The leadership at my friend’s work had made the assumption that output and throughput were the same thing and that measurements based upon output would suffice to encourage the behavior they wanted.

That assumption appears wrong.  It should be tested and if found false, corrected.

Making and operating on assumptions doesn’t make you a bad leader or a bad person.  We all do it.  There’s just not enough time in our lives to fully research every decision (See Thomas Sowell’s Knowledge and Decisions).  We have to use good-enough information when we make our choices.  Once a system is established it’s a good idea to review those choices to see which assumptions can be challenged to find greater opportunities to improvement.

Are you ready to challenge your assumptions?


Making Work Visible

It’s that time again. I’ve been reading a new book, and it’s time for the book list to get updated. This time it’s the book Making Work Visible by Dominica Degrandis. The book started with a story I could relate to. A husband working on the honey-do-list being asked by his wife to start an entirely different project. She was asking while he was atop a rotting roof to tear it and the out building it belonged to apart. That’s a bit more dramatic than any of the situations where similar things have happened to me, but it was certainly a moment I could relate to.


Dominica does an excellent job in the piece discussing the need and techniques to make work visible in areas where work is less visible than a husband standing atop a roof. The IT sector contains many examples of areas where work is invisible to those who consume and appreciate the effort. Dominica’s techniques help to bring forth this work in ways that are digestible by the passer-by and those who deeply study the output.

This book is ideal for anyone who has done work or plans on doing work in the future.

While I’ll tell the full story another day, I can say that this book emerged in my life at the right time to help a very large project focus on the work that would add the most value and now it’s gotten the interest of the leaders who saw how effective its techniques were.  It sort of feels like having to get called into the principle’s office to explain myself, but in a good way.


Everyone’s Right

Youve been there before. You’re in a meeting and someone is very passionate about how they see a situation. They escalate their volume. Soon there’s a misunderstanding and someone else matches passion for passion, but they don’t share the same perspective.

Two people may walk on a path but their destinations aren’t always the same.

It’s entirely possible to pause a conversation that is going badly. During the pause I remarked how both people were right and encouraged them to see it from the others perspective.

It worked.

I only hope someone is around to pause the next meeting where I become passionate.

No Offence

Months into the project the tracts I was working on managing were lagging behind.  My inexperience, cultural barriers, technical challenges, and resources all contributed to a series of delays.  No one on the team had any issue with the way I’d been handling things because I kept them in the loop and help set proper expectations.

There was a great deal of anxiety about the delayed deliverables since so much was depending on them.  A meeting was called for lunch in a company that treats lunch time as a sacred break to give their employees time to refresh and we started breaking out the details on my deliverables.  A lot was done, but without the complete set of work the dependent tasks could not be performed and tested.

A passionate meeting ensued.  The whiteboard basically looked like it had graffiti on it.  Tables were drawn.  Dates were discussed and debated.  People were using their outside voice inside to make sure they were heard.  At the end of it the Product Owner pulled the leadership team aside and recommended that the primary PM own my effort and serve as the single point of contact.

By the time I got to the cafeteria my boss, who had scheduled the meeting, asked me how I was feeling about it.

I told him that I wasn’t offended at all.  We’d reached the point where the delay on my workstreams were impacting the overall project and that the primary PM needed to be intimately aware of what was going on so he could find opportunities to move his dependent steps forward as it becomes possible to do so.  I’m still managing, but now I’m feeding that PM my information at every update instead of just our normal cadence during the week.

I’m not sure how things would have changed if pride were a part of the equation, but I don’t imagine it would have made things any easier.  I think it was better to spend the time to focus on the work at hand and not on placating someone’s hurt pride.

No offense?  None taken.

Kill Your WIP

WIP = Work In Progress

Work In Progress is a large enemy of productivity. It exists even in the home. My 8-year-old is an expert of WIP. During the school season she would wake up at least 90 minutes before her bus would leave. She would start her hair, getting dressed, eating breakfast, and making her lunch. She wouldn’t actually finish any of these things. She would just start them and rotate from one to the next inserting other tasks (playing with the dog) along the way.

Usually about 15 minutes before the bus would leave a kind parent would hover and follow her every step of the way. Eventualy she’d be able to focus and get one thing done, then another, and another, until finally the whole list was complete and she’d head out the door to her day.

“Finish what you started, [daughter]!”

While there are many different techniques to address WIP when it comes to addressing them in your personal life, you might start by just looking for opportunities to finish what you started.

While you’re at it, you might want to ask yourself if what you’re doing is productive, or if you’re playing with the puppy.


How I Made This

I can’t art.

My YouTube feed showed me that the Slow Mo Guys were spinning records until they broke.  I decided that the breaking frames looked beautiful.

So I took the frame from their video and took a screenshot:


But I didn’t want all the background noise.  I just wanted to get the outlines and to do that I needed to convert the bitmap to a vector.  For that I used InkScape.

After InkScape selected the right bits I deleted the unwanted parts (had to ungroup first) and ended up with this:


Ah, but that background was a bit ugly and I like dartkable.  So I brought it into darktable and tweaked the color settings to end up with this:


Now that I’ve done it and typed about it I can see there are better ways to do the workflow.

Interesting how defining processes gives you the perspective to find opportunities to improve the processes.