Here at Terathink, we are working with a large government agency constructing a content services platform. This platform allows content generated by benefit applications to be shared and reused across the organization’s disparate IT applications. We are doing this through the use of application programming interfaces, or APIs.
Our agile development team manages our work using a Kanban approach, from requirements gathering to the deployment of the API to a production environment. We have honed our use of Kanban to most effectively manage the work required to take a user request to functional reality.
As success with DevOps continues to make progress, it ventures into taking on other areas where traditional SDLC / IT practices have been less than optimal. Alongside this need, the IT Security technical landscape has been in rapid transition, making it near impossible for security teams to keep up with both increased DevOps velocity and the changing security landscape. Now, teaming up security in the continuous integration (CI) and continuous delivery (CD) model has a potential to be a game changer.
In the beginning, the movement started out being called DevOpsSec. ‘Sec’ was appended on to the end – almost like a caboose on a train – an afterthought. But in reality, security must be thought of, designed, and practiced throughout the process. In light of this, the more current term is DevSecOps – one where we weave security into our integration. Originally, marketing hype from each security software vendor clouded the concept. But, the movement is less about tools, and more about the way in which we work together, in parallel.
Here at TeraThink, we are currently building an internal application that will allow us to better track new business opportunities. Simultaneously, we are exposing more of our staff to agile and continuous integration/continuous deployment (CI/CD) principles. Among the many concepts we are trying to inculcate in our team is the “layer cake” user story.
The layer cake idea has been around for over a decade. However, I’ve found on nearly all agile engagements that I’ve been on, teams either discard this idea early in the project or completely ignore it from the outset. It is up to the triumvirate of the Product Owner, Scrum Master, and Business Analyst to ensure that the scrum team writes user stories in such a manner that the outcome of each story is working software that delivers tangible value to the end user.
You’re an experienced Scrum Master beginning a new project. You meet with your Product Owner (PO) for the first time and hear him or her say any or all of the following:
- “I’ve never worked in this role before.”
- “I’ll do my best to be on-site as much as possible.”
- “I’ve completed Certified Scrum Master training, but I’ve never applied it in practice.”
- “I’m the Product Owner for your team, and nine others.”
Your spidey sense is now tingling. You are going to be working with an inexperienced and/or overextended PO. Fear not, however. Here are some methods and remedies you can apply to get your PO up to speed.
A few years ago, I started introducing Definition of Ready to help alleviate a common challenge I was seeing. User stories were coming into the sprint with little information and weren’t making it to Done. The team spent more time talking to the Product Owner about what they wanted than developing it.
As an agile enthusiast, I was aware of the latest updates to Scrum guidelines and introduced Definition of Ready thinking this will solve our problem! I met with the team, setup a few guidelines as reminders of what should be in a story, we were set! Over time, through retrospectives, these guidelines morphed into something I started to realize no longer made us an agile team.
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.
I used to be part of the “non-believers” when it comes to agile software development. I’ve since converted to an agile evangelist of sorts, and appreciate the significant benefits the agile approach has to offer. While my own conversion was not so easy, I’ll explain the transformation, what I consider to be the key program management benefits associated with the agile approach, and a few challenges that I think still remain.
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.