Scaling

I had a conversation recently that got me thinking. I had stepped out of my lane and someone was nice enough to politely smack me (not literally, but metaphorically) and point it out to me. It stung and it made me reflect. In the end, I am glad they did, otherwise I might not have realized the mistake I had made.

The Consultants Curse

This is a quote from Jerry Weinberg. What he is really saying is don't give unsolicited advice. This is where I stepped out of my lane. I was involved in a discussion on the NI forums when I sensed that one of the people I was talking to was having some technical issues and also having issues trusting some of the people they were working with. I firmly believe that trust is one of the most important qualities for a highly functioning team. I thought the trust issue was so important that unsolicited, I offered a few technical solutions and added "If you don't trust them, why are you working with them?" Note the trust part was something that they didn't even mention or see as a problem. They saw it more as something to work around than solve.

This person got upset (rightfully so) and sent me a private message. It was polite enough and there was definitely some negative energy there. It said basically "Don't lecture me. I work in a large company with 12,000 developers. You don't know what you are talking about. You are out of your lane." And I had to acknowledge that they were right. I don't have experience working with a 12,000 developer team. More importantly, I should not have given any advice, because it was never asked for. At the same time, my advice probably wasn't all that great or helpful. At such a large company this person likely doesn't have much control over who they work with and I probably don't fully understand their challenges and context.

I think that stumbles upon some reasons to avoid giving unsolicited advice. First, if it is not asked for it tends to generate resentment. The second reason is that sometimes as an outsider you may not have all the context. I knew this person worked at a large company. I did not realize they were trying to coordinate such a large team of developers. In the past I have worked for a larger manufacturer of nuclear power plants, and for one of the larger US Mining companies. However, in working with those companies I always worked in small siloed teams. I made the assumption that they were working with a smaller team. I was giving this person advice that would work with small teams and would not really work well with larger teams. No wonder this person did not appreciate my advice. Not only was it unsolicited, it was bad advice for their specific situation.

Questions

In the end, it was a good thing this person confronted me. I was out of my lane. I need to be more wary about giving unsolicited advice and spend more time understanding context. More importantly, for me, it prompted several questions and reflections about scaling that are worth investigating. I don't really have any answers. Maybe some of my readers do. If so please comment below.

How does trust scale?

I used to be a member of the Explorer's Club Of Pittsburgh (ECP). They are a group of climbers, hikers, backpackers, and general adventurers. They have about 300 dues-paying members and about 150 active members. They had monthly meetings and put on occasional official events and schools. Generally, the heart of the organization was informal trips. They had an e-mail list serve and members would post "I'm thinking of going climbing at Location X on this date. Would anyone like to join?" Anyone could post a trip. Anyone could sign up. It was very informal. There were no real requirements.

At some point, I moved to Colorado and joined the Colorado Mountain Club (CMC). I was somewhat disappointed at first in the way it was run. It was not what I was used to. Instead of an informal list serve, their trip system was very formal. They had an official calendar and website to sign up for trips. They had requirements, not just for trip leaders but also for participants. They had a whole grading system for what level of hiker you were and you had to progress through the ranks before you could go on certain trips. It felt a little stifling.

In thinking about the difference between these 2 organizations, the real difference was trust. This was driven by size. The ECP had 150 active members. I knew most of them and for anyone I didn't know, we had a mutual friend who would vouch for them. If someone didn't have the skills or fitness for a specific trip, the trip leader would know and be able to convince them that this trip was not for them. The system generally worked. The CMC was different because it was much larger. It had several thousand active members and ran a lot more trips. At that scale, it was hard to keep track of everyone and their skills and fitness. There was little trust. So they needed a more formal system. What worked for the ECP wouldn't have worked for them.

What stays the same?

When thinking about large groups versus smaller groups of developers, what needs to change and what stays the same? Which practices carry over and which don't? I've been reading the book Wild West to Agile by Jim Highsmith lately. Toward the end, it hits on the scaling issue a little bit. It breaks agile down into 3 areas:

