Anyone with a basic knowledge of Scrum, and certainly everyone who has taken Agile Software Project Management With Scrum, knows the role of the ScrumMaster—to be a servant leader, to act as guardian of the Scrum process, to remove obstacles for the delivery team, to negotiate any tension between the Product Owner and the delivery team, to encourage the team to self-organize and be cross-functional, and so on. These are so well understood they’re almost clichés. The difficulty is learning how these abstract ideas apply to day-to-day software engineering.

For example, a common question is “Does Scrum permit a ScrumMaster with a technical background to help deliver features for the team he or she leads?” While this is a common practice and some teams have made it work, the general consensus answer is “No” or at least “Not ideally.” The primary reason is that a ScrumMaster can’t be an honest broker when resolving disagreements between the Product Owner and delivery team if he or she is writing code as a member of that delivery team. No one likes a conflict of interest, right?

However, there are other ways that a ScrumMaster with technical skills can apply them to provide significant value to the project and dramatically increase velocity without compromising credibility or the Scrum process.

Alvin Alexander is a renowned software engineer and author. His Scala Cookbook was invaluable when I got started with Scala, and that book and his prolific blog posts have remained essential reading even as I’ve gotten better at it. One of Alvin’s most recent posts, How Scala killed the Strategy Pattern, is the latest iteration of an old criticism of the Gang of Four (Go4) Design Patterns by functional programming (FP) advocates—that you don’t even need them if languages provide sufficient abstractions. In other words, the Go4 design patterns are only necessary because object-oriented programming (OOP) languages like C++ (the language they use in the book published in 1994) and Java demand them while FP obviates them entirely. Alvin’s post reiterates this theme by suggesting Scala “kills” the Strategy Pattern, which is one of my favorites because it promotes delegation over inheritance and is so obviously useful outside of the computer science department.

On this one, I really don’t agree with Alvin. Here’s why.

Vidya is proud to work with Webster & Fredrickson, PLLC, a law firm based in Washington, DC, specializing in the practice areas of whistleblower protection and employment, bankruptcy, and commercial law. Since the firm’s inception, Webster & Fredrickson has won millions for clients who have suffered discrimination, retaliation, harassment, and fraud at the hands of business and governmental organizations.

News broke recently that the Transportation Security Administration (TSA) contracted the development of an iPad app called the Randomizer that eliminates any hint of profiling by airport security by simply directing travelers according to an arrow onscreen that randomly points left or right. That’s it.

No, really. An arrow that points left or right. At random. Over and over.

The cost? $1.4 million.

Yes, that’s dollars.

Naturally, the Internet sprung into outrage. “OMG! $1.4 million?!!! For THAT???” I get it. That cost is absurd for what amounts to nothing more than a dream job for Two-Face.

The reaction was predictable. Add four cups of a smug Internet eager for an easy target, two cups of implicit assumption of widespread government waste, one cup of pervasive TSA resentment for making you take off your shoes when you’re running late, two tablespoons of a technology
everyone can understand, and one teaspoon of government contracting complexity, and you have a recipe for perfect Internet outrage. The app was so simple and the story so easy that The Late Show with Stephen Colbert and The Daily Show with Trevor Noah did bits on it. When it comes to public embarrassment, there’s bad, and then there’s late-night-talk-show-bit bad.

Of course the truth is a lot more complicated. The first shoe to drop was that journalists completely misunderstood the contract. TSA clarified that the $1.4 million figure refers to the entire contract vehicle. The amount dedicated to the Randomizer itself was a mere $47,400.

But isn’t that still way too much for an app that randomly points left or right?

Yes, but not by much and not for the reasons you might think.

At an event recently, someone was kind enough to introduce herself to me, and during the course of our pleasant conversation, she asked me, “So are you a programmer?”

My first impulse was to acknowledge once again that I look really nerdy. I embrace that. But my second impulse was to be mildly offended. I wasn’t sure exactly why.

As I have reflected a bit about that, I think my visceral reaction to being called a “programmer” arose from my perception of programmers as just people who write code, which is a science. That’s different from software engineering, which is an art.

As I help to revolutionize how government buys IT by teaching federal acquisition professionals to avoid spending hundreds of millions for deliverables that don’t work, I have stressed that the best way to maximize value and save taxpayer dollars is to understand the principles behind agile software development and to construct contracts accordingly.

Incentives (also called fee) have long been a significant part of government contracts—including contracts for software application development. When it comes to IT contracts, that needs to change as the government gets more agile. If you understand the core principles of agile development, it’s easy to see why.

Every (American) football fan knows that it is at least as important to know the playbook as it is to be blessed with speed, strength, and endorsement deals. After decades of failure with technology projects, including of course the high-profile debacle that was the initial rollout of HealthCare.gov, the United States government has taken steps to solve the problem. One of them was to create its own U.S. Digital Service Playbook, a guide to best practices for making technology work in government.

For me, this is personal. I’ve witnessed a lot of government technology projects fail because of some combination of incompetence, politics, and procurement methods that motivated shortsighted and suboptimal decisions. As the government begins to understand how to use technology to grow more efficient and yield more value to taxpayers, I want to play a role in that process. I’ve already written about the misunderstandings surrounding HealthCare.gov as well as a tactical overview of the Playbook for Government Computing News. This is a subject that has been important to me for a long time.

It turns out I am not the only one.

As promised earlier this year, we at Vidya are proud to officially announce our newest course Analytics with Apache Spark. Spark is a cool technology making an enormous—and growing—impact in the Big Data space, so naturally there are a lot of courses out there. Ours is different.

Naturally we spend a lot of time on Spark itself with numerous code examples and challenging exercises, but we also stress the importance of things that have always mattered and still matter—architecture, security, and software engineering concepts like unit and integration testing, continuous integration, and continuous delivery. Courses seem to ignore these concerns even though they are actually more important in a complex, distributed environment.

We even survey many of the other leading analytics tools out there so you can get a feel for your options and make informed technical decisions.

All of this distinguishes our Spark course from all the others. We hope you will consider it if you want to make your mark in the Big Data landscape.

Feel free to check out our other courses too—Software Engineering in Java and Agile Software Project Management with Scrum.