Recently I read the book 'The People's Scrum' by Tobias Mayer. In this book, he spends a chapter on describing the differences between project culture and team culture. To me, the given examples of both types of culture are highly recognizable and I can easily extend and complement the list of examples with my own experiences. And this is basically what this blog post is all about, my view on the project- and team culture.
Project Culture
In the project culture, I have experienced that developers got assigned to projects based on their availability in the 'resource-planning tool'. Project managers, team leads or the Project Management Office supervises the availability of every 'resource'. If a developer is planned for 6 hours, this means he still got 2 hours left for another project. The lifetime of a project equals the lifetime of the team. Therefore the teams are often short-lived and it's composition changes continuously. Most of the time the teams work on different projects simultaneously which results in waste due to context switching.
In this type of culture project is king. If scope, budget and time are met, the project is a success. Often the scope is fixed and quality gets undermined due to the pressure of impossible deadlines (considering the fixed scope). Project management is done via Gantt charts and every hour the developer works are tracked by a complex time tracking tool. Every week an extensive report is composed of unreadable graphs describing the output of the project team.
Another characteristic of a project culture is the recognition of 'fire fighting'. If a problem occurs, the project manager comes around to fix it. The irony, however, is that most problems are also caused by the same project manager. This due to inflicting the team with a fixed scope, tight deadlines and lots of context switching.
The final example of a project culture is the relationship with the customer. True collaboration doesn't exist. The customer is only considered as the one paying the bills and all communication runs via the project manager or the team lead (developer). Therefore the necessary relationship between the customer and the development team doesn't exist and mutual understanding is lacking.
Team Culture
In a team culture product is king. It's all about the outcome the teams deliver instead of the output. The organization is built around fixed, multidisciplinary, self-organizing teams who are given the freedom and responsibility to think of a strategy they believe will result in the best product. Everyone around the development team is focused on supporting and facilitating the teams in building great products. The teams themself decide what to work on and how much they can handle. This results in a clear focus and the opportunity to obtain a sustainable pace of continuous delivery.
The Development Team uses the Agile triangle to address the real goals of the project - producing value by delivering high quality, adaptable products that meet the desires of the customer and find a balance between the constraints cost, schedule, and scope. Product management is done via a product vision and canvas board, and techniques like story mapping to help understand the functionality of the system and effectively plan releases that deliver value to the users and stakeholders.
In a team culture, there is no place for detailed time tracking tools. It's all about the outcome teams deliver. If the outcome of a sprint (assuming Scrum is used) isn't satisfactory, the teams as a whole will determine how to improve. Studying the precise amount of written hours really is a waste of time. At the end of every sprint, the team itself produces an end-of-sprint report with the highlights represented concisely.
In a team culture, we value firefighters, but we value fire prevention even more (could be an addition to some famous manifesto...). And if a problem arises, it's the responsibility of the development team to solve it, with the support of a Scrum Master.
Customers are considered to be part of the team necessary to build a great product. There isn't a 'client-supplier' relationship with a thick barrier in between. One of the best products I've contributed to consisted of a collaboration of multiple suppliers. The customer insisted all business cards were thrown away, including their own. From the start, we would collaborate as one team. To me, this is the best example of a true team culture and a healthy foundation to build awesome products.
Conclusion
In this blog post, I distinguished the difference between the project culture and team culture. Because of the used tone, it is probably quite obvious what type of culture I prefer. I believe a team culture will result in satisfied employees and customers, great products and a solid foundation for the organization.
What is your experience with both types of culture? Feel free to share your thoughts!