Month: November 2019

Last week, I was privileged to speak alongside Suzanne Ricci, and Jeff Baird as part of a 3 member panel on tips on what you should do after you’ve gotten the job. It is a two-part webinar (the second part will be recorded in January). The first part is available here.

There’s a famous quote, “The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.”

As Homer might say, It’s funny because it’s true.

But how can you tell when a programmer is stuck on a problem?

One way is to pay attention to their behavior, and if anything is out of the ordinary for a day or two, then you know something’s up.

Another way is to scope all work such that they should be implementable in a day, and this certainly has the side effect of it being easy to tell when a programmer is stuck, it also has the unwanted side effect of putting more overhead into planning — not something anyone wants.

This is one of the areas where daily standups — properly used — can help. Weekly “status” meetings don’t invite the sort of conversation you need to uncover problems people are encountering, and normal daily standups reward papering over problems if you’re not in a high trust environment (if you are in a high trust environment people will likely tell you when they’re stuck — so before all else, think about how you can increase trust).

During a standup, most programmers aren’t going to say, “I’m stuck on X”, and it’s not because they’re afraid of getting in ‘trouble’, it’s because they don’t want to lose face in front of their peers. However, they will give hints that they’re having issues, and you can take that as an indication to follow up with them alone, away from their peers.

So how do you ask a programmer non-confrontationally if they’re stuck?

Try these:

“Hey, it looks like <that thing you’re working on> is a bit more involved than we initially thought; who do you think would be best able to help you make forward progress on this?”

“I can tell that you seem frustrated by what you’re working on. I get that. Hard problems have a way of being frustrating and draining. How can I help, or who can I enlist to help you get un-frustrated by this?”

Use your own terms of art; but there are three things you want to communicate when dealing with programmers:

1. Programming — even things we’ve done hundreds of times before — is hard. A minor update to a library can steal days worth of effort.
2. Because it’s hard, programmers aren’t to blame when things slow down. It’s either a combination of understanding, alignment of skill to the problem domain, or general difficulty of the problem domain. If you ask direct questions, “How do we unblock you?” You’re inadvertently challenging the competency of the programmer, even if you don’t mean to (a literal programmer might say, “I’m not blocked”, even though they’ve spent a week on something they thought would take a day, and a programmer that has an ego might think their peers would think less of them if they answered truthfully).
3. You’re there to quietly help them move forward. No fuss, no muss, no loud hullabaloo about their progress. You’re there to get them unstuck, without them feeling embarrassed by it.

One of the tenets of agile is a sense of “Collective Code Ownership”, that is, that everyone on the team owns the code.

The “traditional” model is for people to specialize in different areas of the code and to rely on those people for their respective parts of the code. The way this manifests itself is that at most 1 or 2 people understand the harder parts of the code and everyone else are “generalists”. OK across the code base but not well versed in any particular area.

Fred Brooks, in The Mythical Man Month, spoke of a surgical team, where one person acted as the “surgeon” (doing the work) and everyone else supported the surgeon with whatever they needed.

Large and complex systems will invariably have people specialized in sections of that system, and those people will necessarily be harder to replace should they win the lottery.

agile methodologies (like Scrum and XP) try to solve this through collective code ownership.

Projects often rely on ‘fast’ work (when have you been part of a software project that was released on time, budget, and original scope?) and that has a natural tension against collective code ownership.

Developers work faster in areas of the code they understand, and specialization helps that. Developers also hate to be pigeon-holed.

So what do we do? Push code ownership for the sake of delivery? Or Push collective ownership for the sake of the bus factor?

Why Not Both?

Encourage developers to learn and specialize, and also encourage them to trade off and teach each other about what they know. This can take the form of documentation, brown-bag sessions, or a post standup teardown of a problem they’re having.

How do you get your team to move faster?

I don’t know. Truly. I know what’s worked for some teams and some contexts, and what has failed in others, and I know there aren’t any silver bullets.

I spend my time working with enterprise software teams and helping discover what works for them.

We want methodologies to be the answer, but they’re not. Software is a human discovery and creation process; and it needs context to work. Methodologies lack context.

That’s why I focus on helping teams automate their hand-offs, and automate the mundane. Those parts can be streamlined without requiring a culture shift. And for many teams, speeding those things up results in a considerable boost in productivity. If you’re truly ready to have everyone outside of the team developing the software butt-out of the decisions, then you’re ready to adopt an agile mindset.

All software teams have bottlenecks and constraints. All software teams handle those constraints and bottlenecks differently. Agile teams try to reduce the bottlenecks by allowing only the team delivering the software to make the decisions.

For the rest of us, the teams that haven’t fully embraced an agile mindset, we still operate in this murky middle ground, and that murky middle ground is where the productivity gains lie. What bottlenecks and constraints does your team have? What processes add to those constraints? Do you have a way to automate those?

