A few months ago I first saw the brilliant speech 'The Smell of the Place' 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. In his speech he uses the example of downtown Calcutta in summer, this place makes him feel tired and lazy. The opposite is the Fontainebleau forest in springtime, which makes him feel energized.
In this blog post, I will shortly describe the examples that are presented during the speech and define some smells that I have interpreted and experienced in organizations.
Examples of Organizational Smells
In his speech Prof. Ghoshal gives four examples of smells in organizations, the ones on the left describe "downtown Calcutta", on the right is "Fontainebleau in spring":
1. Constraint versus Stretch
The strategy created by top management that boils down to the frontline person can be seen as constraints. Stretch, however, 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 are all examples that can be related to compliance. The opposite is embedding norms of self-discipline where trust and ownership are given to employees.
3. Control versus Support
The relationship with management exists to control each other. While 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. While it should all be about trust. Trust the employee to get the job done.
"Changing people's behavior is not about changing people, but changing the context which they are in: the smell of the place." - Prof. Ghoshal
Other Smells I've Experienced
Recently I gave a training in which we discussed the different smells we recognized in organizations. The examples I brought in are:
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 is 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... "Operation succeeded, patient died." Therefore I rather focus on the actual product (that also tends to have a longer lifetime than projects) instead of the temporary project.
6. Planning versus Prognoses
The term "planning" is contaminated beyond repair. This is the result of years of traditional software development. Planning is a synonym to Gantt charts, detailed upfront work breakdown structures, impossible deadlines, etc. Sure you need planning, but I prefer calling this a "prognoses". Scrum started using the term "Scrum Master" to clarify it's something completely different than e.g. the role of 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. It's related to 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 the seeming lack of grip that comes along with it. But luckily the Scrum Guide offered 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, then 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. Therefore 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 mentioned the term desirements to emphasize the difference with requirements in the traditional context. 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 'Downtown Calcutta' I often see in organizations and my preferences of 'Fontainebleau'. What are examples you recognize? Please share them if you have got any!