Agile engineering is a commonly used methodology, but how many teams incorporate their company values, vision, and operating principles into their day-to-day processes? 

Having an agile process that bolsters company-wide alignment is a big step forward. This can help create an organization that works in the way you want, even when you’re not looking.

Outlining the company values and culture

The first step in all of this is defining your organization’s current values and priorities. This can take the form of a vision document, architecture strategy, and/or a culture document. The structure isn’t as important as having something in writing that your managers, leaders, and ICs can point to and say, “This is what is important to us.”

Depending on the industry, stage of the company, and talent on the team, these values can obviously take different forms. For example, are your teams focused more on reliability over velocity? Do you have your teams split up, with service ownership at the team level? If so, maybe team ownership needs to be baked in somehow. These types of questions and answers can help you figure out what your data collection should look like, as well as your overall software development lifecycle (SDLC) and agile process.

Engineering teams should not be doing this in a vacuum. Ultimately, whatever shape your process ends up taking, it needs to be aligned and reinforce a strong relationship with the entire company (but most specifically, with product organization). This means getting product leaders in a room (virtually or in person) and getting a consensus on the “what’s important” bit. If engineering attempts to define an SDLC without this type of alignment, your chances of success are pretty slim.

Finding the metrics

Most companies these days want to be data-driven. Using statistics is a great way to show everyone in the organization (including the ICs) that the change in process is working. 

Using your list of company values, you can begin to start defining the data you want to measure. Defining this data before anyone starts mucking with Jira (or other project-management tools) is important. You want to ensure that your Jira implementation supports the easy collection (or automation) of these metrics allowing you to slice it in the way you want to. It’s usually better to do these types of moves all at once as opposed to gradually over time.  

The last time I went through this process, the team and I wanted to focus on lead time as our north star key performance indicator (KPI) for engineering. This measured the time it took our engineers to deliver impact to our customers. As a result, we added new fields to our Jira implementation so we could differentiate these tickets from internal systems or technical debt. We then divided the data based on the type of impact, and measured lead time on these different categories per team.  

Defining the SDLC 

Now we get to the part everyone looks forward to, reworking your current Jira implementation and establishing something that may be more helpful to your teams. Your SDLC definition should continue to enforce both your values and support the collection of metrics that you hold important. This could include the definition of Jira issue types and workflows (and probably does), along with whether you want your teams working in Kanban or Scrum. During this definition, you need to document and tie those changes back to the data and values you’ve previously defined.  

An example of this is when I was working in an organization where 60% of the engineers were senior engineer level or above. We focused on fostering more autonomy and ownership within the teams and asked members to define whether Scrum or Kanban worked best for their workload and team composition. As such, our SDLC outlined why a team might want to use Scrum instead of Kanban (or vice versa) and how to get the metrics we wanted as an organization, but left it up to the team to use what they felt worked best for them. In an environment where junior and mid-level ICs are more prominent, you might want to focus on a stricter definition to provide structure to the teams.

Training and adoption

In my experience, this is the most difficult and fluid of the stages. Documenting process updates or changing Jira is great, but that needs to translate to adoption and use by the organization. If not, there is no value or overall impact of the work you’ve done as a leader.

This is hard, there is no way around that. And the bigger the organization, the harder it is to turn the ship. First, I’d recommend finding champions for your process. This should be a group of individuals from all different levels who can be the advocates of these changes; perhaps taking the form of an SDLC guild. Through this group, you can begin to develop training, push updates, and create action items and timelines. The guild can act as the advocates of the process within their teams and beyond.

While you need to have materials for the ICs of the organization, the push for change should come from the engineering and product managers. They are the individuals that will ensure the process is being followed until it becomes second nature and is part of the team culture. This means that you should focus a good amount of time on building and training leaders in both the “why” and tactical detail.

Final thoughts 

There you have it, it sounds easy right? Having taken this approach recently, I’ve seen quite a difference – though the process wasn’t always as smooth as I’ve outlined here. Implementing this strategy has decreased lead time while giving our managers better data and insights into how our teams are functioning.

We can now understand lead time, mean time to recover (MTTR), change failure rate, and pull request (PR) times on a per-team basis with clear ownership by the engineering and product managers.