I was asked why some developers don’t have parties or late night coding sessions. I do not think it was meant literally, since organising a party is a trivial activity and does not warrant a discussion.
I understood the question to be why wouldn’t they be as involved with their projects as others might be elsewhere. After all, celebrating success or staying late to meet a deadline is the result of being engaged, involved and caring about the projects one is working on. Consequently, not celebrating success may be a symptom of not being engaged, nor involved nor caring about those projects.
I propose that they do not have parties because their management style is “Command and Control”. They have a hierarchy and teams are told what to do. Teams have leaders that enforce C&C upon their members. There is a separation of duties and expectations across teams and the relationship between all teams is defined by their relative roles in the project’s lifecycle. A “food chain” emerges that is defined by “suppliers” and “customers”. A team’s role in the project is either to serve another team’s needs or is entitled to another team’s services.
This vision is well suited to the C&C management style, which clearly defines the roles and behaviour for the participating teams. The teams, however, rarely have a say in defining the goals of the product nor a say in the overall strategy of achieving those goals. Value is skewed and variances from it are not tolerated thus creating more problems for future business and technological change.
Handoffs between teams are mandated, rarely with any multilateral conversations, and the handoff of requirements is basically synonymous with “Shut up, this is what we want, what’s the estimate?”
C&C stifles independent thought and is inconsistent with excellent programming, which demands intelligence and creativity.
No one would think of ordering the sax player to play certain notes in a Jazz session. Developing products is closer in structure and dynamics to Jazz sessions rather than to orchestrated classical music.
The C&C approach distances people from the product so much that moving the project to the next station in the workflow is met with a sigh of relief …not with the joy we all want to feel when creating something of value. No one in the C&C production chain feels as though they own the product. No one thinks to throw a party because they do not have shared values to celebrate.
C&C demotivates creativity, teamwork, and the drive it takes to work long hours or over the weekend. Under C&C, people wait to be told what to do while the list of backlog tasks becomes a black hole of client frustration.
Another reason is that developers are often described as “resources”. Just by that outlook, we’ll fail. We are human beings with names, abilities and skills. Any project plan will fail if we do not address our people on a personal level, taking their strengths and weaknesses into account. When that is not a part of management practices, teams are manage like conference rooms – available or busy.
A happy, engaged, concentrated developer will produce quality software, all else being equal. A resource is acquired, used, then relinquished. Have we ever seen conference rooms get together for a party? Resources don’t have parties, humans do.
Product Management, Marketing, PMOs, Developers and QA should all meet and brainstorm throughout the project’s lifecycle. Without collaboration, there is little creativity and even less ownership. No one is motivated to pitch in to make better quality products. Teams will not feel ownership, have parties or mark the occasion of software releases if they aren’t invited to actively participate at the beginning. Because of separation, developers are never present at business meetings, and don’t have the opportunity to fully understand the client’s needs. Instead, they are ordered to write code (quickly).
I doubt that we will ever see self-organising teams or a true sense of ownership as long as C&C and segregation is instilled in management’s culture. We need ownership and team collaboration. Alas, teams find themselves against each other in a game of politics. There is scarcely any collaboration between them, only downstream C&C. In some companies, PM does not stand for Project Manager, but for Political Manager.
As a consequence, creativity and communication have been replaced by stale, boring, incomplete and sub-standard power-point presentations. They present lies: the business unit grossly exaggerates the product’s value and the developers exaggerate the cost of its implementation. Everyone is scared.
Another symptom of C&C is that we do not share goals. Since we are broken into segregated teams, each tends to develop their own set of goals and priorities.
Those goals are then presented (barked) as imperatives to the other teams. Product Management’s goal is to have something available in the market. The developers’ goal is to have something adhering to current best practices and quality standards. Project Management’s goal is to satisfy Product Management and so forth. The lack of shared goals divides the teams, creates the need to run interference, and justifies still greater C&C.
I don’t know what value the other units extract from such fiascos, but developers do manage to extract experience and technical problem solving skills, not the least of which are getting around SysAdmin and Network Engineering obstacles that diminish their productivity.
So theirs is not a total loss, but how could anyone expect any team to rejoice at the release of such products? The feeling is of regret, if anything, at having been forced to write rushed code for a perceived meaningless business case. No parties there.
On the other hand, in startup restaurants cooks also take out the garbage, and the owner also sweeps the floors. In software development, developers take QA’s testability needs into account when writing code without being asked to. The business analyst works with the product manager in optimising the process before feature requests are discussed.
I propose that we form project-teams from all disciplines that would report to the project itself, to give all the participants a sense of ownership. I’ll argue that this would lead to self organising teams and that it would also lead to parties, that there would be no more such questions and that I would not have needed to spend so much time writing this apology for bad management practices.
Ugh, what a dismal end to this article. So on a happier note:
Come to planet agile and enjoy the party!