Lots of ink has been spilled as to why small startups deliver value faster than large companies, and I won’t rehash it all here. I’ve been a part of small startups, large enterprises, and everything in between (different sized product companies, services companies, and hybrids), and the companies that have moved the fastest had two things in common:

1. A shared vision that everyone understood (We exist to help X do Y)
2. There were either no seams, or the seams were invisible

In a cross-functional agile team, you would have no seams — everyone acts as one and delivers together; but in an enterprise where you have matrix’d reporting structures or traditional reporting structures, you would have visible seams. The UX designer reports to the UX lead, the Automated QA person reports to the QA lead, etc. Those QA testers may even be working for several teams that all have demands on their time.

You can remove the seam (go entirely cross-functional and keep a team on one project or product without splitting their time), or you can work to make it invisible through automating JIRA.

What would this invisible seam look like? (the pun was unavoidable, I didn’t see it coming) It may look like automated hand-offs between groups based on their workload and their availability. It may look like a warning when you assign an item to a person that they won’t have availability to work on it. It may look like JIRA suggesting a person to hand it off to based on their past work. It may be an automated email that let’s people know who have worked on that area before that your code is ready to review.

There’s a lot you can automate in JIRA to hide the fact that handoffs take place. Automating JIRA to hide the seams enables two major wins: 1) JIRA truly is a value-add to your organizational efforts, 2) your software fits your process which enables your team to focus on what matters: delivering value effectively.

Git is the most popular source control system in wide usage today, hands down. It’s also the unfriendliest source control system in use these days, hands down.

TFS and Azure DevOps have adopted Git as their default source control provider, and teams that previously had no experience with Git are now working with it, even though their previous default source control provider (TFVC or SVN) was a completely different animal.

Put those ingredients together, mix in a little frustration and merge conflicts, and you have $20,000 lost in productivity without realizing it, within in the first few months.

A cross-functional enterprise software team recently moved to TFS 2018, and along with it Git as their source control provider. The team was used to having long-lived individual branches for feature work, and they continued this practice with git.

Within a few weeks, however, they started to notice problems: changes that were previously in “master” (the default name for the centralized branch in git) were being merged out. As the team ramped up its feature delivery, this happened more and more. At first, they would reach out to the affected developer and ask them why their feature (that they thought was merged in) wasn’t in the delivered software. This kept happening.

Finally, one of the newer developers that it happened to asked other members of the team: What’s your branching strategy? “We have our own named branches that we use and we use the same branch for every feature” was the reply.

Ah ha! thought the new developer, that’s where the problem is. She proceeded to sit down with other members of the team and show them the problem. Git, you see, makes branches very lightweight — they’re effectively a post-it note at a certain point in the repository. Any new changes are also marked with this same post-it note, and when you’re ready, git will put all those changes right where that post-it note was, and then throw away the note.

TFVC can’t use post-it notes; it requires that you make physical copies of the files and make changes to those copies and then check each copy against its original and merge those changes together.

The problem — and the reason why the team was seeing conflicts merged out; is that it’s very easy and fast to move a post-it note to another point in the repository and tell git to start from there, but that’s not what was happening. The post-it note was staying at that very old place in the repository, and trying to check changes against that old starting point. If people didn’t move the post it note forward, git had a lot more work to do, and the potential for error increased.

The net effect was that every time the team had to stop and figure out how the heck those changes got merged out — if they even realized the problem was in source control in the first place — cost the team money. Delivery downstream impacts, developer time, cycle time as QA waited for new builds, all of that added up to — in some cases, a loss of $20000 per incident in productivity time.

The moral of the story isn’t to go out and buy git training (though it’s well worth it), it’s that the things that sap a team’s productivity and cost delivery teams money could be a mismatch between the process the team has and what the process should be for that team. In this case, the fix was a slight change in how develoeprs branched, an activity that took a sum total of a few seconds.

f you’ve read Col Boyd’s biography, then you already know what I’m about to talk about, and if you haven’t read Col. Boyd’s biography, add it to your list. Col. Boyd was a fighter pilot, the creator of the OODA loop, and also the architect of the Desert Storm Battle Plan. After he’d already led a pretty full life of being one of the best fighter pilots in the Air Force, he started to study a problem that had nagged at strategists: Why are some fighter pilots successful and others aren’t? How can someone in a technologically inferior aircraft beat a pilot in a technologically superior aircraft? Through his efforts, he figured out a theory that drove success and failure in dogfighting, and it’s a lesson that applies to successful software development as well: Some teams win because they’re able to execute the The Observe, Orient, Decide, Act (OODA) Loop faster than their competition. This is the success that Scrum tries to replicate, and one of the reasons why Scrum practitioners are assigned Col. Boyd’s biography. The value in the loop is how quickly you’re able to execute the entire loop for any given problem. For small teams, this is easy, there are very few people to take part in the loop. For larger teams — teams that can be helped through process automation, it’s much harder.

You can read more about the OODA loop here, but for our purposes we’ll tie that loop to how current ALM software works:

