DevOps is dead! Enter the Modern SDLC.

Okay, I tried my hand at a sensationalist title, and I have to admit, it does grab you, right!?

The truth: DevOps, in its truest, original form, is dead. We are living in a time where DevOps is no longer a goal, but a reality. I know what you're thinking, "this guy, c'mon!" Stick with me here -- why else would you be reading about all of these weird variations: DevSecOps, DevSecQaOps, and AIOps, just to name few? Organizations and teams have already, or are well on their way to, adopting a model where their development and operations teams are communicating more and integrating more than ever before. I would even go as far to say, in smaller organizations, operations teams are non-existent and development teams take the full SDLC burden. This can lead to exceptional results if executed correctly.

What is "DevOps," anyways!?

A question that many business leaders are still asking today. The term has always been muddied from different perspectives. I'll keep it simple: it's about joining people and process together to accelerate product delivery while maintaining quality.

Buzz words, I know, but what does it mean? Most organizations struggle with large, immovable, archaic structures: the department. You want someone to test it? Ship it to the QA team. You want someone to release it? Ship it to the operations team. You want someone to build it? Ship it to the development team.

Don't get me wrong, these structures can work incredibly well if you don't have a customer you want to keep interested, or if you can get away with a 1-year release cycle. Unfortunately, most of us don't live in that world anymore. The window to failure and success is drastically shorter, and we need to keep our customers (read: 💵) happy and using our products.

Enter the Modern SDLC

Software is eating the world. —Andreessen Horowitz

Every business and every one inside that business is involved with software, whether they know it or not. Businesses must adapt our process for this new, modern software development lifecycle (SDLC).

Developers must know and retain more information than ever. Even more challenging, that information changes every single day. It's no longer good enough to simply know how to take a basic idea, develop some piece of code, and then "ship it."

A modern software development team must:

1. Know how the business works, understand what it wants, and how to push back when necessary.
2. Know how to convert requirements into working software.
3. Know how to test their own software.
4. Know how to secure their own software.
5. Know how to operationalize their software.
6. Know how to release their software.
7. Know how to monitor their software.

And there will be more as time goes on!

Previously, in most organizations, developers were only concerned with #2. There was a team or process for everything else external to them. This is unacceptable with the Modern SDLC.

Further, notice how all seven of the points involves every team member, not just developers. A modern team must include every single person needed to take an idea from whiteboard to release or else that team will fail.

That failure can take on many forms, but one of the most common and overlooked is slowness to market. Some might not even consider this failure.

The Modern SDLC Framework

The Modern SDLC is all about bringing people and process together to accelerate product delivery while maintaining quality. Sounds familiar, right? How can we bring people and process together, just in time? You may not need an architect or security experts hanging around all the time. So, your modern team must be able to bring them in just when they are needed, get something accomplished, and then head out to their next thing and stay productive. This allows a modern team to plan effectively and keep the product delivery on time and on budget.

Areas of continuous action

A modern team should always be continuously doing something in all 5 of these areas. There is a part to play for every role. The mind-set of continuous is one that a modern team must always be in.

1. Continuously Planning
2. Continuously Developing
3. Continuously Testing
4. Continuously Releasing
5. Continuously Monitoring

Continuously Planning

Being able to bring the right people in at the right time is all about planning. One or more people should be dedicated to doing just that and making sure that along with the amount of work they have to do.

Part of continuously planning is a modern team must first acquire and understand their backlog. Start with big chunks and keep breaking them down into smaller and more manageable pieces that can deliver value while not throw the team into a tail spin if something goes awry.

A team should be adding to and grooming their backlog on a regular cycle. Every person on the team should be involved in fine tuning each item in their backlog. For efficiency, it may make sense to only involve business owners and technical leadership at a high level and then involve the whole team once planning takes place.

When the team is fine tuning a backlog item, all parts of the process should be kept in mind to ultimately end at "what does success look like?"

1. Do we understand the business need?
2. Do we understand how to technically develop it?
3. Do we know how to test it?
4. Do we know how to release it?
5. How do we know it's working right, or not working at all when released?

Notice how these 5 questions align with the 5 major areas above. Depending on the team and how mature they are, they could have a set of questions, similar to a Definition of Done, to help them through their process so nothing is ever missed.

Once these are thoroughly answered and laid out for the item, then it should be ready for the team to develop it.

Continuously Developing

A modern team should always be producing. The production rate is not, and cannot be, constant. It may not even be increasing sometimes, and that's okay! A team needs the freedom to go up and down as different demands need to be met. Onboarding, offboarding, and several other factors are major production hurdles that should be allowed for and be accepted, but communicated and planned for.

