I Can't Agree with Advice to Specialize

I follow John Sonmez from simpleprogrammer.com. His latest post "I'm Not Sure I Want to be a Specialist" got me thinking. John says:

"I’m definitely ... going to tell you specialize ... It’s going to be very hard to narrow yourself down so much that you’re pigeonholed into a place where you’re not going to have customers, especially if you’re just looking for a job."

I just don't agree. There are plenty of technologies that developers might have specialized in that just aren't in use anymore - the digital equivalent of buggy-whips.

Certainly some specialists have fantastic success, but aiming for that kind of success feels like aiming for a career in the NBA. If you are one of the few who can, that's great. But it's not the kind of advice I'm going to give out as a mater of course.

Specialization has real risks, for individual developers and for teams. For instance, as I mentioned, if I specialize in a technology that goes out of favor, my employability declines, potentially seriously.  Additionally, teams of specialists can face roadblocks when a particular type of work piles up faster than the team specialist can complete it. Or worse yet, when a team loses a particular specialist, predictable team capacity, a critical value for project owners, can tank until a replacement can be found and ramped-up (see Bus Number).

My employer, a consulting firm, seeks "Generalizing Specialists", developers who:

• have one or more technical specialties
• has a strong general knowledge of software development lifecycles
• has at least a general knowledge of business and a willingness to gain at least a minimally functional knowledge of their client's business domain
• actively seeks to gain new skills in their specialties and beyond, in technical and non-technical areas

If the team I am on suddenly needs an an extra push in QA, I am comfortable enough with testing that I can temporarily shift my responsibilities.

My advice to developers is: "Specialize in one or two things, stay on top of market trends without following fads, and always be learning, in your specialties, in tech areas you don't specialize in, and in non-technical areas."

How JIRA Helped Our Team

A colleague at a different client asked about what out-of-the-box JIRA reports we use and how they benefited our team.

Whatever you think about physical card walls versus electronic tools, the fact remains that some teams use them and JIRA is a common one.

Like many good charts, many conclusions can be drawn from the reports below. I have explained one or two specific benefits that my teams have reaped from them:

Burndown: We used it to track daily movement of cards (or lack of same) at standup and it worked to identify that developers we incurring risk by working on individual cards for several days.

Sprint Report: We used it to look at what work was added/removed from the current sprint, and what cards were finished. It worked because it enabled us to detect that developers were pulling work ahead while there were still incomplete cards in the sprint. This gave us an opportunity to have a conversation about swarming to get cards over the finish line and breaking down silos.

Velocity Chart: We used it to to compare committed/completed of current sprint verses past sprints. It worked because we detected a trend of increasing overcommitment and the team was able to adjust sprint commentments so that PMs had better projections and the team reversed the growing feelings that they were failures.

Version Report: We use it to project when our project will be finished. It worked because the PM learned that the team was not going to deliver all the scope by the needed date. The PM and the business were able to agree on reduced scope and the version report projected a good delivery date.