Introducing new processes to your team

Using the example of how feature flagging was implemented on a team level, learn how to introduce new processes and navigate change management.

When people change teams they gain the opportunity to spread their knowledge. Some might imagine it being a heroic pilgrimage where the enlightened and wise sage from a faraway team brings their wealth of knowledge to a new one summoning forth a new age of productivity. But rarely are the transitions so smooth. Most people value stability and are hesitant to adopt change. 

I recently introduced the use of feature flagging within my team to reduce delays in deployment and my experience led to a deeper understanding of how to bring about change successfully.

Finding the opportunity

The workflow I inherited when joining my new team worked well for our existing backlog. Most of the features had no external dependencies so we were able to operate autonomously. Code could be written and deployed when it suited us. 

Last year, the team took on a migration project to replace a core legacy system. This was a complex initiative as it involved modifying interacting systems owned by multiple teams. The upstream and downstream systems needed to be in agreement on whether they were using the legacy or the new replacement workflow. Our users also had to migrate to using the new systems which meant that our feature deployments needed to be in sync with the process change management. All these factors made us realize that our development strategy was inadequate. 

Our work now needed us to be able to finely control the release of our code. To do this within our existing Gitflow branching model meant we needed to strictly regulate when certain features could be deployed. Due to uncertainty from other teams on when their deployment could be coordinated, this led to many long-lived feature branches and eventual merge conflicts.

In one of our team retrospectives, it became clear that the team was unhappy with the constant delays in deployment and the extra effort needed to merge stale branches. I suggested we try an experiment with feature flagging. 

Introducing feature flagging to the team

In my previous teams, we used feature flags extensively, and I had confidence that this approach would be able to improve the current team’s workflow. But, they would need to be onboard. 

I started by giving a presentation to address the issues people had raised during retro. I explained the advantages of feature flagging and how it could be used as a potential solution. The pitch was met with a lukewarm response. 

Feature flagging had been used by the team before, but it had not been common practice so they did not see value in it. Some had questions on what it actually entailed and how it could be implemented. Both reactions showed me that further education on the matter might be helpful. 

Unifying and upskilling the team

A mob programming session was a great way to establish a standard for how we implement feature flags in our projects. To ground the session, I picked a relatively simple upcoming feature that we could build within an hour, having one volunteer developer drive while the rest of us navigated. 

The session itself was mostly led by team discussion after I had initially defined the approach. In areas where I noticed they stumbled off track, I would gently guide them back to the topic at hand. Usually, this meant fielding “leading” questions for further debate in the group. 

It is a fine art to drive the conversation forward while not stifling discussion. It is important to be very clear about the scope and objectives of a discussion to understand when it is going off track. If the topic is interesting but should be addressed elsewhere, make a note of it and steer the conversation back. If the team is getting bogged down with options, try to suggest a sensible default to move the discussion forward. If needed, schedule a second meeting instead of hurrying things and risking people feeling they’re not respected or heard. 

Make sure to overbudget the meeting time to allow for questions and discussions at the end. This should fine-tune out any lingering confusion, leaving the team feeling more confident. After the session, the work doubles up to serve as a useful reference template for future changes. 

Iterate

In an ideal scenario, everything would work and you’d get accolades and pats on the back. Realistically, most problems require multiple directions of attack. 

In our project, issues arose when the team started implementing feature flags for a number of features that all touched the same lines of code. The nesting features escalated the complexity of our branching logic and our test cases. 

To deal with this frustration, we held a meeting to clearly define the problem. We then compared some possible solutions and evaluated them based on the effort to implement and the value to delivery. With the complex approach, delivery timelines would be more stable but our task estimates would need to reflect the overhead and potentially wasted effort. We decided that this complexity could be better dealt with by separately scheduling the nesting features in a later sprint instead. 

We also had a more formal retrospective to refine and document our standards and patterns. Despite the shortcomings, the feeling was that this tool was a net benefit to the delivery of the project. 

Final thoughts 

If you’re looking to introduce a new tech initiative you should consider: 

• Timing and opportunity:
  • Identify when it makes sense to introduce the change and clearly share the vision and benefits to gain support. 
• Start simple and small:
  • Begin with a manageable implementation to demonstrate feasibility and benefits.
  • Address uncertainties by creating a proof of concept and setting standards for future implementation.

• Upskilling your team:
  • Conduct collaborative sessions, such as swarm programming, to familiarize the team with the new technique.
  • Encourage questions and discussions to foster understanding and adoption.

• Iterate:
  • What works for one team or project may not always work. Get feedback by asking questions through retrospectives to see what needs clarifying or improvement. 
  • Adjust the scope. Rarely does a single tool solve every problem. Understand where the tool works and doesn’t and come up with new solutions as needed.