The modern team should be developing out readied items from the backlog. Each developer on the team should be able to pick up anything off the backlog and work on it. This is the ideal state, and never truly realized in practice, just like 100% code coverage doesn't exist. Understand it's an asymptotic goal that you should always strive for, but will never reach.

An aside: if a team finds themselves where they have hard partitions, or knowledge gaps, in domain where only certain people can work on certain things, then they should look into cutting their team at that partition and creating two teams that can work more harmoniously.

Continuously Testing

A modern team does not ever hand off unfinished code. Unfinished code is anything that a developer or team is unsure of. They should be 100% confident that they have tests which pass every single acceptance test before handing it off to anyone else. Further, a modern team should also be running tests on every single code change, on every single pull request, on every single release. AKA continuously testing.

Now, I'm not naïve. I'm a realist. Some companies still need QA teams and other testing-type teams because of regulatory measures or some other type of bureaucracy which will not be going away anytime soon. So what is a modern team supposed to do? They treat the hand-off like a production release. Any bugs that may come back will be treated like escaped production-level bugs.

Which brings us to our next point on testing: how does a modern team handle bug triaging? The team should have a defined process around how to intake bugs, determine priority and severity, and then based on that criteria, determine to prioritize and fix immediately or add to the backlog as if it were a regular backlog item. There should never be a question or too much grey area around what a bug is or should be, and always caution to the side of more severe.

Finally, how does a team test that their code is secure? Security testing comes in many shapes and forms. You can follow best practices and hope your product is good when you release it, or you can buy expensive tools to validate it for you. Most teams will fall somewhere in the middle depending on what their product does. As with other parts of the value stream, security needs to be thought of at the forefront of planning. Modern teams realize that they should be catching security issues as early as at development-time, but also add more and more testing as they promote their code through environments into production. This may include deeper penetration testing, if their business case calls for it.

Continuously Releasing

A modern team should always be releasing. The team is always releasing one-item at a time. The items should never put anything at risk other than the item itself. Rollbacks should be trivial, but rarely executed. I can recount on a single hand the number of times I've had to rollback on any given product team. It's a fallacy to think rollbacks are commonplace and that you should prepare for them. Instead, roll-forward! It's easier.. and if you are at this step in your continuous journey, then most likely it'll be easier.

Take special attention to what I'm saying. I'm not saying the modern team is always releasing to production. No! They are always releasing to an environment. It could be production, or it could be an integration environment of some sort. As mentioned above, some companies have regulatory constraints, so they must have an external team verify it.

How does a modern team setup their environment infrastructure, anyways? As part of bringing people and process together, the team can't wait on someone else to provision and secure all of their infrastructure. This is bad and will cause us to fail! Instead, the modern team takes ownership of their infrastructure and instead lets policy guide them to scalable, secure, reliable infrastructure. These policies should be governed by best practices and other internal and external factors decided by the company. Ultimately, the modern team is responsible for it.

Continuously Monitoring

This is the most nebulous of all the principals in a modern team's continuous journey. Teams love to stop just short of this and think they've done it. They are planning, developing, testing, and releasing their code all the time with few defects. BUT! They have absolutely no idea how their product is working with their customers, and thus have no idea if their customers are happy or not. They only have implicit data based on their cash flow.

Modern teams should be thinking and building for an operations mindset from the beginning in their continuous planning. Afterall, how can you know if you are successful without monitoring?

Continuously monitoring goes hand in hand with continuously releasing. Teams can have automated gates in place in their pipelines so that it checks metrics for quality results before allowing it to move forward. Teams can run a battery of system tests which verify functionality, as well as load, of your system and monitor it during the process. If it ever crosses a threshold, the release should fail for further review.

Modern teams must be able to see real-time metrics so it can scale or see impending problems sooner. Some teams may go as far as setting a real-time dashboard that sits in their team room, or have it readily available for people to look at every day. It should always be on the top of each member's mind.

Finally, modern teams understand that "shit happens." You can plan for the worst, and something will break. Statistics have my back on this one. So, teams should plan for it. What if your database mysteriously goes down, then what? What if that 3rd party service decides to quit responding to you, then what? Teams should plan for all of their dependencies to fail, and have a way to handle it. Sometimes, it may just be to throw up the white flag and say you're down and then press the big red button. Other times, it's possible to work around it, add something to a queue, and process it later.

In Conlusion

Modern teams must start on their continous journey and never end the cycle. It's...continuous! Teams must fulfil and be responsible for all parts of their product from start to finish, with no boundaries, and eliminate as many external dependencies as they can so they can be in control of their own destiny.

The future is now, and the truly modern team will be leaner, meaner, and release quality products to their customers in faster times than ever before!