Command & Control Management – The Party Killer


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!

Advertisements

DDD – Document Driven Development


We rarely document. We are used to being handed a set of PowerPoint slides that describe, on a very high level, the business need for software. We roll our eyes at the slides, and get to work, asking questions, clarifying the needs, hope to understand them and start imagining features and how we can deliver the implementation within the requested timeline.

If we follow the Agile framework, we’ll translate the transformed slides into stories. We do so and derive tasks from them. If we’re lucky, we might be able to condition the business to accept deliverable milestones that are aligned with those stories.

Using BDD, we’ll transcribe the stories into Gherkin and using TDD, we’ll start coding tests at that time (rSpec, Cucumber).

As development gets under way, we cycle through iterations and we deliver collaboratively.

After the celebrations, all the good things mentioned above (stories, milestones, BDD, TDD) evaporate as the project starts gliding at low altitude as the business moves to new territories. We’re left with mundane maintenance and tickets are opened for small bug fixes and minor enhancements. Stories are no longer written as “it’s not worth it” and small changes are never fully documented.

The project stops being documented and over time, as the team members rotate and business rules change, people no longer remember why we check-off the ‘accept contract’ terms after signup and not on the page where the user enters their email address. It so happens that there will be a major impact on the back-end provisioning system if we change that.

I think the pattern is clear – If we don’t use our documents, the whole eco-system of our product degrades to entropy and will ultimately lead us to revival by rewrite, or at least by going through the analysis again and likely to some re-engineering. Time wasted.

What I would love to see is a system whereby the development and maintenance is driven by documentation and that the documentation drives the deliverables.

The pieces are there, we just need to use them:
Participate in the requirements phases, translate them to stories, deliver story implementions. Always, recurringly. Never stopping this cycle.

Months from now, anyone reading your stories will fully understand why the system behaves the way it does – people like to read stories and will understand the system on their own terms. New hires in the business will use them as a guidline on how to perform their jobs. New developers to the team will have a standard to meet when fixing bugs or evaulating new or changed requirements.

We will end up with a document-driven system, accumulating a library of living documents that drove our software development effort. Any new contradictory story will violate the automated validations for previous generations of stories and will stop us in our tracks, showing us exactly where the business flow will break if we add that new feature. No one actually needs to know this in advance: Let the business tell new stories and see how the system reacts. It’ll tell us whether we’re in violation of any existing processes and alert us automatically.

If you’re using Gherkin and Cucumber already, put them front and center of your development workflow and don’t let go of them!

 

The tip of the (good) iceberg


Recently, a “perfect storm” situation occurred when we realised that there was a convergence of a new business need with an old technical need.

We have a technical issue that we wanted to deal with for a long time and yet never got to it because of high-priority tasks requests for the business. Our issue has to do with overhauling data structures and internal SOA processes to be more flexible and to be able to support business requirements in the future. The tasks and migrations were analyzed and estimated at “medium” and “hard” complexity levels and felt like an elephant in every meeting concerning the project, which is a central one in our business.

The “perfect storm” appeared when the business unit requested a feature that was solved by our internal analysis as part of the overhaul, but the key factor was that they asked for an initial implementation where only 20% of the customers be effected.
We were confronted with a situation where both parties had the same goal – we had technical justifications to make what we saw as needed changes and the business unit had a market-driven justification for asking for changes. This is a perfect situation to be in as both units are aligned and there is no conflict of interest.

The beauty of the situation is in the “20%”. By requesting that only a selected 20% of the customer base be affected, we could now picture the technical scope of the project with a different mindset – one of depth of development for a limited breath of the customers. By this I mean that we are able to plan for the “most value” for the business unit – producing working software to solve for the 20%, while back-filling the rest of our technical debt towards this project by the current processes till more is developed for the next segment of customers. True, there will be “production support” till we achieve 100% customer base, yet solving for 20% economically justifies that cost and effort.

The result is that the business unit will see only the tip of the iceberg of this project with immediate value, while we work on the invisible part that will cover the subsequent market segments that will be addressed sequentially over time.

The convergence of the business goals with ours makes it possible for us to succeed with this project and introduce it to the market in small segments. If only all business and technical requirements were so well aligned!