BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Embracing Agile Values as a Tech and People Lead

Embracing Agile Values as a Tech and People Lead

Bookmarks

Key Takeaways

  • Reflecting upon agile values helps me to build my leadership style: if I know the value, I can spot when it’s been violated and find ways to foster it
  • The Prime Directive is not only valuable for retrospectives; I applied it in my daily work when approaching tech debt
  • It’s easier to align iteratively than with a big bang; by breaking refactorings down into increments I also avoided upfront arguments
  • Integrating knowledge sharing in the decision-making processes enabled everyone to own the decision
  • Asking for resistance when proposing a change helped to fine-tune it and increased the buy-in

 

Having worked for more than ten years as a software developer, the agile community has been a great source of inspiration for me to find better ways of working. In my first leadership role, I incorporated the agile mindset and want to share how it has helped me to get everyone working towards a joint goal: refactoring an inherited code base for scalability, while enabling cross functional teams to work as autonomously as possible.

My leadership challenge

When I joined MOIA and became frontend chapter lead, the former frontend only team had only recently been split into newly formed cross functional teams. We were two newly assigned chapter leads for around ten frontend developers, and half of our people had just joined.

The externals who had contributed a lot to the system were about to leave and we would hire more internals. The challenge in leading people was to keep the connection that the frontend developers had, even though they were now distributed to different teams. 

I wanted to foster cross team collaboration while helping them understand their home base is their new team.

Having been built in a frontend team, it was no surprise that the frontend had a monolithic architecture that no longer fit the needs of the cross-functional teams that wanted to build their features in their part of the system independently.

Also, because the system was built under time pressure and with different people who joined and left in the early stage, the architectural concepts for cross-cutting concerns were well intended, but only halfway finished. The UI was inconsistent because it had been developed incrementally by different designers and developers. The workflows were not optimized for developer experience, for example the deployment included several manual steps.

So my tech challenge was to guide us through refactoring this tech debt together incrementally while the cross functional teams would add features in order to use synergies. 

We needed to keep the teams actionable and enable them to be as autonomous as possible.

My leadership style

I’m building my leadership style based on my values. I’ve been socialized within the agile community, and when I started coaching other developers, I reviewed the agile values which have been important for me ever since.

I use both the XP values - Simplicity, Communication, Feedback, Respect and Courage - and the Scrum values - Commitment, Focus, Openness, Respect, and Courage - for reflection when I want to understand how to improve our interactions and processes.

For example, if I experience that some people don’t tend to share their opinion or try new ideas, I want to understand what is discouraging them to do so. An environment that doesn’t foster the courage to speak your mind or try something new is not healthy. If people hold back their ideas, teams will create worse solutions and individuals will be frustrated because they feel less appreciated.

Understanding the value of courage, I can then find ways to foster it. I’ve found that it helps people to be more courageous in a group when they already reflected upon what they want to share with an individual. That’s why I think one-on-ones are important: they are a safe space to share anything. As a leader, I then encourage people to share what they just shared with me with the team.

I ported a lot of values and principles from the agile community into my leadership style, for example the Prime Directive for retrospectives by Norm Kerth:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Applying the Prime Directive

As I described earlier, the frontend had a monolithic architecture, our deployment contained manual steps and our UI was inconsistent. But this doesn’t mean the previous authors of the system were not giving their best at the time they architected it. They had a different focus. The problems they needed to solve were different when they made their decisions. They had different resources.

That’s what the Prime Directive is about: acknowledging that past decisions were taken under different circumstances, understanding what circumstances changed and taking new actions for improvement.

Approaching the tech debt with the Prime Directive in mind, I didn’t encounter much resistance when I proposed a change. Also, it helped me to only propose changes that were really addressing a pain point. To get a better understanding before proposing changes, I asked first why and under which circumstances they took which decision.

If someone's arguments became defensive, it helped me to clarify: “I just want to understand, I’m not judging.”

Experimenting with our working modes

Even though they joined new teams, the frontend developers still shared a joint responsibility for the cross-cutting concerns in the frontend. As described earlier, our code base was not ready to scale.

So we needed to have space to do this work. First, we had “Tech Stack Wednesdays”: we would get together in a room - that was pre-pandemic - each Wednesday, leave the work for our teams behind and focus for a day on platform work. Platform work was defined as the cross-cutting concerns that we needed to solve in the frontend together because they provided the base for feature development.

