If you are a software engineer or run software projects, code coverage is probably very important to you. It’s intuitive. Of course more tests produce better software! It’s easy to calculate. Tools, automation, and stunning charts to impress the people who pay for the occasional pizza are all readily available. The problem is code coverage is killing you. Don’t get me wrong. You deserve credit for your agile commitment to quality and your investment in continuous integration and continuous delivery.
Functional programming isn’t exactly a fun topic anywhere outside of technical conferences and The Big Bang Theory. Even software engineers who love code often tune out when they hear terms like monad and referential transparency. But if you are a technical manager or executive, heads up. Functional programming will limit your technical debt so you build better software faster than you imagined and will earn you the Tesla you always wanted.
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.
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.
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.
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.
Please take a look at my latest column for Government Computing News where I discuss why Kanban might be an easier agile alternative for government IT projects having trouble with the rigor of Scrum. Just to give you an idea, here is the unedited introduction. Over the last decade, many have written about what agile software development offers to government IT. Their success has led to a GAO report, for which I was a contributor, on making agile work in the federal government and the U.
Please take a look at my latest column for Government Computing News where I explain how to apply the guidance found in the White House’s new U.S. Digital Services Playbook, which embraces agile software development and open-source for building better government applications. Just to give you an idea, here is the unedited introduction. Software engineering is my passion–not just the technologies but the art of building software the right way.
If you are a software engineer, you’ve probably been in a job interview where you were asked, “Have you ever used [Insert some awesome technology you may have heard of but certainly never used professionally here]?” You hear the question, and inside you’re basically like “Uh ohhh.” Your mind races for a reasonable response that won’t kill your chances. The best you can come up with is some sheepish variation on these: