How did industrial people take good care of machines? They took them apart, let’s say once a year. They had a close look at the pieces, did some filing on them, added a little oil, changed some gear wheels, did some repainting and put the machine back together.
Great way to handle machines.
But there should have been a notice in the maintenance manuals of such machines saying “Not to be used on human beings”. A Team of people is not a machine you can take apart to examine the individual parts, file or replace some of those parts and put it back together.
People are not replaceable pieces of machinery.
Still, it’s what we do and how we treat them. We use the label ‘resource’, i.e. (see dictionary) a “source of supply that can readily be drawn upon when needed”. And we think we can make up for this totally inappropriate definition by adding ‘Human’ to it. So, what do we mean then? A human form of a replaceable hardware component?
People are not mechanical robots.
Too often people are reduced to just a sum of pseudo-capabilities like a diploma and a cv. But -surprise, surprise- even if different persons have near-identical lists of such ‘properties’, they still have different backgrounds, personalities, private lives, interests, senses of humor, and all those other aspects that make working with people so exciting. But -indeed- it does prevent them from being interchangeable.
Too often is the uniqueness of people blatantly ignored by an overload of ‘HR’ strategies, policies and penalizing KPI’s. And at a yearly performance measurement this human hardware part is investigated against them. And sent home with a set of reprimands that it should interpret as something ‘to learn from’. Does it really come as a surprise if the surveyed object does not feel too motivated by this type of machine-like maintenance procedure?
How then about some positive change? Improve this domain of the world we work in? How can Agile thinking help?
In The Iron Triangle of Valuation I presented the hideous career path that is projected on people in IT. It forces people on a path that typically leads from developer to analyst to project manager. And if one’s lucky the gates of management are opened to have a ‘real’ career. I introduced a triangular-balanced context to replace it, allowing people to prosper and do well in a ‘role’, taking away the focus from ‘position’ and endless stairs.
We can use that base model to fundamentally reform the way we work with people, the way we observe and assess people. Certainly for organizations making the shift in external orientation to a Customer-Oriented Enterprise this is a promising internal re-organization opportunity; it aligns the internal thinking to the external orientation.
The triangle of valuation describes the context that needs to be created first before people can prosper and develop their potential. It demands that organization and individual agree on:
- The individual showing a clear interest in performing a set of tasks and activities (or moving to those tasks),
- That person demonstrating a talent (or having the potential to grow a talent) in performing those tasks and activities,
- The organization’s ability to offer (have or create) a domain in which the tasks and activities can be performed and are valuable.
Intermediate evolutions need to be transparent.
Individual and organization agree on gradual follow-up and evolution. Because it is highly disrespectful to confront people once a year with results from the organization’s perspective without having given the people the chance to adapt and improve. And in the end, the organization is neither getting any benefits from this. The core idea of an evolutionary approach is that, if a yearly review is considered important, there should be no surprises at that time of evaluation. All involved should already be aware of the results that have, or have not been, realized, and what has caused it to be like that.
The clue is that in today’s world of continual change and evolution, there is no reliable way to impose upfront, detailed definitions, expectations and predictions, not even for individual performance. This should be replaced by an incremental path allowing the assessed and the assessor to meet regularly to conversate, learn, interact, review and re-plan. They must travel a common path upon jointly set objectives and forecasted expectations, with a frequent demonstration/summary of progress.
Incremental evolution with room for empirical improvement must be added to respect the individual and lead to true valuation. The individual will perform to the maximum possible, taking into account changing circumstances beyond the individual’s control. At least yearly, but possibly earlier, objectives can be collaboratively reset, and even the base triangle can be reviewed. A win-win situation will emerge. Valuation can take material, financial or non-material forms.
If the legs of the triangle are fixed upon the wrong assumption of total predictions, without room for evolution and incorporation of new insights, valuation will suffer from that fixation, not originate from it.
Agile enterprises embrace people practices.
After the transition from ‘Human Resources’ to ‘people practices’, assessments will be focused on helping and facilitating people, no longer on mere judging. It is the only way to give rise to the emerging individual performance that has the potential of improving overall enterprise results. It’s a model that aims at emerging performance. KPI’s represent a technique that can still be added, but that should be done with the objective of providing information, not be judgmental in itself.
Results will be the result of emergent performance. At least a result will be the hard work itself, even it only pays off in the future. The introspective get-together’s serve to check whether we are still learning from it. That’s why these intermediate reviews take place. Pressure is taken away from hard-coded results and shifted to context, learning and improving. And a yearly retrospective review creates value in stepping out of the normal rush and taking a look at the bigger picture, and insert evolutions to the triangle. IF the base context, expressed in the 3 legs of the triangle of valuation, was in place. What else would be evolving?
And if an intermediate introspection requires a substantial revision of the wider context, as expressed in the triangle, take enough time to close the process and restart.
Agile enterprises embrace emotions.
And finally we can stop blaming people for being “emotional”. AS if we are not in a people business. Emotions are the essence of human nature. And in case of a conflict, look first at the triangle of valuation to check whether the right context is still in place, in the current circumstances.
Is this an emotional, highly personal desire? Of course it is! It would finally create a context that will not only just tolerate deviant people like me, but possibly even appreciate them. That in turn could be a stepping stone to stimulate them and open ways for them to truly innovate.
Kan and Ban are Japanese for Card and Signal. A Kanban (signal card) originates from the Toyota Production System (TPS) where it is a physical card that visualizes a pull question for inventory. It serves to minimize stock in a ‘Just In Time’ strategy and is a way to ‘eliminate waste’ while assuring a continuous flow of goods.
In an Agile context, a Story Card is a Kanban. Out of eXtreme Programming it grew into an established Agile practice in describing a feature. A Kanban Board holds the active Story Cards per ‘status’, thus being an Information Radiator (term by Alistair Cockburn, also my inspiration for the Games metaphor).
My Scrum Product ànd Sprint Backlog items are User Stories. (‘Minimal Marketable Feature’ is more generic, but I stick to ‘User Story’) The Sprint Backlog is made visible by sticking a printout from my (Excel) tracking model on a wall. Around the Daily Scrum (we do it standing up) each Story Lead writes the estimated time to finish a Story on the printout and I create the Sprint Burndown. That works fine. We use a Kanban Board only for feedback from functional testing. This is generally too small to create a Story (would be ‘waste’).
