Benefits and practical aspects of working without project managers
Projects and project managers in the software development industry are an inseparable combination, right? Well, no, not at all. That’s the received wisdom, and it often goes unquestioned. Like many companies specializing in digital product development, we considered it as something obvious. In the past, we used project managers for every project. The turning point was when we started using Scrum as an agile project management framework. With a development team, scrum master, and product owner, we found no need for a separate project manager role. As a result, we work more efficiently and more closely with our partners and get better results. So, what is it like working without project managers responsible for the project’s success?
Table of contents
What do project managers do?
The project manager role covers the ‘classic’ management responsibilities, including:
- project planning and goals,
- the project timeline,
- allocating tasks and objectives,
- managing resources,
- and the motivation and performance management of team members.
It all sounds very non-controversial. After all, that’s what you want a manager to do, isn’t it? And these responsibilities all need fulfilling. However, we believe that we can cover all these functions through other means, and without anyone assigned to the role of a manager. And this is what sounds a bit controversial, isn’t it? Why do we consider the manager-centric approach to be inefficient? For us, it’s a manifestation of obsolete, ‘waterfall’ methodology and a mindset that tends to rest on the following assumptions:
- With enough work up front, the project plan is a constant.
- The more detailed the project plan, the better.
- Clients (or those for whom the product is being created) only need to be involved at the beginning and end of the project.
- Sticking to a schedule is a measure of success.
- People need to be managed.
At Boldare, based on our 19 years of practical experience in software development, we know that this is just not the best practice for the creation of complex digital products.
None of the above is to say a project manager cannot be useful in a mature and healthy organization – they might serve multiple, useful and efficient roles, including being a single point of contact for team communications, and they are also there to take responsibility for any problems during the project. But we simply believe that there is a powerful alternative.
The agile alternative to product manager
Here at Boldare, we use a combo of the lean startup build-measure-learn approach and the sprint-based scrum methodology that divides project work into short (usually around two weeks) periods of activity, each resulting in a tangible and workable product iteration.
In the absence of a project manager, the key roles in an agile project are:
- Development team – containing all the necessary specialist skills and experience: frontend and backend developers, quality assurance specialists, business analysts, graphic and UX designers, etc.
- Scrum master – a person expert in the scrum process who acts as a facilitator to the team, supporting them to use that process most effectively.
- Product owner – a representative or stakeholder of the client or department for whom the digital product or software is being created.
Agile working is based on flexibility, strong client involvement, and an iterative structure. Which all sounds excellent but what are the differences exactly, compared to using a project manager?
How to work without product managers?
Product and project vision
Having a vision is important, no matter your methodology. It’s a clear and overarching guide to what you’re aiming for. Traditionally, the project manager would be heavily involved in creating the vision and then ensuring it is imparted to the project team. Usually, throughout the course of the project, the vision is fixed and unchangeable.
In scrum, the vision is set with the involvement of the whole team, including the product owner. At Boldare, we do this as part of a product discovery workshop (or one of the other workshops we offer, depending on the business needs of our partners) to kick off the development process, before the first sprint. It’s an event that involves both sides - our development team, a scrum master as a facilitator, and also the client’s stakeholders. What are the benefits of such a workshop?
- It helps both the team and stakeholders to understand the real reason for bringing such a product to the market.
- It allows us to understand the product’s level of maturity (are we going to use the MVP approach, or are we talking about scaling existing products?) allowing us to define the specific software development needs.
- We can revise and challenge the ideas of our business partners concerning the solution they have chosen - business and technology-wise.
- It helps us to select suitable technology.
- We can map the risks and agree on a definition of success that is satisfactory for both sides.
Workshops not only increase engagement and commitment from the team but also put the overall responsibility for the vision where it belongs, with the product owner.
It also makes that vision easier to change, if necessary. If circumstances and priorities shift in a way that impacts what the team is building, as the client’s representative, the product owner will be the first to know and it’s appropriate they take responsibility for this input into the process.
Planning and time management
Usually, the project manager uses a detailed project plan, broken down into individual tasks and activities and showing the dependencies between them. In other words, a roadmap for the project.
However, this approach often places that roadmap in the category of holy writ; to be followed slavishly. In reality, knowing where you want to be is one thing, but how you get there is subject to change during the project and an agile team is ready to change direction when necessary.
With the work planned one sprint at a time (via the process of sprint planning) the team takes joint responsibility for the project’s direction and creates a much more adaptable work environment. They plan tasks only for a short period of time (a sprint is usually a week or two long) and usually provide only one functionality, defined in the sprint goal. Thanks to this, the team focuses on a single deliverable goal.
When the sprint finishes they can reflect on their work during a sprint review and look back at what happened during the same period in a sprint retrospective meeting. This helps to summarize what happened during the sprint but also allows the project to pivot if the initial approach was unsuccessful. The conclusions reached following the sprint are implemented into the planning of the next in the form of executable actions.
This way, the build-measure-learn loop is used in practice and scrum teams rarely repeat mistakes.
Technology (for example, Trello, Jira, or Asana) can be used to help manage this and ensure the high degree of information transparency necessary for such an approach. In this way, there’s no need for a project manager to keep track of the project schedule.
Work allocation – who does what?
A project manager looks at the tasks and timings on the project plan and allocates them to team members, according to their roles and specialties. This usually reflects a rigid team structure with clearly defined responsibilities and accountabilities. The result can be a narrow individual focus on allocated tasks, and actually reduce teamworking.
An agile, manager-free development team supported by a scrum master is likely to be smaller (usually up to 8 or 9 people at maximum; to manage more complex and multiple scrum teams we use the Nexus Scrum framework) and offer more flexible skill sets, with people’s specific roles and responsibilities potentially evolving from one sprint to the next, depending on what the product and development process require. Also, scrum comes in handy here: daily scrums are short, daily meetings for the team to discuss the events of the previous day, plan the current one, or ask for help or explanations. Each team member has an opportunity to speak their mind, seek help, or warn about an issue.
This way, the responsibility for success (and failure!) is shared throughout the team instead of resting solely in the project manager. Every team member learns the lessons coming from the process better, through their own example.
Communication & information
A project manager tends to act as a kind of custodian of project (and product) information. If a stakeholder wants a progress update, they don’t go to the project team, they go to the project manager. Likewise, if the team needs to know about a change in priorities (for example) it is the project manager who is responsible for communicating that change, and for updating and then communicating the project plan.
In agile, the key is transparency. Everyone involved in the project has access to all the project documents and information. With the system of sprints and accompanying review and planning meetings, the client can see project results as they emerge and develop. Everyone is on the same page; there are no gatekeepers.
Naturally, even with agile working, poor communication is possible. But technology helps: using a messaging system (such as Slack) ensures nothing is hidden; and using a suitable video meeting app and online collaboration app (we recommend our own app, Boldare Boards that we have developed, of course) means that everyone involved can attend the regular sprint meetings, whether they are in the office or not.
Also, at Boldare we use a radical transparency approach which practically eliminates gatekeepers in the form of managers because the information and knowledge are shared publicly and accessible by everyone. We encourage our employees to use public channels, instead of private messages. This way we all get access to all the information quicker and learn faster. This approach favors knowledge sharing and problem-solving, because if someone asks a question publicly then everyone can answer, not only the person who was asked in the first place.
Performance management
In a traditional team setup, the manager is responsible for team and individual performance; including setting goals, monitoring performance against targets, delivering feedback, and rewarding achievement.
In an agile development team, individuals are more self-organizing, responsible for their own performance, and are expected to ask for (and offer) support when necessary. Performance management is more of a collective task. This is exemplified in the retrospective meeting that takes place after every sprint. The retrospective’s purpose is to examine the process; i.e. not so much What did we achieve? but How did we achieve it? Retrospective meetings can be also used to summarize longer periods of time and important milestones. For example, internally we use it to summarize each quarter or each product launch.
In a waterfall project, there’s an assumption that the project process is perfect, untouchable and the goal is always the same. Working in agile, that process is regularly reviewed and improved, to the benefit of the project’s outcomes.
Dealing with problems
Whether it’s an unexpected lack of resources, a new project dependency, or an interpersonal conflict between team members, it’s a project manager’s job to find a solution to project problems.
An agile team is much more connected and engaged – both individually and collectively – with the project and its process. This means when (not “if”) problems arise, the self-organizing team can tackle the issue together, facilitated when necessary by the scrum master.
Additionally, in turquoise (or ‘flat’ as they’re also called) organizations like Boldare, we don’t put the whole responsibility for solving problems or conflicts on one person. Responsibility is shared between all team members, especially those in the roles of Lead Link and Rep Link. Also, if there’s a problem and we don’t have a role that can take care of it, we simply create such a role. For example, before the COVID-19 situation, the company had no need for a role that would be responsible for communication about company policies or business decision-making during a pandemic. When the situation evolved, we created such Active Strategy roles for our New Normal strategy.
Working without a project manager: the culture factor
For flexible, self-organizing, collective, and agile working, culture may be the most important success factor.
A company that is used to waterfall projects with a strong project manager role is used to working in a more rigid, stratified, command-and-control environment. From our experience and perspective, this approach is high-risk because it rests too much on a single person. You can imagine what might happen to your software development project when the project manager (custodian of all knowledge and decision-making power) is suddenly on sick leave or simply leaves the company.
To move from that to an agile, product- and client-centered way of working is a major culture shift.
Ultimately, for truly agile, project manager-free working, the attitudes of each team member, the scrum master, and the product owner are critical. If anybody is just expecting someone to give them a job and then get on with it in isolation, they’re not working agile.
Less managers, more agile!
Put simply, in Boldare’s long and practical experience of working in scrum, the project manager role is not necessary to build high-quality, cutting-edge digital products. In fact, it can even be a barrier to success. When the traditional project manager role is distributed between the development team, its facilitator (scrum master), and key client stakeholder (product owner) a far more effective way of running projects opens up.
As the COVID-19 pandemic changed the way we work and discouraged physical collaboration, self-organizing teams have become more suitable for the current remote/distributed working model. With everyone engaged and jointly responsible for the project, an agile team can work efficiently without the need for geographical proximity or a single guiding individual.
Share this article:
