Month: November 2019

One of my peeves about ALMs like JIRA and TFS is that they default to a scrum or Kanban view, where all the items are shown for a given sprint, iteration or increment.

The idea is, by showing everything, the team can physically see how much work is left and where it is.

If the only time we viewed items like that was during the standup, it’s still distracting, but fine.

however, it’s the default view. TFS and JIRA both support a “show only my items to me” view, but that has the same flaw seeing *everything* for a sprint does — it’s distracting and it doesn’t reflect how we work.

At best, a person can only work on one thing at a time, and again, at best, they only care about that item and anything that intersects with that item (think about how reports may be dependent upon a particular model that is also changing during the sprint).

So why then do we insist on showing them their entire todo list all at the same time? All it serves to do is to distract people from the work right in front of them. Someone, somewhere cares about all the work that’s left (that’s you, delivery manager), but your programmers and QA testers don’t need to — and shouldn’t worry about that day to day. They can’t work faster than one item at a time anyway, and our ALM software should reflect that constraint.

A close friend of mine spends his year between two activities, sailing around the US with his wife, and freelancing. Every year, he has to stop for around a month and do the maintenance on his sailboat. That usually involves a dry dock, orbital sanders, and scraping off all the barnacles that have grown on the boat over the past year. Personally, I never understood it. Barnacles can’t really affect a ship that much, can they?

Turns out they can.

I own a midrange grill from Home Depot, and every 6 months, I strip the grill down and clean all the plates, and pick the carbon bits out of the gas outlet holes.This involves steel wool and lots of elbow grease. When I’m done I oil them and run the grill through its paces. Every time I do that the area above the grill plates registers 100 degrees hotter than before.

It’s amazing to me — the carbon bits affect the temperature so much that cleaning the grill nets a 100 degree difference. Now again, this is a midrange grill with a midrange thermometer so this isn’t scientific — but it’s noticeable when grilling, so much so I have to leave steaks on for an extra minute before cleaning.

in software teams, it’s easy to see the big problems that slow teams down, like team cohesion and uncertain requirements, but it’s not so easy to see the small things.

These small things are the things you’ll hear occasional gripes about, like having a hard time finding things in JIRA, or a build server being flaky, or test case formats not reflecting operational needs.

if your team complains about certain problems occasionally but persistently, then these are your barnacles.

Every team needs time to clean the barnacles, and you as the delivery manager are in the best place to see the barnacles growing.

Juan Soto is a 21 year old baseball player for the Nationals. After one of the games during the NLDS (National League Divisional Series), Juan had trouble batting. He did something that announcers still remark about 2 weeks later. He stayed after the game (already close to midnight local time at this point), and he worked with the batting coach to practice hitting against the shift — to pull the ball to where statistically players were least likely to be (yay sabermetrics).

Imagine that. At the time, a 20 year old player practicing hitting in a specific way at midnight with a batting coach when they have a game the very next day.

Juan ended up using that practice in the very next game to hit very well and help his team get ahead.

We tend to go through the motions as software developers. We’ll practice katas, sure, but we don’t think about intentional practice in the same ways other professions do (this anecdote could have been about doctors, dentists, or even members of the military or first responders). And maybe it doesn’t have to be like that for us? Maybe we’re special. After all, we rarely need to perform under pressure, and we rarely need to ‘hit a home run’ — most of the time the fundamentals are good enough.

But, what would that look like for us? Would it be TDD katas? That comes to mind. Would it be codewars? It could be. But really it’s not about practicing the things we do most often, it’s about practicing the things we don’t do every day — the things we need to get better at to be our most productive.

For me, it’s breaking tasks down and working on communicating effectively when what I’m working on is going to take longer than I thought. Sometimes it’s working on speaking less in meetings, and ensuring those that speak less are given the chance to contribute, and sometimes, it’s improving my CSS.

What are the things that you feel like you could practice?

Model Software Delivery is an exercise in effectiveness, not efficiency.  

​Effectiveness is building the right software, for the right customer, with the right process, aligned with the current culture.  

Efficiency is building software with as streamlined a process as possible for the current customer and in maybe in alignment with the current culture or in spite of it.

Business leaders will say they want efficiency but what they really need is effectiveness.

If you focus only on improving your team’s process (hello Scrum) you’re delivering efficiency gains, not effectiveness gains.

Scrum (and other agile methodologies) try to change your culture to deliver software effectively. Without that culture change, Scrum can only deliver marginal gains in efficiency, and no gains in ​effectiveness​.

To deliver gains in effectiveness, your process and software must align with your culture.

It’s a rainy Friday evening after a week of soccer practices, ballet, ice hockey practice, and tutors. My wife is exhausted, driving home with two cranky kids, and I get the dreaded phone call from her.

What do you want to do for dinner tonight?

Since we have a menu we stick to (productivity begins at home?), getting that call means the menu is out. Whatever was on there isn’t happening, and it’s now up to me to make a decision. What are we going to have for dinner tonight?

We live in the suburbs of Washington DC, and there are a plethora of pizza places locally — good pizza places too. But, as this conversation usually goes, I tend to forget about them at that particular moment, and suggest Papa Johns.

Papa Johns.

Up against a wall, panicking for an answer, I pick quite possibly the most mediocre pizza chain to frequent the ‘burbs. Papa Johns is consistent, and the pizza is okay, but the reason why I’m picking it has nothing to do with how good it is and everything to do with its name recognition and its ability to be a reasonable compromise among all other choice.

If you want a mediocre pizza that works in a pinch, Papa Johns is it. Heck, after years of having Papa Johns, you may even be forgiven for thinking it’s the best there is.

Jira is the Papa Johns of Application Lifecycle Management (ALM) Software.

It works in a pinch, everyone knows about it, and it’s just consistent enough that you can be forgiven for realizing how terrible it is for producing software. You can always configure it to how you really want to work, and you aren’t going to be laughed out of the board room for suggesting Jira. But, it’s going to have the same effect eating Papa Johns will. You’ll be full, but you and your team won’t be satisfied.