Demonstrating progress: the crucial first step for a new team

There I was, nervously waiting in a bland conference room for the team members to arrive. Half of the people that were supposed to come showed up. How do we get going and build some momentum? That was the question at the top of my mind. 

I had been assigned responsibility for an agile experiment – the first one for that corporation – within an established, bureaucratic organization. I was to be the Scrum master for a single team tasked with building a platform for a new product line. Not knowing where to start, I felt the pressure from a – to put it mildly – skeptical organization to produce. Those initial days felt like navigating through a dense fog.  

I suspect that many feel that way when they try out a new approach within an established organization. Even if the team set-up favors success – with minimal dependencies to others and a clear goal – the start will still be rough. 

Today I want to offer some advice on how to get going and build some initial momentum. To spoil the next 1000 words or so: the best thing to do is to build immediately


The Backlog is a bi-weekly newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox. 


Demonstrating progress shows that the invest was worth it

If you are trying a new approach within an established organization you will face headwinds early on. 

Externally, expect skepticism or outright hostility from the organization. As a nascent team, you lack an established role within the company, and your goals may remain unclear to many stakeholders. Some individuals, teams, or departments may feel like you’re stepping on their turf.

At the same time the team members are still feeling each other out and might also not be convinced of the new approach. Also, some members could be missing because they are still involved in other projects. The team might not yet have a team space. Finally, the team’s objective might be so vast that you don’t know what to start with. 

All of this is perfectly normal. 

Nevertheless, you need to move quickly. If you are not careful the team will be eaten alive by the organizational antibodies (stolen from Build). It is therefore important to immediately show the organization that the investment in the team is worth it. It’s crucial to create some initial momentum. 

The easiest way to do this is to build something fast. 

It doesn’t really matter what you build. It just needs to provide some level of value. Producing something quickly helps a) convince skeptics that this is not just another initiative that is introduced with much fanfare but will fizzle out quickly (as so many do) and b) helps the team learn how it wants to collaborate.

Don’t conduct a team building workshop

Many newly formed teams conduct some sort of team building workshop to get to know each other better. This does help. However and with the risk of some pushback, I don’t think they are needed. 

I believe the best way to get to know each other is to collaborate closely. You can still use coffee breaks, lunches, or idle time before meetings to talk about things outside of work to become more familiar. 

Also, be aware of the impact of having a fancy offsite team building workshop has on an already skeptical organization. It surely won’t reduce the amount of skepticism. 

My advice on getting started

To create some initial momentum you need to build something, fast. That sounds reasonable. How do you actually do that? For me, it comes down to four principles. These four help identify what to work on and improve speed of delivery:

  • Lean on the team members
  • Focus on what you can control
  • Hacks aren’t always bad
  • Optimize your process

Let’s start with the most pressing question: what to work on first? 

Lean on the team members

In the initial stages, you may be overwhelmed by the distant goal and the mountain of things to do, leaving you unsure where to begin. Leverage the insights of your team members. Ask them what to start with.

However, striking a balance between importance and size is crucial. The most important topics the team proposes are often also the big ones. They take time to build, time that you don’t have. You need to build something of value quickly. Work with the engineers to find something that is important enough but reasonably small so that it can be implemented within two weeks. 

Remember, the goal is to build initial momentum. If you can already present something after two weeks you are likely going to impress a lot of people. Big organizations are not used to that speed.

You also need to focus on those topics that are fully in your control.

Focus on what you can control

Minimizing dependencies enables you to move fast. If you want to build something quick you therefore need to focus on something that has no dependencies to others. Focus on something that is fully in your control. 

Using the product architecture or the process as guidance, visually map out what you are responsible for and where you have dependencies to others. Anything that needs input from others is off the table. For the remaining parts, brainstorm improvements and start building.    

Hacks aren’t always bad

Most developers hate quick and dirty solutions or hacks, preferring robust, long-term fixes. I generally agree. Hacks will cause additional maintenance or refactoring effort down the road. Working in an established team I always advocate for spending more upfront time to do it properly and only once. 

In the situation at hand, however, you are not in an established team. You need to quickly show progress. When time is scarce, pragmatic hacks can be your friends. Hardcoding a roles-and-rights system or scraping data are examples of things we have done in the past to demonstrate progress. 

However, remember to revisit and refine them later, once you have some room to breathe. Many don’t do that. Make sure you are not them! 

Optimize your process

Corporate processes, while essential for alignment of large organizations, slow down development. Recognize that not all steps apply universally, as generic processes need to take every edge case into account.  

Many simply accept the processes. They forget that you can change them. Optimize the process to fit your context. Use common sense to eliminate unnecessary bureaucracy, and you’ll make a lot of friends in the team. As long as you keep to the spirit of the process you should be fine. 

Most companies actually have a procedure in place that gives official permission to deviate from processes. Make use of that if you are unsure how far you can go.

Do good and talk about it

Having figured out what to work on first and how to improve speed of delivery, you will soon produce results. Then, there is one final step missing in building initial momentum for the new team, communicating what you built.

One of the first and best pieces of advice I got upon entering the working world was do good and talk about it. This has stuck with me and it applies here as well. Use all available channels – reviews, blog posts, emails, and Slack – to show off your accomplishments.

What is true for building products is true for a new team within an established organization as well. Building by itself isn’t enough. Sales and marketing matter. Shout your accomplishments from the rooftops.