These “Tech Stack Wednesdays” helped to get everyone on board who had newly joined, and that was about half of the frontend developers so it was a huge advantage for bonding and knowledge sharing at that stage. But they also were a great disruption in our workflow; we needed to interrupt the work in our teams on Wednesday and interrupt the work for the frontend platform on Thursday, so we had two large context switches each week. This approach was tiring and also led to long living branches as we nearly never got anything finished in one day.

After four months, we decided to change the working mode. For one month we tried a “rotating pair”: each week two developers from two different teams would pair for the whole week on a cross-cutting concern for the frontend platform. This helped to increase focus.

However, with two people rotating each week, the handover was a bit difficult. To solve this, I became the steady member of the pair while a different developer would join me each week. 

With this mode, I could provide the long term vision while integrating different ideas. While I learned from the teams about their context, I also could share my knowledge about the big picture with them.

Eight months later, the developers found it more and more difficult to commit to their “Platform Week” in advance because their teams experienced unexpected spikes in workload. To reduce the stress on the developers, we agreed that everyone would pick something in between if they had slack time. This mode resulted in more small improvements that were done in parallel. As long as we had enough small tasks in our backlog, this was a good solution. But as we accumulated more bigger tasks again, we decided to form a platform team that was dedicated to these tasks.

Creating the platform team, we also could take on more responsibility and shifted our focus from frontend only to full stack because we included the backend of the user management as a cross-cutting concern. This was helpful because this part of the system was previously maintained by a team that had other priorities, and therefore neglected to improve it.

We kept the alignment that we had with all frontend developers as a community of practice, and continued to share the workload for cross-cutting concerns in the frontend. We also turned the rotation around and now developers from the platform team visit other cross-functional teams from time to time. These internships help us to remain informed on the needs of the teams we build the platform for.

During the last two and a half years, in this ever-evolving working mode, we changed quite a bit under the hood of our frontend and made it scalable.

Extracting a UI Pattern Library

Together with the designers, we created a Pattern Library to make the UI consistent and reduce development and maintenance effort. This was an incremental change spanning over years. We already had been using Material UI as a base but it was used very differently throughout the frontend: the customization was often done at different places and always slightly different. So we extracted and standardized the patterns step by step: colors and typography first, then basic components, later layout components, and so on.

For me it was important to advocate that we can do this change incrementally. Developers have a tendency to cry for a rewrite when they encounter a large inconsistent code base, because it seems so completely broken that it’s hard to think about the increments. But the danger of a rewrite is that it is a big bang approach. And as with any big bang release, you might underestimate the time it takes and miss errors you make because it is not used until released.

Changing the existing code incrementally also enabled us to already add new UI Patterns to the Pattern Library as they emerged.

The most difficult task was to get designers and developers to talk with each other regularly. We tried some upfront concept workshops and they would result in big arguments without any outcome. Also from the people’s perspective, an iterative approach was more fruitful: get together every week for half an hour, sync on the next step regarding the Pattern Library, implement, feedback and repeat. This repetitive Pattern Library Sync meeting helped us to reach a common understanding.

Modularizing a frontend monolith

To migrate the monolithic architecture into a modular one, we first just moved code around and changed the folder structure by feature set instead of by function. Having folders with the complete logic for a feature set, we introduced Yarn workspaces but didn’t succeed to untangle the monolith into separate workspaces because it required a lot of manual effort. I then discovered Nrwl/Nx which is another tool for modular monorepos and we decided to use it as it had much better tooling than Yarn workspaces, like dependency graphs and code generation.

With Nx we could also introduce other changes, e.g. only execute tests that were affected by a change and speed up our build pipeline. Also we didn’t stop at using Nx, but tweaked some parts with introducing other tools like pnpm and vite.

Even though we also approached the modularisation iteratively, there was a larger chunk that needed to be reworked at once: for the general setup of Nx, we needed to make every folder an Nx library. This branch lived for nearly two months.

I usually advocate to use feature toggles for large changes, but when changing the configuration of a project I haven’t yet found a strategy for how to create small changes that can be integrated into a live application.

It was the largest Pull Request I had ever created, and without everyone's commitment to integrate their changes on main also into the refactoring branch, we would not have succeeded.

Decision-making for cross-cutting concerns

Other big refactorings were the migration from Javascript to Typescript, the removal of redux, and changing our test setup from enzyme to the react-testing-library.

It was important to me that people not become overwhelmed by all these changes. When I joined, it was typical that such ideas were discussed and decided on in Slack. That put a lot of pressure on everyone to be up-to-date and answer quickly to take part in the decision-making process.

Such an ad hoc decision-making process privileges people who are already knowledgeable on a topic, and fails to hear concerns or receive different ideas from people who first need to gain some knowledge.

