The 9 Smells of an Organization

Posted 3/15/2016 8:06:17 AM by BARRY OVEREEM, Professional Scrum Trainer at

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:

1. Constraint versus Stretch

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.

2. Compliance versus Discipline

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.

3. Control versus Support

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.

4. Contract versus Trust

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. 

5. Project versus Product

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.

6. Plans vs. Prognosis

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.

7. Commitment versus Forecast

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.

8. Resources versus People

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.

9. Requirements versus Desirements

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

manufacturer coupons for prescription drugs prescription drugs coupons manufacturer coupons for prescription drugs

Read More


About the author: BARRY OVEREEM, Professional Scrum Trainer at

Barry Overeem is an Agile Coach at Prowareness and Professional Scrum Trainer at He is also an active member of the Agile community and shares his insights and knowledge by speaking at conferences and writing blog posts. Since 2000 he fulfilled several roles within the ICT, these vary from application consultant, project manager and team lead. Since 2010 his primary focus is applying the Agile mindset and the Scrum framework. Barry is specialised in the role of the Scrum Master and servant-leadership. Due his own practical experience as a Scrum Master, Barry gained a lot of experience with starting new teams, coaching teams through the different stages of team development and applying different types of leadership. Sharing these experiences and hereby contributing to other persons growth is his true passion!

Subscribe to App Developer Daily

Latest headlines delivered to you daily.