.png)
Proudly brought to you in association with S A Partners, a world-leading business transformation consultancy.
Introduction
Dr James Coplien. James is a writer, lecturer and researcher in the fields of computer science.
James is known for his work on patterns in software, program design. James and Jeff Sutherland and 18 co-authors published the book titled "A Scrum Book, The spirit of the game". This book outlines many of the key patterns of success in achieving high-performance teams. Let's get into the episode. James, thank you so much for joining me today.
Summary
Start in life: Technology and people.
James started as an electrical engineer in training, went on to an undergraduate degree in computer science and later gained a PhD. In the doctorate, he began with a technological focus. He loved to tinker with electronics as a kid and built some simple computers at home before actually using a real one. James went to college, started work at Bell Laboratories, loved the technology there, and enjoyed the work. He did what he feels now were some pretty amazing things.
Several years later, a friend of his, Moody Ahmad, said, "You know, it is all about people, this technology stuff", and that's what got James into the human side of things. He still keeps his fingers in technology, specifically object-oriented programming. But his passion is more on the human side, working with organisations and looking at development processes and organisational structure. James has worked a lot with Jeff Sutherland in the early days and is still part of the Scrum community.
Working at Bell Laboratories - all problems are people related.
While working at Bell Laboratories, he had a great boss, Steve Bauman, who said, "There's never been a technical problem that Bell Laboratories has been unable to solve". All the problems were people problems. James is an extrovert and likes working with people. He speaks about working with Bell Labs Research, studying development processes. At that time, AT@T tried to break into the European market with the ISO nine 1000 trade barrier and needed ISO compliance. They had documents and made role activity statements from these. James was to study the organisation and make role activity statements based on his findings. When they compared reports, there was no correlation, and he was never allowed to publish his results.
It was so clear to James that that's where the problems are. The dysfunction in organisations is usually a people issue. If processes are not the right thing to study, what is? Relationships and social networks.
The Mess Pattern and working with Nonaka Sensei
James thought it's about relationships and social networks. But then he started noticing specific configurations arise again and again, in sick organisations, like highly centralised control by managers, or disconnected roles, or time serial sequences. And some patterns reoccur in successful organisations, and is what James called the 'mess pattern'; it had no recognisable structure.
Later, James was doing many empirical organisational studies over ten years of between one and 200 organisations to find out what made them work. In one especially effective organisation, of only twelve people with four developers, one of the things that made them effective was the four developers meeting every morning to discuss:
What did we do yesterday?
What are we going to do today?
And what impediments are in our way?
James published a paper on the mess pattern. Others began to notice, and James worked with Jeff Sutherland, co-authoring "A Scrum Book, the Spirit of the Game" with many other co-authors. He also immersed himself in Japanese culture and learned about Takeuchi and Nonaka. James worked with Nonaka Sensei, who had studied successful organisations in Japan and noticed a pattern of everyone doing everything simultaneously. It reminded him of sashimi on a bowl of rice: every task was overlapping. What would the human equivalent of sashimi be? Well, it's people overlapping each other, like people with their arms around each other's shoulders, like a scrum in rugby. And that's where the word Scrum comes from in Agile.
The work by Takeuchi and Nonaka grew on James. He was also always interested in the Chinese classics. These elements emerged into an integrated worldview, a whole system that is wonderfully beautiful and consistent. Christopher Alexander had a similar view of architecture. He wrote a book called "A Pattern Language" and another called "The Timeless Way of Building". So this would become another part of the language and formalism that James uses to describe and convey how one approaches the development of a complex system, something like a development organisation.
James believes that the term 'patterns' probably came from his previous work with software patterns. So initially, he was looking at patterns and architecture and software architecture for object-oriented programming. He is also one of the founders of the Hillside Group, which launched the patterns in the software discipline.
Buffalo Mountain Pattern
James wrote his first pattern, terribly terribly named Buffalo Mountain pattern (you can hear the humour in this episode!) It was an organisational pattern that used the same form and systems thinking regarding how many complex systems and emergent behaviour works. Alexander had seen this in architecture. Biologists use the term for the configurations that arise spontaneous symmetry breaking, which is how patterns form from more scientific theory and theoretical point of view.
Swarming Pattern
Everybody is doing everything all of the time: the heart of Scrum.
Swarming is also known as single piece continuous flow or one by one production.
Did Scrum come from the Toyota Production System? Well, kind of. This notion of single piece continuous flow has to do with waterfall development, which is what Toyota does. Relating to Nonaka Sensei's observation of the sashimi type of behaviour - everybody doing everything at the same time is the swarming pattern.
Cross-functional team and co-located team patterns
You can't have specialisation. Anyone in the team needs to be able to look and say, Oh, this work needs to be done, and pick it up and do it. That's what enables everyone to do everything all the time. You also need a co-located team.
Daily Scrum
If you're swarming, you need a plan for what you're doing during the day. And that's the daily Scrum. The daily Scrum is not simply a reporting meeting with an agenda. The daily Scrum is a planning meeting; it's a small extension of sprint planning that you do day by day to accommodate what you've learned from urgent requirements.
A Scrum Book
Jeff (Sutherland) worked with the 18 co-authors, including James, on this book.
If you're at the beginning, you can use the patterns described in the book to move from incompetence to competence. Patterns aren't for building buildings. Patterns are to develop you: they're to put you in touch with the insight you were born with so that you can follow your instinct.
James believes that A Scrum Book is a Trojan horse book on the sociology of development. There's nothing technical in it, and there's nothing in it about software. It's about people. Humanity research grounded in sociological research, psychological research.
So it's not about how to do Scrum. It's how to be a whole human being as part of a culture that wants to do great things. And how do you do that? You'll figure it out!
Can patterns scale an organisation?
Have you seen a large (50-100 people) organisation really working well, where people contribute fully? Where everything fits together and adding more people corresponds to the productivity of the organisation? Probably not. James has not seen a single good study of a software organisation that shows us that scaling works. Four people created Skype, and then the company grew to 2000, and it died.
Because every person you add detracts from the effectiveness of other people on the product for about 25% for six months. Imagine taking a team with a velocity of 100 and splitting it in two. The resulting teams each have a velocity of about 30, for a total of 60. This means to get back to the original 100, you have to double the size just to break even.
So James doesn't think this scaling is a good idea. He does believe that scoping is essential.
James talks about multi-site development: he hates it. But sometimes it's necessary because you need someone in the country for localisation or because they're close to the resources they need for manufacturing.
James speaks about the management tradition of hierarchy and small world theory. So small world theory can do for 8 billion people what Scrum at scale cannot do for 600 people. What's wrong with this picture? Why does this work for 8 billion people? Because it's not hierarchical.
Scrum of scrums
A scrum master from each team would get together with the scrum masters from the other teams after the daily Scrum. It didn't work as scrum masters were process people, not technical people, and the problems were technical problems.
Hub
A hub is like the new Scrum of scrums, but it doesn't have to be about technical issues; it can be the organisation's core competencies. We could have a testing Scrum hub where did the testers come together to decide what conference we go to next? Or a chess hub where people who want to play chess just come together to play chess to blow off steam. Or management hubs. Hubs are common sense; they are what people would do naturally to work in a large community.
Steve Johnson, an innovation researcher, notices that innovation tends to come from cities, and this is why cities spawn innovation. Well, part of it is that you have a lot of diversity: having many different perspectives on things. And part of it is because you break down the hierarchy. People just meet each other in the street and have these chance interactions.
Where does management fit?
So often, in Scrum, people will say, okay, the whole world is these five developers and a product owner and a scrum master? Well, no. Who sweeps the floors, who runs a cafeteria, who locks up things at night? Management does have a function. You see this in Japanese corporations, not in managing development, but in managing the corporation. So there's more than just a scrum team.
In Japanese culture, you have executive management, and they don't interfere with development; development manages itself.
Executive management runs the corporation and answers the questions:
Where do we get funding?
What market should we be moving into?
What strategic alliances should we have with other companies?
What is our marketing strategy?
Should we start a new product?
Should we kill a product? A product owner will not commit suicide and kill their product; they need someone above them. What makes companies great is cutting the fat: noticing the projects that will not go anywhere and cutting it.
The Executive has the money and power - the big guns. If a team of developers can't solve their problems, they need to get help, maybe from another Scrum Master or Product Owner. And if they can't solve it, they go to management. If something prevents the team from getting something to the customer in this sprint, management has the big guns. And so they're there to serve the team.
The CEO of an organisation could be both the product owner, the one who's accountable for ROI, or the Scrum Master, who serves the entire organisation. The goose that lays the golden eggs is the developers. Managers have a servant function in that they should do everything to help the developers at their level. On the other hand, developers aren't in the position to steer the big ship. That management function is still needed to steer the ship. But we don't need our middle managers and hierarchy.
James speaks about organisational structure in Denmark - it is very flat. Management is not viewed as a real glory power job. It is not about filling out the hierarchy with control points or having an extensive formalised governance system for interaction between managers: the governance is emergent and is very lightweight.
Toyota management made a strategic decision to export cars. So why do you find all their vehicles in Australia, in the US and in Europe? It's because it subsidises the price of building cars back in Japan and lowers the cost they can charge for Japanese people. So this is a strategic decision on the part of the management of the company.
A manager is looking for making those kinds of strategic decisions, setting the vision and level of value for their organisation. They can kill projects. A product owner, on the other hand, like a chief engineer at Toyota, is looking at value from their product. How can you make this car perform well? Get good gas mileage? Have sexy styling? Different dimensions of value from each other.
How does someone in a traditional hierarchical organisation struggling with keeping up make a change?
James recommends the book "Becoming a Learning Organisation". And the authors said, fundamentally, some organisations and some industries are so woven into the fabric of a culture that it's just hopeless to change them. The examples they gave were the post office and government. They have some economies of scope. But the cost to serve society is very high creates tremendous inefficiencies because they're dealing with throughput rather than latency. James lives in Denmark, and it takes about six weeks for him to get a letter from North America. Why? They're dealing with throughput because they have this vast scale and struggle to optimise latency. James believes it could work if you turned it loose to self-organisation, like Federal Express. They have discovered the value in lowering the latency, which is worth charging money for: there is a market for reducing the latency (of product moving from one place to another).
So what to do if you're in a large legacy organisation to create change?
Small startups
James offers the following advice; become a rebel, insulate a small group, build a skunkworks off to the side. Show that you can take on the organisation and rebuild what they make with your small team. But it would be challenging if you have a blocker - someone who finds a reason to say it didn't work.
James had a friend Dennis De'Bruleur who taught him everything he knows. In 1979, James joined AT&T with a workforce of one million, designed for volume rather than latency. It took six years to develop a new system, though the systems were huge and ultra-reliable; three seconds of downtime a month: incredible quality and incredibly great products. AT&T faced a new world with rapidly changing technology; the internet and IP were coming along to support voice. And Dennis said the best thing that AY&T could do is build garages up and down Naperville Road. Imagine the line of garage shops, small startups, like Hewlett and Packard did.
How about turning people loose? Yeah. Have your people get out there and give them money to do something interesting. And you're scaling your business. James thinks big companies shouldn't grow the existing development; instead, they should put the money into something else. Toyota figured this out a long time ago. If they build an assembly line for a car, they'll create between 300-600 thousand cars and then rather than putting money into improving that assembly line, they design a new car. So don't grow the current organisation. Build a new product.
What's been a recent insight or learning that you've had?
James gets a lot of little things and also slow hunches. There's a growing hunch about the importance of swarming in Scrum. There is also learning that working remotely over zoom is not nearly as bad as fun. We will all probably go back to co-located work once this is all over.
Tech has made it easy to connect, even with James in Europe and me in Brisbane, Australia. And this new world makes it easier to be able to communicate and share, which is fantastic. Thanks, James, for your alternate view on creating a better future and thinking about what the future holds for business. There are not enough alternate views and discussions in our society. I welcome them because if we can all challenge our minds every day, we're constantly learning.
Key Takeaways
1. Patterns of high-performance teams are all about people, and they are a natural social phenomenon
James mentioned that the patterns of high-performance teams and organisations they have defined are people-based. They are natural patterns based on human traits. James said the swarming pattern, small groups of differently skilled team members gathering regularly to plan, overcome challenges and move forward towards their goal. I have seen this pattern occur in a crisis within highly bureaucratic organisations. The crisis creates collaboration and a swarming approach. Unfortunately, when the crisis is over, people go back to their silos and traditional practices. James provides a great tip around forming small pilot teams or even separate organisations of small groups focused on a new innovative approach and product.
2. Autonomous self-organisation at the front line is key to success.
Autonomy is part of human nature. We all want to be able to create, contribute and play a role in our future. Autonomous small front line teams that have within them the skills and capabilities needed to create excellent outcomes for customers are naturally going to be highly agile and innovative. They are all close to the customer; they have the skills and capability to create and deliver excellent outcomes for customers within their small group. These teams are empowered, motivated and can directly see the results of the work they do for customers. Startup companies evolve from small autonomous front line teams. Unfortunately, as many of these companies grow, they lose this culture. As James mentioned during the show, this does not have to be the case.
Quotes
05:59min Then we started noticing, if you look at the pictures of these social networks, there are certain configurations that arise again and again in sick organisations. Like highly, highly centralised controlled by managers, or disconnected roles, or time serial sequences. And there are patterns that, that recur in successful organisations, and notably, the pattern that recurred in successful organisations is what I called the mess pattern: it had no recognisable structure.
08:03min And it reminded him, he said, If this were a Gantt chart, or a pie chart, everything all the tasks should be overlapping and reminded him of sashimi on a bowl of rice, overlapping pieces of fish, like overlapping tasks. On a pie chart, we thought, what's the human equivalent of sashimi? And he thought, well, it's people overlapping each other, like people with their arms around each other's shoulders, like a scrum in rugby. And that's where the word Scrum comes from.
18:26min But Alexander says something interesting in his book with his using patterns to build, you know, towns and neighbourhoods and buildings and so forth. He says, If you ignore these patterns, and you just put things together according to the constructs of your culture and ignore these patterns, you will fail. But if you faithfully follow these patterns and use them, together with other people, to follow them and build a city and a town and a neighbourhood and building, you will fail. Patterns aren't for building buildings. Patterns are to build you. They're to put you in touch with the insight you were born with.
23:02min Because every person you add detracts from the effectiveness of other people on the product for about 25% for six months. And if you take a team and split it. Let's say you have a team with a velocity of 100, and you split it in two; usually, the resulting teams each have a velocity of 30 for a total of 60. Which means to get back to the original 100, you have to double the size just to break even.
33:58min So one of the functions of management is to manage the enterprise. A second one is they have, they're the big guns. They have the money. They have the power. And so, if you look at solving a problem, of course, developers should be solving their own problems. If they can't get the help of a scrum master, and maybe you pull in some other Scrum masters. And maybe they pull in a product owner. And if they can't solve it, you go to management. If there's something that's preventing us from getting something to the customer this sprint, management has the big guns. And so they're there to serve the team.
35:12min So, I think there's this, this realisation that the goose that lays the golden eggs is the developers, and I mean we want to do everything to serve the developers at their level. And so management has this servant function in serving them. On the other hand, developers aren't in the position to steer the big ship. And so the same people who are doing that are steering the big ship. And we still need that management function. But you don't need our middle managers and hierarchy.
42.34min But we're facing a new world with rapidly changing technology. And the internet and IP coming along to support voice. And Dennis said, "The best thing that AT&T could do is build garages up and down Naperville road". Yeah. With the image of, you know, people starting garage shops, like Hewlett and Packard did, right? Yeah, a whole heap of startups. How about turning people loose? Yeah. And just having people get out there and give them money and say, you know, go do something interesting. And with scaling? This is what I think these big companies should do that have all this money that they're using to grow development. Don't grow the existing development; put the money into something else.
Links
Brad
Brad is proud to support many Australian businesses. You can find him on LinkedIn here. If you’d like to speak to him about how he can help your business, call him on 0402 448 445, or email bjeavons@iqi.com.au. Our website is www.bradjeavons.com
James
James' LinkedIn Profile: linkedin.com/in/coplien
Email: jcoplien@gmail.com
Thanks again for your time and knowledge, James. Bye for now.
Written by Emily Jeavons