Year: 2015

Posted on by

Using programming problems to screen technical candidates

For some reason, the majority of technical interviews consist only of talking. Sometimes there’s a written quiz of some sort. Rarely, there’s a programming challenge; typically the candidate is free to complete the challenge on their own, in any amount of time whatsoever, in any manner whatsoever, with no opportunity for the interviewer to observe the candidate’s thought process or methods.

And yet, there’s general agreement that professional software development is a team sport involving collaboration skills as well as technical knowledge, and that software isn’t written once and discarded, but rather must be “habitable” for many years into the future. Weak screening methods don’t separate people who can handle that kind of work from those who can’t.
Continue reading Using programming problems to screen technical candidates

Posted on by — 1 Comment

Impedance and Software Delivery

Impedance is a term borrowed from the hard sciences and applied in a loose fashion to other domains. When we use terms in this way, like inertia, momentum, or velocity, they can provide a useful analogy or metaphor for an aspect of social sciences or other disciplines (possibly including software delivery) that helps explain a concept or principle. The problem is that people take these terms too far when they are used outside their intended context. Analogies and metaphors are useful only up to a point.

Continue reading Impedance and Software Delivery

Posted on by — 5 Comments

Bringing TDD and automated testing to the mainframe platform

Can contemporary lightweight software development and delivery methods “scale” in large enterprises without appropriate support for the venerable IBM mainframe platform? Thought leaders in the “agile” community seem to think so. For example, this proposed session on code isolation and automated testing for mainframe applications received almost no notice from the review team for the Agile 2015 conference. The two reviewers who noticed the submission seemed not to understand what it was about, or to see any relevance or usefulness in it.

It’s true that some large enterprises don’t have mainframe technology. Apple, Google, Amazon, and a handful of others built their businesses in an era when alternatives to the mainframe were plentiful. Those companies tend to be relatively uninterested in “agile” and “lean” methods, as they have come up with their own ways of doing things, and their financial position doesn’t lead them to believe they need to change. They’re probably right. If they were “dysfunctional” they probably wouldn’t be doing quite so well financially…a minor detail often overlooked by enthusiastic change agents.

However, the majority of larger enterprises have been around for decades. They have used computer technology all those years. The general pattern has been to layer new technologies on top of old rather than to migrate applications. Name a large bank or insurance firm that doesn’t have a significant investment in mainframe systems. Now explain how you would bring agility to those organizations just by setting up a few Scrum teams, applying good technical practices only to the outermost layer of their technology stack, and ignoring technical practices and tooling on the mainframe platform.

Continue reading Bringing TDD and automated testing to the mainframe platform

Posted on by

Feature teams and vertical slices in a large corporate IT environment

The idea of a feature team that incrementally delivers vertical slices of application functionality is central to many “agile” software development organizations. A feature team possesses all the skills and resources necessary to deliver a customer-centric software feature end to end. How feasible is this model in a large corporate IT environment?
Continue reading Feature teams and vertical slices in a large corporate IT environment

Posted on by

The accordion game

As a middle manager in a large corporate IT department, you feel as if

  1. you are in the middle of an accordion
  2. and the accordion is being played by a monkey
  3. and the monkey has taken some sort of unknown street drug
  4. and the strange music the monkey is playing makes no sense to you
  5. and your bosses think the monkey is a genius
  6. and your subordinates think it’s all your fault
  7. and you don’t see how it could possibly be your fault
  8. and you’re not even sure what “it” is.

You never know whether your job will survive the next re-org. Furthermore, you’re not even sure that your job adds much value to the organization: In a nutshell, you (a) take direction from above and disseminate it downward, and (b) collect data from below, compile it and report it upward. You don’t know how to run the business from the top. You don’t know how to do the hands-on work at the bottom. You have only a vague idea of what’s going on. You can’t trust any of your peers. What will happen to you if your present position is eliminated?
Continue reading The accordion game

Posted on by — 8 Comments

The mother of all management anti-patterns

My book on software development metrics is in the final stages of editing. The editor made a kind comment about one section of the book. She wrote: “This section is marvelous. I wish all management everywhere would read this and pay attention.” Me, too. This is the section:

(begin excerpt)

This may be the mother of all management anti-patterns. Management science has treated human beings as interchangeable machine parts at least since the time of Frederick Taylor’s “scientific management” in the early 20th century, and possibly much longer than that. Even today, many managers loosely refer to workers as “resources” without realizing the implications of the word.
Continue reading The mother of all management anti-patterns

Posted on by — 2 Comments

Komm süße Todesmarsch

People who’ve been in the IT field for some years tell tales of the bad old days when every project ended in a Death March. Well, actually, no one died. Truth be told, no one marched, either. But we called it a Death March. Some call it the Death March Antipattern. It was, in fact, one of the reasons people became interested in exploring alternative approaches to software development.

Younger professionals have managed to avoid the Death March Antipattern, for the most part. When oldtimers tell their tales, many of the younger folk react as if they were hearing Monty Python’s Four Yorkshiremen sketch, in which four retired gentlement reminisce about the difficulties of their youth: “There were a hundred and sixty of us living in a small shoebox in the middle of the road.” “You were lucky. We lived for three months in a brown paper bag in a septic tank.” “But you try and tell the young people today that…and they won’t believe ya’.” “Nope, nope.”

But it was real. On a typical 12-month software development project, the first ten months would be spent preparing useless documents and snoring through useless meetings. With the deadline looming, the team would scramble to get as much of the work done as possible in the remaining few weeks. It meant working 24×7 until you delivered, and then crashing for a few days. That was the Death March. And it had much in common with modern-day “agile” development practices.
Continue reading Komm süße Todesmarsch

Posted on by

What skills does a technical coach need to have?

What skills does a technical coach need?

One of the goals of my present coaching engagement is sustainability, defined as the ability to continue with the improvements after the coaches are gone. To that end, we’ve been identifying internal people who have the potential to become effective technical coaches. One manager asked us for a short list of key skills that a technical coach ought to have. Answering that question has been quite a challenge. It occurs to me that other people may be asking the same question, so it might be useful to discuss it publicly.
Continue reading What skills does a technical coach need to have?

Posted on by

(!Scrum) != Scrum

This post by Thomas Schranz caught my attention: Why SCRUM Backlogs lead to bad Product Decisions. One finds numerous articles against Scrum on Thomas’ site. I think he misunderstands Scrum fundamentally.

Is my purpose here to defend Scrum? Friends and colleagues will know that I’m not a Scrum salesperson. I see Scrum as a tool, and not as the answer to the ultimate question of life, the universe, and everything. So, why defend it? My purpose in this post is to caution against blaming one’s tools for one’s results, and to suggest that we try to understand a thing before we criticize it. (I don’t claim to be a flawless practitioner of my own advice.)
Continue reading (!Scrum) != Scrum