The 9 Smells of an Organization

A few months ago I first watched ”The Smell of the Place,” a speech by Prof. Sumantra Ghoshal. It's about corporate environments and the faults of management in creating a positive workplace. In organizations, it's all about the context. This has a huge impact on the behavior of employees. 

"Changing people's behavior is not about changing people, but changing the context which they are in: the smell of the place." - Prof. Ghoshal

Taking from Prof. Ghoshal’s speech, here’s some environments I’ve witnessed with “smells” that map to his views:

The strategy created by top management that boils down to the frontline person can be seen as constraints. However, stretch is when management creates a set of values and an ambition that invites and inspires employees to get the maximum out of themselves.

Planning systems, budgeting systems, financial systems and the like are all examples that can be related to compliance. The opposite are embedding norms of self-discipline where trust and ownership is given to employees.

The relationship with management exists to control each other. Instead, the primary role of management should be to help the employees succeed by giving support and guidance.

Everything is described as a contract: your job is a personal contract, your relationship with the company is a contract, and the budgets are personal contracts. Actually, it should be about trust - trust the employee to get the job done. 

First of all, there's nothing wrong with a project. But I often see organizations that start lots of projects with temporary teams whose main focus are deadlines, budget and scope. When the agreements made at the start of the project are accomplished, the project is a success. 

Of course deadlines, budget and scope are important, but in the end it's all about building a product that suits the latest expectations of the customer. A project that meets all the deadlines, is within budget and hasn't changed the scope can still result in a crappy product. The focus should be on the actual product (that also tend to have a longer lifetime than projects) instead of the temporary project behind it.

The term "planning" is contaminated beyond repair. This is the result of years of traditional software development. Planning is synonym to Gantt charts, detailed upfront work breakdown structures, impossible deadlines, etc. 

Sure, you need a plan, but I prefer to call them a "prognosis." Scrum started using the term "Scrum Master" to clarify it's something completely different than the role of the something like the project manager. For the same reason I prefer using the term "prognoses":  it isn't contaminated yet with all the bad smells of traditional software development.

Commitment might be the most abused term in Scrum. I think of the famous saying, "We ask them for estimates and then treat them as deadlines." In organizations starting with Scrum some old-school (project) managers fear a lack of control. 

But luckily the Scrum Guide offers them “commitment.” Development teams should commit themselves upfront to sprint results. No matter how complex (and by this unpredictable) the software, a hard commitment by the development team is a precondition. Should any unforeseen problems arise, than that's the problem of the development team, they gave their commitment, so they should fix it, just order some pizza and carry on! 

To me, commitment in this context smells. I prefer using the term “forecast.” When planning a sprint, the team gives a forecast of the amount of functionality they think they can deliver, given the available amount of knowledge. But taking into account the complexity of software development, giving 100% guarantees and impossible and meaningless. I rather trust teams they will do everything that's possible to deliver a valuable, high quality product. Fortunately, in the latest Scrum Guide commitment was actually replaced by forecast, I can only warmly welcome this.

People are resourceful, but they are not resources. Johanna Rothman puts it nicely: "People are not the same as desks, licenses, infrastructure and other goods people need to finish their work." Organizations that often talk about resources when they actually mean people, usually also apply all the other “smells” mentioned in this blog post.

In his book "Scrum - a Pocket Guide," the author Gunther Verheyen mentions the term “desirements” to emphasize the difference between them and traditional requirements. And although I won't use the term desirements in all my communication, I like the underlying message. To quote Gunther, "A desire is too fuzzy to work on and a requirement is over-specified and over-detailed. Therefore the term desirement is well suited to a Product Backlog item." 

Requirements are too often used literally, it's all required. When this mindset arises I like to use the term desirements, this at least guarantees a nice discussion!

These are some examples of the “smells” I experience in organizations. Are there any you have experienced? Please leave comments below.

If you have questions on the topic or want to contact me, you can email me.

If you would like to learn more about Scrum, find Scrum training or take a Professional Scrum certification assessment you can visit Scrum.org.