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.
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.
I was recently at an event hosted by the Agile Leadership Network of DC (ALN) called Reflective Retrospectives To Build High Performing Teams. It was an interesting presentation with a highly credentialed speaker–Certified Agile Coach, ITIL, PMP/PMI-ACP Coach, Protector of the Realm, Breaker of Chains, and so on–but what really struck me that evening was a question from the audience. The question came from a fellow software engineer, who began by noting that ALN events typically engage executives and managers rather than engineers, and can be paraphrased this way:
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.
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.
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.
I have written quite a bit recently about my longstanding passion for improving the way government procures technology and manages technology projects. The administration has taken many significant steps toward that goal, and I have played a small role in the process to this point. But that role is about to get a lot bigger. As I wrote before, the Office of Management and Budget (OMB)–the largest office within the Executive Office of the President of the United States– challenged us to improve how government “builds and buys digital services.
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.
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.
I spent most of my career building software for U.S. government clients as a contractor, and one thing I noticed is just how bad the government is at running software projects. Take every bad thing every commercial software project ever did in the 1990’s, and it was built into the government software development process. It’s like modeling every high school after Bayside High. Eventually, everyone else caught on with the infamous rollout of HealthCare.