• methods - these are many XP-type technical practices: TDD, pair programming, CI/CD, etc.
• methodologies - these would be more about how we break down and manage the work. This would include Scrum, SAFe, Kanban, etc.
• mindset - This is more about getting back to the agile manifesto and its value statements. It is the way we think about the whole entire process.

It seems from reading the book and my intuition that the closer something is to a mindset, the more transferrable it is. Mindset is very transferrable, methodologies not as much, and methods really tend to be hit or miss and/or need to be adapted to the context a lot more.

Where is the Breakpoint?

The obvious question is where is the breakpoint? What size of team causes this shift? This is important to me as a consultant. I want to ensure I'm not stepping out of my lane and giving bad advice. I generally work with smaller teams. I've got that part down. At what point am I exiting the small or medium team realm? At some point, I'll need to either change my thinking to accommodate a larger team size or just say "This isn't for me, I only work with smaller teams." It would be nice to know where that line is.

In Wild West to Agile the author does attempt to address this obliquely. He is trying to address the question of "Is Agile still relevant?" and his line of inquiry is still relevant here. He goes back to the Agile Manifesto and the tradeoffs. He poses the question: The Agile Manifesto says "We value individuals and interactions over processes and tools" As teams grow there are more individuals and interactions. At the same time, we need more processes and tools to keep chaos at bay. Do we reach a point where processes and tools become more important than individuals and interactions? If so, where is that point? How do we find it? You can ask that question for each of the Agile value statements. If you ask those same questions about the various agile practices you'd probably get different answers. This entire line of questioning ties into my previous point about mindset and values being more transferrable.

I remember reading a Malcolm Gladwell book - I believe it was "The Tipping Point." He mentioned that primates naturally keep their group sizes to 150 or less. The thinking is that above 150 people it is hard to have a relationship with each one and that once you get above 150 the group dynamic changes drastically. I don't know how much truth there is to that, yet it does give you a hard number and correlates with my ECP vs CMC story above (probably just a coincidence). Based on my experience 150 developers seems like a lot (at least for LabVIEW).

Technical Questions

This line of questioning can also extend to more technical practices

Framework - AF vs DQMH

If you've been following me you probably know that I am a big fan of DQMH and not as big a fan of AF. I find it overcomplicated for the projects that I do. I don't need its level of flexibility. It does bring up the question of scaling though. Most of the people I know who use DQMH regularly work on small to medium projects and most of the people I know who really like AF tend to work on much larger projects.

PPLs or monolith?

PPLs are another technical issue that seems to hinge on the issue of scale. For small to medium applications, a monolithic application isn't a big deal. It tends to be small enough to grok and build times are generally pretty quick. It's hard to justify the complexity that PPLs add. However, I was talking to a developer recently who had a 3-hour build time for their app. In that case, I would definitely start looking very hard at PPLs. Most people I talk to who use PPLs talk about at least 10s and usually 100s of PPLs for an app.

CI/CD investment

CI/CD investment also seems to have a scaling issue. I will start out by saying I think CI/CD is a fundamental skill and everyone will benefit from it. However, in LabVIEW, there is a large upfront cost to setting up CI/CD. On small projects, it is hard to justify that cost. I imagine that at some point a project gets large enough to easily justify the investment. At some point, a project probably gets so big that it becomes hard to justify NOT investing in CI/CD.

Style Guides

I'm preparing a presentation about the Blue Autoformatter for LabVIEW for GDevCon N.A. In it, I talk a lot about style guides. I think style guides also scale with an organization. When you are a 1 or 2-man shop, style guides aren't quite as important. You could easily make do with an informal agreement. As your team grows, the importance given to style guides and the amount of effort involved in creating, maintaining, and enforcing them grows as well.

Thoughts?

How does the issue of scaling affect how we work and the specific tools and practices we use? What have you noticed? What am I missing? Please add your thoughts to the comments.