Welcome to newsletter 53
Past 3 newsletters:
Empirical Coach weekly newsletter #52: Changes to Scrum Guide coming
Empirical Coach weekly newsletter #51: User story is not a format
Empirical Coach weekly newsletter #50
Interesting Quotes
Dictators come and go, and when they go the dictatorship goes with them. When a true leader departs, the company he leaves behind is healthy, self-governing, vibrant, and intact. -Ricardo Semler
"What one programmer can do in one month, two programmers can do in two months." - Fred Brooks
Importance of Fuzziness and KPIs for Collaboration
If you have attended one of my LeSS trainings, you would have seen me sharing a video from Yves Morieux talks about the importance of measuring the right thing and how many KPIs don't encourage co-operation.
Here is an excerpt from his book Six Simple Rules, I am sure you would enjoy this.
“When companies only use individual KPIs to reward performance, people put all their energy into the individual output that can be measured, at the expense of cooperation and group results. But collective goals don’t do the trick either.
They are necessary, but insufficient. Unless cooperation also makes a difference to the individual, he or she will stop taking the risk to cooperate with others.
Yes, companies need measurement, and they should measure whatever is useful and measurable to monitor performance. But in order to foster cooperation, they must move beyond KPIs and other formal systems for appraisal. Since cooperation cannot be measured, rewarding people for their cooperation can only come through the personal recognition of the manager. Such recognition is the product, not of metrics, but of observation and judgment. As the word suggests, recognition is about cognition, knowing what people do and understanding what is really going on.”
There is another key nugget in the book about the importance of fuzziness
“Resist the pressure to clarify roles, decision rights, and processes. Try to keep appropriate fuzziness and overlaps between roles.
Beyond a certain threshold, clarity only encourages mechanistic compliance and “checking the box” behaviors, as opposed to the engagement and initiative to make things work.
The ambiguity is killing us. Nobody knows where his job ends and another person’s begins.” When somebody asks for clarity in this way, it is frequently an attempt to avoid having to cooperate. If you respond to such a request by offering complete clarity on where the responsibility starts and ends, another question is sure to follow: “OK, well if that’s how it is, and I’m going “to be held accountable, I’m going to need a few things: equipment, team, budget, and decision rights that clearly match the scope of my responsibility.” If you agree, and even if you are careful not to give too many resources, you will discover that you have achieved a “miracle.”
All the dependencies will disappear and the need for cooperation that goes with them; now the person who asked for clarity has complete self-sufficiency. The individual who is clearly accountable—thanks to that clarified list of responsibilities—can do without others and escape the servitude of cooperation. Each person can tend his or her own garden, not being dependent on others. But at what cost for the company as a whole? Self-sufficiency may be comfortable, but this kind of comfort is a poor predictor of organizational success.”
Large-Scale Scrum(LeSS)
There is an upcoming conference LeSSDays in Europe. It is an online conference, and I would be speaking at the conference.
You can join the conference here
Thinking about Design from "Practices of Scaling Lean and Agile"
Craig and Bas make some interesting observations about the Software Architecture, and thought would call it out here.
First observation—The sum of all the source code is the true design blueprint or software architecture.
The software design/code improves or degrades day by day, with every line of code added or changed by the developers. The software architecture is not a static thing. Software is like a living thing, more like a plant or garden than a building, and the living design or architecture is growing better or worse day by day.
Second observation—The real software architecture evolves (better or worse) every day of the product, as people do programming.
The analogy to gardening, parks, and plants is salubrious [HT99]. For example, there is the noun and verb landscape architecture—it is normal and skillful to consider and ‘architect’ the big picture when planning a big garden or park. And yet people do not leave it at that. Because of the visible nature of a park, and because plants grow, it is crystal clear that the actual landscape architecture will quickly devolve into a jungle of weeds without constant gardening or pruning by hands-on master gardeners mindful of the park’s original or evolving vision.
We have a friend who works as a landscape architect for golf courses. He sees with his own eyes the details of the real, living course while it is being created, walking around it and playing golf—in touch with the reality of what is.
This shift from the metaphor of architecting and building software to growing it like a plant has influenced many people reflecting on successful development. For example, Frederick Brooks, in his famous article, No Silver Bullet, shares his shift in understanding:
The building metaphor has outlived its usefulness... If, as I believe, the conceptual structures we construct today are too complicated to be accurately specified in advance, and too complex to be built faultlessly, then we must take a radically different approach... The secret is that it is grown, not built...
Harlan Mills proposed that any software system should be grown by incremental development... Nothing in the past decade has so radically changed my own practice, or its effectiveness... [Brooks87]
Third observation—The real living architecture needs to be grown every day through acts of programming by master programmers.
Fourth observation—A software architect who is not in touch with the evolving source code of the product is out of touch with reality.
Fifth observation—Every programmer is some kind of architect— whether wanted or not. Every act of programming is some kind of architectural act—good or bad, small or large, intended or not.
If you like this newsletter, please share it with your friends. You can subscribe to the newsletter here
Upcoming Events
Look forward to public courses in Brisbane, Melbourne, Sydney, Perth and India in 2020. Possibly expanding to other countries.
I have conducted several online training for Certified LeSS Basics and Provisional Certified LeSS Practitioner till date. I recently completed a few and would be announcing a few more soon. Keep an eye on this newsletter.
Many might not know that I also offer Certified LeSS Executive training. This is specifically for senior leaders who might be interested in learning the intricacies of management and structure to influence the culture.
Please reach out: venky at agileworld.com.au for further details.
About Empirical Coach
If you are interested in Agile coaching, mentoring and training services, please reach out to me (venky@agileworld.com.au). We have a team of passionate coaches collaboratively working together and could help.
Our team has deep expertise in Agile, Lean, Systems Thinking and Complexity science. We look at challenges from different angles and apply tools from various schools of thoughts. This is different from the cookie-cutter approaches you see around. We are proud to be different.
I have been deeply involved in many of the initial experiments that lead to the birth of LeSS, one of the countable number of people globally.
Blog | LinkedIn | Twitter
