Let's start off today by looking at the following diagram I created. You are looking at an SDLC (Software Development Life Cycle). If you are new to the engineering gig, the SDLC traditionally is the process used by software engineering teams to design, develop, test, and deploy software. If you are a seasoned pro at engineering, then you will notice that this SDLC seems to expand the purpose of the SDLC to include additional items. This article is all about why the SDLC isn't just a development and deploy process but rather implementing the 360 degrees of building software. And I should state, that by no means do I intend this 360 SDLC diagram to be exhaustive. On the contrary, this 360 SDLC is a representation of how engineers should think about software development and the life cycle that fits their business may look different than the one represented. That said, this 360 SDLC is a good place to start for any engineering leader.
Let's start with a scenario. You are the engineering leader of a team. You have been producing software on your team for a couple of months. You think things are going well. Heck, you are running Agile Scrum, you are getting features into production, your team seems happy, and you are just about to load up another sprint of features you have been dying to produce. And then it happens, the CEO or whomever happens to be your supervisor starts asking some questions. These might come up like:
Are we working on the right things?
How much work is getting done on your team?
Where are you at on the latest project and why is it taking a long time?
How can you be sure that what we are producing has quality?
Why is it that after we have a release that the support desk lights up?
And there you are, thinking things were great, but none of your greatness or your team's success is making its way to senior leadership. In fact, they seem more concerned than pleased. When we are working only from a standard SDLC and methodology we might be missing out on the goodies that are naturally produced during a cycle of development. But these goodies can only be harvested if you understand business needs, product management, support management, and software development. If your missing one of these then its possible that your SDLC is narrowly focused on only building software.
The traditional SDLC
As I studied the traditional Software Development Life Cycle, and especially as I started implementing the SDLC, I realized that on its own it doesn't cover all the 360 degress of software development. There are many representations of the SDLC but here is an example of the traditionally recommended life cycle:
Before I go on, let me say that I one-hundred percent agree with this life cycle. In fact, I agree with practically all of the purported life cycles. I am merely suggesting that when we consider our processes we not limit ourselves to just the development processes but expand our vision and consider all the inputs and outputs to a system for software development. In this way we discover artifacts, tasks, and metrics that lead to tools, relationships, and many deliverables that will benefit the the company.
Overview of the 360 SDLC
Let's breakdown the components of the 360 SDLC. First, if we only look at the steps in the process then we get an image that looks like this:
These steps represent the major events in producing software. Notice that this life cycle has three different colors. These colors represent engineering's responsibility to work with departments outside of their immediate responsibility. Yellow represents the work done with the product team and blue represents work done with the Support team. Green represents the events directly associated with the engineering team. One of the first lessons a engineering leaders should learn, is that they are part of a larger ecosystem of departments and that they have duties to that ecosystem as a whole. If we accept that as the case, then our life cycle should reflect events with other departments.
The Yellow Events
Looking at the two yellow events, Backlog and Plan. Engineering collaborates with the product team to keep a backlog that can be groomed and prioritized. It is essential before any planning is performed that features are understood and organized. We must be aligned with our customers and aligned with marketing before we strike out on the next sprint. I have experienced many times when people have come either directly to engineering asking for work to be done which by passes the backlog. Or sometimes a project is started and planned but never compared to the other projects in the backlog to ensure we are working on the best priories. Engineering helps ensure that proper product management is taking place.
The Blue Event
The blue event is shared between engineering and support. Engineering must understand that being "done" does not simply mean that the product has been deployed, but rather "done" means that customers are effectively using the deployed software without significant problems. We need to realize that the part we play in the maintenance of the software. When companies have a support team, that team must understand the details of every deployment so they can support the questions that inevitably come from customers. If the support team is unprepared, then they may misinterpret a customer's confusion with a bug and escalate the issue to engineering to deal with the customer. This misunderstanding causes delays on the engineering side if they must evaluate every bug and determine if there needs to be a fix or not. I recommend making maintenance part of the life cycle so that proper deployment documentation and training is done at each release. Also, when engineers pay attention to their code after a deployment, they can often head off unforeseen concerns or issues before they arise and can remedy a situation before a bug needs to be filed. Finally, when engineering accepts responsibility for the maintenance event, they often pay closer attention to details during unit testing, integration testing, systems testing, and smoke testing which drives a higher degree of quality into the product.
The Green Events
The remaining events on this life cycle are green and represent the actual build, test, and deployment of code. This is where engineering is naturally drawn and obviously you cannot produce solid software products without these components.
The Actions of the 360 SDLC
I have added actions to the SDLC diagram. Actions in the 360 SDLC should represent the actions taken at each step. I have added some common actions that most processes need but you feel free to add actions that make the most sense for your business. When adding actions you should have a couple of questions on your mind. One, what does it take to build software in a solid process at my company. Two, what metrics or KPIs should I be delivering during this process?
With these questions in mind, you should be able to craft actions that will easily lend themselves to a smooth process and to creating metrics. This is also where you may get the most push back from your teams. After all, who wants to be measured constantly. In these situations, I recommend that you take the high ground and let everyone know that modern best practices use smart metrics to inform the team and the business about the effectiveness of the processes. And reassure everyone that metrics are not to be a used as a penalizing stroke against an engineer. But just the opposite, they elevate the engineer by showing off their work and give everyone a target for improvement. The only time I use metrics to confront an engineer rather than encourage them is if the engineer is not performing the actions that will produce the metrics. Actions are an enormous part of the actual SDLC.
Adding in the Artifacts
Once you have the actions that take place at each step of the SDLC you start forming an understanding of the artifacts that need to be produced to get the work done. Artifacts are the parts of a project that can usually be represented in a tool as a ticket or issue. In this 360 SDLC representation, I have selected six artifacts listed in the diagram.
Most of these artifacts can be represented easily in a work management tool such as Atlassian Jira. I recommend that new features are first collected as stories and kept in a backlog. Stories and a backlog are natural features in Jira. As the backlog is groomed these feature stories will become part of a project. The project can be represented with an Epic or a Project in Jira. During the planning phase the stories are discussed with the engineers who break down the work and create a series of tasks to perform. These tasks are also represented in Jira and are tied to the story. Tasks are also a good place to capture engineer time estimates (or story points) for each task. Using a work management tool you should be able to construct a sprint and kanban boards for monitoring and organizing the work. The tasks will have certain statuses that an engineer will use to represent the progress of the build, test, and deploy. The work management tool can also produce KPIs and metrics which will be discussed later.
As the tasks and stories are completed, they become part of a deployment or release. At this point, documentation should be produced. Documentation should contain at a minimum deployment notes or instructions explaining the purpose for each feature or fix. This documentation should be shared with other departments and leadership.
Finally, as the deployment moves into the maintenance phase, issues and new features will be generated in concert with the support and product team. Which then load back into the SDLC and become part of future sprints.
KPIs and Metrics
Unfortunately, engineering leaders sometimes forget or ignore to build metrics into their SDLC. For this reason, I consider metrics to be part of the SDLC from the beginning. Experience has taught me that proactively promoting KPIs and metrics with your team and with leadership is the best way to head off the unfortunate conversation that will enviably come. A 360 SDLC diagram allows you to show where you are heading with KPIs even if the metrics are not fully ready. You will have to study your business and processes and determine what are the best indicators of success but I have included some with my 360 SDLC that are worth using. I will only give a short explanation of each KPI in this article. I suggest that you study KPIs and metrics to get a fuller understanding of what they are and how they are used.
Customer Alignment - This metric is produced in concert with Customer Satisfaction scores and marketing research. We want to declare that the backlog is organized to produce the features that are most valuable for the customer. This answers the question, "Are we working on the right things?"
Time to Market - This is the time it takes to start providing value to our customers or the time it takes to realize revenue for the company. It can be measured in the number of sprints before deploying a feature to production. This KPI relies on the velocity metric.
Resource Assessment - Also known as Capital Redeployment, this let's us know if it is worthwhile to continue a project or if we should shift engineering talent away from a project and to another.
Budget - Product, marketing, and engineering teams can help produce a budget based on estimated costs for features and company revenue goals. The budget helps inform the planning step on what should be included in a project and in each sprint to derive the highest value for the customer and the business.
Cost - Everything that we produce has a cost associated with it. We should be estimating and tracking the time it takes to produce a feature so leadership can make budgeting decision that revolve around revenue and profitability.
Velocity - This is a measure of how much value is being delivered. It is the average number of user stories that can be completed by the team in a sprint. We also use it as an indicator of how much a team will accomplish in future sprints. Velocity is a factor of the Time to Market, Resource Assessment, and Cost metrics. This answers the question, "How much work is getting done?"
Burn Down - A burn down chart is typically associated with scrum but can be used in any time boxed methodology to demonstrate progress during a sprint. It focuses on work remaining against days in the sprint. If the sprint is interrupted by a change in scope or ancillary work, this can be represented on the chart as well. It answers the question, "Where are you at on the project and why is it taking so long?"
Escaped Defects - Any bugs experienced by a customer in production is considered be an escaped defect. This means that this bug eluded the engineer, the tester, the acceptance tester, and the smoke test and escaped into production. These bugs should be rare. A high amount of escaped bugs may point to a quality problem somewhere in the SDLC. This metric helps answer the question, "How can you be sure what is being produced has quality?" and "Why does support increase after a release?"
Defect Density - Counts the number of defects against the size or complexity of the deployed feature. This helps keep the defect ratio in check. A larger deployment composed of multiple sprints will have a higher total story points for the feature versus a deployment of a small feature that was part of a single sprint. By taking the number defects and dividing by the size of the feature we get a ratio that can be used to measure our effectiveness for releasing quality code against all types of features.This also helps to answer the quality questions.
Customer Satisfaction - This is one of the greatest KPIs that engineering should pay attention to as everything we do is for the customer. As much as we love the experience of cutting and deploying code, that is not our primary responsibility. When the customer is not happy or willing to promote our product then we have some improvement to do. Customer satisfaction often is measured using a Net Promoter Score (NPS) which simply asks the customer if they would recommend our software, do nothing, or recommend against it. We want recommendations.
Summary
My intention by showing you my concept of a 360 SDLC model is to get engineering leaders to think beyond just producing the software. As we construct our processes our thinking should include the following:
Our relationships and responsibilities with other departments
The standard operating actions we perform
The artifacts used to stay organized and monitor our progress
And the metrics that we use ensure and show our success
My hope is this article helps leaders to think about the SDLC in a different way and perhaps will keep someone from experiencing what I experienced when my CEO asked those questions.
Take care and go do something amazing today!
Comments