Observe – Put in Jira ticket
Orient – Team prioritizes that ticket (manually)
Decide – Team moves that ticket into the “sprint” (manually)
Act – Team member(s) complete that ticket (and hands off to other team members, manually)

The loop itself drives how quickly a problem is manifested and acted upon — something that successful software teams do is that they’re able move through those steps faster than other teams. This is important for all types of teams, not just product teams. If you work in enterprise software, you have necessarily long sales cycles, and it feels like the impact of your work won’t be noticed for 6-9 months — but that’s not the case. Internal stakeholders see your work daily or weekly, and being able to respond quickly to their concerns is important to build and maintain trust in the organization.

So why is JIRA associated with slowness in teams? Why is it maligned by startups and small product teams? Theoretically, it should be the perfect enabler of executing the OODA loop quickly. It knows all the information. If you’ve set up JIRA properly to track that information it knows what the impending ticket affects. It knows who can work on it (who has bandwidth), and it knows based on your past efforts whether that item is likely to get done. All of that data is sitting beneath the surface, waiting to be queried, and yet JIRA hides it.

Our teams need the ability to make reasoned decisions; and JIRA contains all of the data we need to make process decisions, and JIRA can be automated to help your team execute the OODA loop faster.

If you’d like to know how to unlock JIRA to help you make these decisions, hit reply and let’s talk.

Most times the first thing a team will automate is their build process. This is an easy target for productivity improvement, and is table-stakes for most (if not all) software teams. Then, teams will automate their deployment pipeline, and someone will wave a checkered flag and poof the team is now practicing “DevOps”.

Congratulations! There’s nothing left to automate, right?

Sounds absurd when I say it like that, doesn’t it? Like, we all know and feel there’s more to be done, but it’s hard to put our finger on it, isn’t it? The code part has been automated, the part the developers control by themselves is automated. Therefore, there must be nothing left to automate.

Put another way, left to their own devices, developers will automate everything they think can be automated or will improve their day-to-day work. Most developers, absent time and the ability to think deeper on the subject, would never think to automate the handoffs, or the tasks they do repeatedly but aren’t visible problems, or non-tech workflows.

We accept a certain level of manual intervention when we deal with JIRA because that’s what we’re used to. We’re used to developers manually creating their own branches, or manually reaching out to people who know that area of the code well, or manually letting testers know it’s ready for review, or manually de-assigning themselves items when it gets close to the end of the sprint, or letting the build notify everyone when it’s broken instead of a targetted alert to the person that broke it, or manually decide who needs to be in on a feature meeting.

Those things add up, and they add up quickly, but these things I list are automatable — and JIRA already contains all the information we need to automate these processes. What keeps us from automating it (besides not realizing it’s automatable) is that we don’t realize its effect on everyone on the team. How much of your day is spent responding to a code review request only to find out there’s one or two people on the team who have even worked on that feature previously? Or how we create hooks and automations to enforce branch and commit naming conventions but we don’t automate the creation of the branch itself; or automate the commit message itself? Or that we don’t automatically have JIRA send an email to the Project manager de-assigning lower priority items from a developer who is overloaded; and suggesting re-assignment to someone who has worked in that area of the code before and has bandwidth? If you use the ability to label feature areas in JIRA, then you already know who has completed work in which feature areas in the past, and boom, that’s a good starting point for a code review or a feature discussion. No need to spend human time figuring something out that the machine already knows.

In our next segment, we’ll talk about the underlying principles that cause this to be the case, and give a recipe to fix them.

I follow John Cutler on Twitter, and if you are into Product Management and developing a “Product Culture”, he’s worth your time to follow.

A “product culture” is one of those new-fangled movements that seeks to replicate the success of good product teams for everyone — even enterprises that may not develop products. Product Culture is the idea that a team, with all of the dependencies, authority, responsibility for outcomes, decision making, and execution contained within a single team, is able to deliver a far superior product or service than a team who does not have all of those components within the team.

You can imagine it this way: If you have to ask someone who is not a part of your team for something, then you don’t yet have a product culture. We’ll leave whether this is possible or desirable for another segment, but to give you an idea of what this visually looks like, John shared an image on his twitter account that captures this idea neatly:

Where does your organization fall? Leave a comment and share your thoughts.

It’s easy to get bogged down in the problems. We see problems every day. A never ending stream of problems.

It’s hard to remember that those problems are always going to crop up and it’s better for us to focus on turning them into opportunities.

The Build server is broken again. Tests are failing in the report suite again. Joe submitted bad code, again.

We have an opportunity to improve the build server. Let’s take a look at what makes the report suite so hard to test, and see if we can fix that. Joe, let’s take as look at what you’re working on. It may be you have a module with a lot of inter-dependencies. It may be that you don’t understand what the module does as well as we thought. It may be the module isn’t well documented. Let’s fix that.

There are no magic bullets to improving productivity wholesale; but there are indicators. A good first step is to see where the problems are and turn those indicators into opportunities.