Do you suspect that your company’s commitment to agile consists of jargon and sloganeering, as opposed to actual organizational and cultural change? Then you would do well to refer to this pamphlet on Detecting Agile BS (pdf) produced by the Department of Defense’s (DoD) Defense Innovation Advisory Board (DIB) in October of 2018. The DIB established itself to bring the best practices and innovations of Silicon Valley to DoD software development. The pamphlet was the result of luminaries such as Eric Schmidt, Reid Hoffman, and Neil deGrasse Tyson coming together turning their gimlet eye towards true agile practices in DoD software development.
I’ve excerpted some interesting parts of the pamphlet below and tied in some of my perspectives based on my current TeraThink project at U.S. Citizenship and Immigration Services (USCIS). Full disclosure: TeraThink is a for-profit company, and as such is not 100%-free of BS. However, I like to think we have less BS than most. I’ll detail why through highlighting key flags that a projects is not truly agile.
In an earlier blog, I wrote about a couple of takeaways regarding improvements to the ServiceNow platform from our trip to Knowledge18, Those weren’t the only key takeaways from ServiceNow’s annual conference. There was a lot of focus on improving the user experience for both the producers and consumers of ServiceNow’s features and value. Having seen many projects succeed or fail based not upon features but upon user experience, this was exciting to see.
In May, my colleagues and I attended ServiceNow’s annual conference, Knowledge18. We joined over 18,000 attendees in Las Vegas to meet, learn, share, and collaborate on all things ServiceNow. They presented a wide range of valuable content spanning all aspects of the platform. This ranged from in-depth solution-focused sessions, to industry-based workshops, to a roadmap of functionality coming to the platform.
Two of my takeaways from the conference centered on the platform improvement and their increased focus on the customer.
This year marked the 15-year anniversary of the writing of the Manifesto for Agile Software Development. Today, I can’t help but marvel at the impact this collection of simple, yet elegantly stated principles continue to have, especially here in Washington, D.C.. Agile has not only changed how we build working software, it has fundamentally changed how we understand our organizations and how we define the business value we produce. With agile, many of us have learned new approaches to prioritizing our work at an enterprise scale, how we can organize our businesses, and even how we can build deeper relationships in the process. Agile development has sparked a new wave of innovation, especially in the Federal market and it’s incredible to think what 2017 will bring.
For those who are doing it successfully, being agile requires the adoption of both an agile-mindset and the incorporation of new software architectures and delivery practices. At TeraThink, we recognize that our clients have very specific needs and objectives for their implementation of agile solutions. We work closely with each client to provide their desired results. Agile is, of course, not without its challenges. Whether it is initial adoption, sustaining agility at scale, or breaking into a more effective CI/CD model, these challenges are significant. I’d like to share a few key observations and strategies that have helped our clients hit their stride with agile.
Over the past two years, organizations of all types and sizes have adopted the agile methodology for the delivery of projects in some or all of their programs. While many are recognizing successes and tangible improvements from agile software development, many others are either struggling with their implementation of agile practices, or are simply not reaping the benefits that they could and should. In our experience, there is no “one size fits all” agile approach or implementation, and it is important for organizations to recognize that fact and adjust how you use agile to fit your programs and your processes. Also key is setting realistic expectations and defining specific goals for your agile adoption, and not simply expecting agile to solve every challenge or struggle you have in your software development process. Through your agile implementation planning, we encourage you to be cognizant of a handful of common pitfalls that we have seen contribute to marginalizing our clients’ agile implementation success.