That’s why I introduced the “Discuss & Decide” meeting, where we would weekly make decisions about cross-cutting concerns. For big changes, the most knowledgeable person would first do a knowledge sharing session before we made the decision to use that new tool or concept.

Once we had a working proof of concept for refactoring a cross-cutting concern, we would put this change on the list of our “Campground Tasks”.

If someone touched code that was outdated regarding our refactoring goals, they would change it. This way we avoided large plannings for refactorings, and made sure the most important code - the code that is changed - was refactored first. Also, it was helpful for learnings: everyone applied the new principles and tools in the part of the code base they were responsible for - and at the pace that they needed to, to get acquainted with it.

Embracing change to facilitate reorganization

A key agile principle to me is “Embrace Change”, the subtitle of XP Xplained by Kent Beck. Change is continuous in our world and also at work. Accepting this fact makes it easier to let go of a decision that was taken once under different circumstances, and find a new solution.

To change something is also easier if there is already momentum from another change. So I like to understand where the momentum is and then facilitate its flow.

We had a large organizational change at the beginning of 2020. Some teams were newly created and everyone at MOIA was allowed to self-select into one of around 15 teams. That was very exciting. Some team formations went really well. Others didn’t. There were two frontend developers who had self-selected into a team that had less frontend work to do than expected. These two tried to make it work by taking over more responsibility in other fields, thus supporting their team, but after a year they were frustrated and felt stuck.

Recognizing the right moment that they needed support from the outside to change their team assignment was very important. Changing their team assignment too early would’ve resulted in them feeling like they hadn’t tried properly, but leaving them alone with the problem could have resulted in a resignation.

Fortunately, we had a good relationship, and they told me when the experiment failed for them. Team setup requirements were changing for other teams as well, so I had collected the changed assumptions of how many frontend developers were needed on which team. I used that knowledge and the momentum of these two frontend developers who wanted to change their team to re-evaluate all teams and give every frontend developer the possibility to change their team.

Instead of holding on to the original plan and building on top of it, we canceled three positions in two teams, created two new positions in two other teams, and two new positions in a new team. In total, we just needed one more position and could find a new team for three developers.

Get better buy-ins for changes

To facilitate this large team rotation, I used the resistance call method that I had also applied earlier for other changes; I shared the information I collected about the frontend positions that each team needed along with my educated guess as to who could move to which team.

To get an honest opinion, I emphasized it’s a draft and the next step is honest critique.

Most developers were happy about the team that I assigned them to on the draft, but two were not, so we followed up on it in a smaller circle and fine-tuned the draft until no concerns were left.

Starting with a proposal instead of starting from scratch like we did in the self-selection process a year ago had the advantage of using everyone’s time efficiently. At the same time, the resistance call method allowed for in-depth inclusion.

The buy-in in this organizational change was very high as it was motivated by the individuals’ perception of the changed circumstances and their inclusion in the decision-making. Everyone was motivated to make the new team setup work. Also, the understanding that changed circumstances means we can re-evaluate existing solutions easily helped to facilitate other changes in the team assignments afterwards.

What I learned in my leadership role

I was prepared to set the tone as a leader - that’s why I wanted to become one. The agile mindset deeply influenced my style. A team works best if everyone is included, so I make sure everyone has space to share their ideas. I don’t allow blame, and if I challenge an idea I do it respectfully so that I role model working with each other on eye level.

I also interfere with critical feedback if someone makes another person feel inferior by intimidating them with their knowledge. I then explain that it is important that everyone feels safe to share their ideas and admit what they don’t know, so that we can learn and grow as a team. That it is the responsibility of everyone: to share their knowledge at a pace that others can learn. 

To get everyone involved in a topic, before, making a decision was, and still remains, a challenge. Both knowledge sharing in advance and the resistance call method have helped to make inclusive decisions.

The most important learning for me was and still is to balance democratic decision-making and making decisions as a leader. Those who are highly affected by a decision should also be involved as they are the ones who execute the decision.

However, if I have more detailed information and knowledge on a topic, I need to be ok making some decisions on my own. I realized that it is more effective and even appreciated when I involve the people I lead only using feedback and fine-tuning, instead of during the whole thought process for decisions that set goals or define a strategy.

That being said, I got a lot of positive feedback on my participatory style. It has helped me create a deep impact because the people I led felt safe, appreciated and included. We never encountered conflict, but instead gained a lot of momentum on topics that we aligned on.

Growing into a leadership role, I can only recommend reflecting on your agile roots and integrating them into your style.

About the Author

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT