On 13th July we had our meet up with Craig Larman in a very nice auditorium at Delta Lloyd in Amsterdam.
Craig Larman surprise talk was about the history and (de)scaling of agile.
One of the directors of SAGE was discussing why the programming had gotten out of hand. He was then asked, “ if you had to do it all over again, what would you do differently?”
His answer: “ Find the ten best people and write the entire thing themselves.” After a year working in large, multisite offshore development, his key advice is:
- Large – don’t
- Multisite – don’t
- Offshore – don’t
The reasons for large scale are often a side effect of thinking mistakes and misunderstandings about the nature of the word. For example thinking that software development is a manual activity like digging a ditch, where when the hole is twice as big, we need twice as many ditch takers, instead of recognizing (to quote Kent Beck) “Software development is a learning activity, with code as a side effect” and the dynamics of software development are often nonlinear. There are 17 major factors to measure productivity. The second most important one is the size of the requirements that are added to the process cycle
Craig has worked with developers in India and China, not by video conference, but actually sitting with them in a room for months, developing software. It is actually horrible if you actually experience that. If you work in a multisite environment, you should go and see for yourself to see how much crap, waste, dysfunction, and friction there are in a multi-site organization.
In India there is the Mother-in-law problem: if you get married and tell your mother-in-law that you are a developer, she looks at you whether your career has failed. “ Are you not a manager yet?” she will ask. This leads to the 4-year programmer problem in India: nobody wants to continue a career as a programmer. If you go there yourself you will notice the low quality of code that is produced in offshore countries. CMM-5 in India is a question of bribery. If you pay the right people, you can get whatever certificate you want.
The market for Agile and Scrum in the world is almost zero. The market for fake changes is massive.
Why do we need to scale? Why do you need more than 7-10 people to make any product?
Is LeSS for scaling?
LeSS is not for scaling, scaling is a bad idea. LeSS is for descaling and simplifying. LeSS is about deleting almost everything in your organizational design.
Can LeSS be used in big complex organizations?
This is the wrong question. Traditional large groups are complicated – though not because they need to be, but because their organizational designs create an illusion of “necessary” complexity. Due to the complex organization, a lot of coordination between different groups is necessary. People try to smear Agile sauce to achieve Agile goodness, instead of asking the question: “ why is it that way?”, and that is what we are doing in LeSS.
How can we simplify the unnecessarily big and complex organizational design, and be agile rather than do agile?
The word Agile has been chosen to suggest flexibility and adaptability, but never speed, quality or productivity.
It is a scientific method that can be used when there are a lot of unknowns, leading to changing requirements, high variability, and high learning. We use assumptions, take a step at a time and based on the learning we take the next step in the most promising direction. In each process cycle, there is transaction cost. It is so rare now, so probably a silly example, but back in the 60’s and 70’s there was something called “manual testing”, which is part of the transaction cost. Because of adaptive means that we change direction frequently, the other cost is the cost and friction of change, the switching cost. (all of this can be found in Kent Becks first book) So an adaptive system should have low transaction cost and low switching cost.
What is different in large scale and small scale that influences these factors?
In a group of 5 people, human interactions are first order, like:
- Native Intelligence
- Psychological health
- Social health
But how does this work if you have 700 people working on one product (7 sites, 100 people per site, different disciplines per site)? In that case, the first order factor is structure. Human interactions become third or lower. Structure is the real influencing factor. You can improve behaviour, tools, interactions, love in the room and agile practices, but it is like rearranging the deck chairs on the Titanic, it is just meaningless. Because young agile coaches cannot change this, they think they can solve it by bringing more love in the room, but that completely misses the point in large scale organizations.
What needs to be done to be adaptive?
For example: close down 6 of the 7 sites, get rid of PMO, eliminate the architecture group, eliminate the testing group. LeSS descales organizational complexity, dissolving unnecessary complex organizational solutions, and solving in simpler ways. The 700 people in 7 sites are the problem. This cannot be solved by a new tool or a new way of working, it is part of the organizational design itself. LeSS is about deleting all things that are not necessary. If an organization is structured such, that for every product you need to go via 7 component teams (front end, back end, pricing module), coordination is unavoidable and leads to even more teams like Analysts, architects, integration workers, End-to-end testers etc that we all start producing their own artefacts to inform all component teams. All these teams will have their own queues, leading to raising lead times.
Stop using the term agile, because it has become distorted and misunderstood as meaning fast or quality or something like that. Use the term adaptive from now on, to go back to the true meaning.
Ban all jargon (like DevOps, Stories, Agile, Squads), from your vocabulary for the rest of your life, because it creates a false impression of change while nothing has happened (fake change). Simply stick to plain Dutch and plain English.
The lesson of this presentation: Think carefully about how people work together in an organization.
When your organization grows, simplify and descale your organization instead of scaling your organization by adding extra roles that create extra artefacts.
The full recording can be found here. (beware that the camera is focussed on centre stage, but Craig is often left or right of the camera. You can follow his speech via audio).