Handy guide to Agile Software Teams in the Real World

So, you’ve graduated with your computer science degree and now you landed your first job! You’ve joined a true software industry (Silicon Valley?) company, which means you’re going to be doing agile! You might be wondering who is responsible for what on your new software team. Let me just translate that textbook understanding you now have a little bit to the real world, so that you can understand who is who when you see them!

Agile software team according to textbooks…


Why software teams that are on time and on budget probably suck

Many people in the software industry are bad at their job. Probably more than in other industries. Plenty of data shows the abysmal results of software projects, but you can simply ask your nearest software professional for plenty of horror stories. I have more than ten years of experience “on the inside” of the software industry and I have found bad software teams everywhere I look.

Bad managers have a disproportionately high impact on software because bad managers build bad teams, but the individuals on the teams themselves—even the good ones—are, more often than not, complicit in and even the cause of bad software. But what is most surprising is that bad teams are almost always rewarded for their incompetence. They “meet deadlines” so they are considered to have delivered “results.”

And what’s wrong with delivering results? . . .


Kotlin: Java Evolved?

Kotlin has been gaining some serious ground in usage the past couple years. If you haven’t checked out JetBrains’ language for the JVM, you should!

Not only does it now have incredible support and integration with IntelliJ IDEA, but it also has its own subreddit and a growing list of books.

At first glance, Kotlin is quite similar to Scala: right down to details like being able to define functions with blocks or even with an equals sign if it is a one-liner (see figure 1).

private fun add1(addend: Int, otherAddend: Int): Int {
    return addend + otherAddend

private fun add2(addend: Int, otherAddend: Int) = addend + otherAddend

Fig. 1 – Equivalent functions

But there are also some differences from Scala, even improvements! Kotlin defaults to non-nullable variables. To make a variable nullable, you have to explicitly define it with the “?” syntax. It also has a nice data class syntax.

In short, if you haven’t checked out Kotlin lately (or at all), you should!

Innovation – Excerpt from Peopleware

Excerpt from Peopleware: Productive Projects and Teams:

Innovation is a subject whose talk:do ratio is even more out of whack than that of leadership. Upper management in most companies talks a good game on innovation. The party line goes something like this: “We need innovation to survive. It is so important. Its importance simply cannot be overstated. No sir. Innovation is reeealy, reealy important. And innovation is everybody’s job. In fact, it is probably the most important part of everybody’s job. Listen up, everybody: Get out there and innovate.” Oh, and by the way,

  • Nobody is given any time to innovate, since everyone is 100-percent busy.
  • Most innovation that happens anyway is distinctly unwelcome because it requires accommodating change.
  • Real innovation is likely to spread beyond the realm of the innovator, and so he or she may be suspected of managing the organization from below, a tendency that upper management tends to view with great suspicion.

The net here is that it takes a bit of a rebel to help even the best innovation achieve its promise: rebel leadership. The innovator himself doesn’t have to be a great leader, but someone has to be. What rebel leadership supplies to this process is the time to innovate–you take a key person away from doing billable work (This may constitute constructive disobedience on your part) in order to pursue a nascent vision–and the hard push for whatever reshaping the organization has to submit to in order to take advantage of the innovation.

Since nobody ever knows how the next innovation may alter the organization, nobody knows enough to give permission to the key instigators to do what needs to be done. That’s why leadership as a service almost always operates without official permission.

What to do when Github is down

Unicorn! What is that? I guess Github is down everyone. So now what do you do?

Here’s three ideas:

1. Catch up on reading
There is always a book that you want to get to but can’t seem to find time for. For me this year it is Manning’s Functional Reactive Domain Modeling. For you it is probably something else. Either way you just scored some time for reading!

2. Create a professional development plan
If reading isn’t your thing right now, consider creating a professional development plan. Yes it sounds kind of business-y and conjures visions of straight-laced board room suits, but even software engineers can benefit from charting out a plan for how to improve this year.

3. Learn a new language
You don’t need source control to start learning something new. Of course I highly recommend that you learn Scala but how about Go or Kotlin? The truth is that seeing how other languages handle things can produce some real insights.

Happy No Github Day!