How Freedom and Responsibility Fuel High-Performing Software Development Teams?

First few phases of the project (business as usual)

The story starts like any other project, but it’s worth mentioning that the job was quite lengthy and challenging. We were taking over a project with a considerable legacy code in an analytical application that simply didn’t work at the time.

The discovery phase was a huge mission in itself, and then the first couple of sprints were mainly focused on building the right team structure for the project and establishing the process, testing, etc.

It was a massive assignment. And like it usually is with those kinds of jobs, we needed to approach it the right way to reduce any risks and ensure we’ll be as efficient as possible once we begin.

But other than that, it’s fair to say that the workflow wasn’t that much different from any other project we’ve done before. For the first few months, we would spend quite a lot of time planning, meeting, and consulting within the team and with the product owner from the client's side. After about 4 sprints, we’ve managed to reach fairly high efficiency, and our 7-person team was closing around 50 story points per sprint.

However, we would still spend a large portion of our time discussing the project and figuring out the best way to move forward together. And at some point, we realized that those meetings were far less productive than those we had a few months back.

At the time, they were necessary. We were still figuring out our ways around the project and making sure we all shared the same vision. But it became clear that we don’t need that anymore. Around sprint no. 25, we came to the conclusion that we agreed with each other a bit too often. So, if we’re all on the same page, maybe we don’t need to talk that often.

The final straw came from the product owner, who strongly favored creativity over procedures. He believed that our team had all the capabilities to make the right decisions without a lot of his involvement.

So we just decided to switch things up a bit.

Let’s trust each other and get this project to the finish line

Of course, we didn’t just lock ourselves in rooms and turn our phones off. We maintained the regular schedule with demos,

However, we decided that we can trust each other’s judgments, and we feel comfortable about every team participant making decisions and figuring out the best way to deliver their own tasks. Almost immediately, we would see interesting results that we could divide into three categories

1. Less talk, more work

It doesn’t get simpler than this. As a team that already had a well-established workflow, we would just close more tasks more efficiently. Without unnecessary meetings and consultations, we could focus on coding. As it turned out, we didn’t need that much help to do that.

2. Out-of-the-box ideas

There’s a great Neil Gaiman quote that perfectly encapsulates this aspect of our newly introduced approach.

“If you don't know it's impossible, it's easier to do.”

We didn’t have to wait too long before people started showing excellent features that weren’t even in scope. 2D elements would become 3D elements overnight, people would surprise us with fascinating approaches almost on a daily basis. Creativity was blooming.

3. Better product quality

The last result partially comes from the first two. While working more independently, people were definitely more focused, but they also had to make their own decisions and find ways to complete their tasks. The responsibility was much more significant, but it also came with the feeling of ownership over every line of code. People working on their own wanted to complete their parts of the project in the best possible way.

The results

Okay, so here are the numbers:

After we changed the approach in the 25th spring, we quickly reached record numbers in stories finished and beat that record over the next few sprints.

But the most important result is, of course, the app. From a vast cauldron of spaghetti code, it evolved into perfectly functional software with plenty of users. Right now, our client is waiting for another round of investment before they hire us to expand the application.

Why did it work?

The change in approach was crucial and helped us quickly deliver a great project. But I still can’t say it will work in every case.

First, there’s a question about the extent of the strategy. How much consultation and prep is actually necessary to ensure that developers are ready to start working on their own?

Factors like the project’s complexity and scope, organizational culture, and even the exact team composition play a role. Overall, it’s a difficult decision and one that comes with quite a considerable risk.

That’s why I believe that the change has to come organically. It cannot be constituted. And I’m not only referring to developers not being able to work in such a fashion. The management side might not be ready for it as well. It has to be based on trust and mutual understanding, which is a tough goal to achieve in itself. And it’s fair to say that in our case, most pieces were already in place. Most importantly, the responsibility aspect.

About a year ago, I wrote my first article on the Order Group blog. I was mainly talking about how being given crucial tasks to complete by myself gave me confidence. I appreciated the trust and realized that it made me feel comfortable and much more efficient right from the get-go. So the culture was already here, it just had to be translated into the development process.

Patience is key

Right after the new strategy was implemented, there was some hesitance from a few members that weren’t accustomed to that kind of workflow. But it was never seen in their actual impact. After they realized

On a psychological level, I can see this approach working wonders for brilliant developers that simply don’t have the will or ability to play the front role during group meetings. Due to their personality, their ideas don’t always see the light of day in a regular workflow in which they follow the generally accepted framework.

On the opposite side, the approach requires some level of flexibility and the ability to work alone. It’s fair to say that not everyone can do that efficiently, but it clearly wasn’t a big issue in our case. And frankly, I can’t see that being a real problem in most cases, given the nature of the software development work.

If it works, make it a habit

What we did on that project was essentially an experiment. We felt comfortable about the change, and we were confident that it would help us move forward more efficiently. In the end, the results exceeded our expectations. But it’s still just one project. Now the goal is to make it consistent.

So, after the project was finished, our entire team was assigned to another one, this time significantly less complicated. We’ll try to adjust our newfound strategy to the requirements of the product that doesn’t need that much consultation in the first place. Once we have the results, I’ll definitely be back to tell the tale.