The following post will discuss how you can guide a team to a better way of working. Important side note: this post assumes that the team, and by extension the organization you’re working for are open to your help and have a healthy organizational culture. Be aware of situations where management asks to “fix the team”. Usually improving the way of working starts with working on the leadership team in an organization. Remember: leaders go first and have to set the example. Michael K Sahota wrote a very good summary on how you can change your organizational culture.

We trust you to help us

So let’s assume the organization and the team you’re working with, realize they can do better and they trust you to help them. Where do you start?

In general, these steps can be applied to any team:

  1. Analyze their current way of working.
  2. Try to understand the “why” of their way of working.
  3. Create a north star for the team.
  4. Get feedback.

In essence, we’re using the Deming cycle to find a better way of working until we can stick to a more robust standard. And repeat in small increments.

Analyze the current way of working

Whenever we get asked to help a team of software engineers we try to take a look at the bigger picture with an audit or conducting 1-on-1s as the first step of our assignment. No matter what we’re asked to audit, we’ll also take a closer look at the organization’s processes to see how they currently work and more specifically, what isn’t working for the organization. From experience, we know that the supporting structure of an organization has a tremendous influence on how a software engineering department can do their work.

The first step in this analysis is interviewing every team member to see what their understanding is of their current processes. What’s their role? How does it fit into the bigger picture of the organization? You would be amazed at how often you hear different stories, depending on who you speak with. It’s important you take note of the similarities and differences in every team member’s story. It could be a red flag or a result of different perspectives on a given situation.

The second step is observing what was said versus what you see happening within the team and organization. Especially in the early stage of your collaboration, people like to paint a much nicer picture than what’s actually happening on a day-to-day basis. This observation can be done by attending meetings, working within the team and joining their communication channels (eg: Slack).

When your analysis is done, you’ll probably have a list of things you want to improve but hold your horses! This is not the time to implement those improvements, yet.

Try to understand the “why” of their way of working

You have some insights from talking to the team. People have told you how they work and why they work like that. You have seen it with your own eyes by observing the team. What’s next?

The reason for not immediately proposing improvements is because there might be a very good reason why it’s done like that. At madewithlove, we like to create a hybrid team of our software engineers and the client’s team. This can create some friction at first, but if there’s enough trust you’ll already see things changing without actively intervening anywhere. Our team’s responsibility is to work with the client’s team and show them best practices, help them set up tools to improve day-to-day work, analyze the current state of the product, etc.

Create a north star for the team

You gain more trust with the team and are actively taking part in their day-to-day work. Things have already started changing because of the hybrid team setup. Now is a great time to take a critical look at everything you’ve learned and share with the team where you want to go and why. This is not about saying: “We should do Scrum from now on and all our worries will be gone.” We don’t believe in silver bullets. This is about taking the first step in a direction you believe is more or less correct.

This doesn’t mean we won’t dive into very specific solutions to fix things. It means we’ll keep the north star in the back of our heads and work from there. And we rather work from a pull perspective (“Ask for any help you want and we’ll assist.”) than from a push perspective (“This is how you should work now.”). Your principles should be the same, but the execution can be very different depending on the team.

Ron Jeffries wrote an excellent post on a simple set of principles for software engineers to work towards:

No matter what framework or method your management thinks they are applying, learn to work this way:

  • Produce running, tested, working, integrated software every two weeks, every week. Build your skills until you can create a new fully operational version every day, twice a day, multiple times a day.
  • Keep the design of that software clean. As it grows, the design will tend to become complex and crufty. Resist and reverse this tendency consciously, refactoring in tiny continuous steps, all the time, so that your rate of progress is as steady and consistent as possible.
  • Use the current increment of software as the foundation for all your conversations with your product leadership and management. Speak in terms of what’s ready to go, and in terms of what they’d like you to do next.

This is the development team’s best hope for a reasonable life. By keeping the software always ready to go, we can hit any deadline with the best possible result. “Is today the deadline? Here’s what we’ve got, it’s ready to ship.”

He continues further on with his idea of running a company. This is the best advice for what you should expect from the team.

If I were starting a company, I’d let the teams choose any process they wish. However, there would be constraints, not on how they choose to work, but what I need to see. I’d make it clear that every two weeks at most, I would like to review their running tested product slice. They’d show me what they had planned to build, and what they built. It would have to actually work, and to contain visible capabilities that I could understand. We’d talk about what they should do over the next interval. And I’d make it clear that one week would be better than two, and that one day would be better than one week.

Get feedback

As with any change, some things will work, some things will not. From early on in the process, it’s important to coach the team in voicing their feedback in the group. This can be installed within a ritual like the retrospective meeting and by inviting them to raise any concerns they have personally.

Because everyone’s different, you should watch out for changing things too much. Some people get excited and want to change everything at once, but some colleagues might not adapt as fast to changes and get uncomfortable. The goal is sustainable growth.

What’s next?

Celebrate the small wins, learn from mistakes and don’t forget to have fun along the way. If done correctly, you should have set the context for the team to keep growing in the way they work. It’s important to remember that there’s no sense in rushing things. Keep things evolving at a calm pace where people have room to adapt.

We’re happy to help improve the way your team works. Requesting an audit is the perfect way to kick things off and see where we can help. Message us and we’ll get in touch!