Lancer: Dhaval Panchal starts the discussion about teams and management.

 

Dhaval: In 2010 there was a need to have a mobile development team and a web development team. Now when responsiveness came into play, the need to have two kinds of focus areas went away, because technology allowed them to take care of rendering into different kinds of devices, but that technology would have never come until the problem in the first place. So it’s almost like, you know, taking two steps forward, one step backward, and then some technology allows you to move a little bit ahead. Right? So when you look at the question of “what does scaling mean?” To me it means, “can we build the tools that actually help us to get better?” As opposed to “how can I find a lot of work for all the people?”

<oh>

There will always be new technology that is going to make what you were completely obsolete. And if you have the capability to build your own tools, to build your own improvement by building your own tools, then you’re not dependent on an external agent to come sell you that tool.

 

Dhaval: There’s a lot of motivation for someone to build the technology tool to actually solves the problem.

<oh oh>

Like for example, in one of the companies that I was working with did gaming design. The tool they were using to do design was an internal tool and that was the least funded effort in the entire organization when instead it should have been the largest funded effort because it saves the designers a tremendous amount of time. Instead the designers were making their own internal hacks and shortcuts to overcome the tool shortcoming and they were hiring more and more designers to cope with the fact that they have to do a lot of design. And that problem will never be solved by adding more people to the design department when the problem is you have really bad tools to do the work.

<oh oh>

 

Lancer: Does scaling your organization well avoid that?

Bas: I guess you can generalize it as simply when you grow larger, gradually people take away more and more responsibility from the team. So you get less responsible teams. And the tools aspect is just just one of the symptoms.

 

Lancer: So if a teams are becoming less responsible than something else is stepping in to provide things. Um, so maybe we’re talking about those like, “hey, we’re going to have a test platform as well on the test platform team.” Maybe that’s how that pattern starts croming up.

 

Dhaval: Bobby, the hypothetical manager we talked about in the LeSS course, is probably the simplest solution that someone in upper management could implement. When upper management sees a problem, they hire a manager to take care of the problem, right? And let that manager figure it out rather than pushing the responsibility back onto the team, which is different than giving it to an individual because, well Bobby is going to handle it now. Right? He assumes all the responsibility of the entire problem when in reality if they went back to the whole team, then five minds will likely find a better answer than just one person.

 

Lancer: At some organizations that I go into, the people are living with problems and they don’t want to tell anyone about it because they’re afraid that somebody will take it over. Take it away from them and perhaps resolve it in a way that makes it even less pleasant. So I think I see what you’re saying.

 

Dhaval: From coaching experience I’ve learned that “my problem” is more important to me than “your solution” because it is mine. I have ownership over my problem, but anytime the solution comes from outside, it is not mine. Therefore my first reaction is to push back and not accept it.

<oh oh>

 

<new sound track>

Lancer: The information in the training we’re receiving is about not doing too much for the team. Is that fair to say? How would you summarize? How do we give teams more ownership? Because we’re doing Scrum, teams are supposed to have ownership, right? Agile Manifesto, the Principles and Values…. Teams are supposed to own the process, but somehow when you get into an enterprise, that part doesn’t happen.

Lancer: 我们正在接受的训练中的信息是，我们不会为团队做太多的事情。这么说公平吗？你怎么总结？我们如何让团队拥有更多的所有权？因为我们在做Scrum，团队应该拥有所有权，对吗？敏捷宣言，原则和价值观。团队应该拥有这个过程，但是当你进入一个企业时，这个部分不会发生。

 

Dhaval: Here’s what I liked is that at the end today’s class, we were talking about the fact that competitor analysis is added as another product backlog item for the team to actually go and investigate on their own and take more ownership of the product, which is contrary in some respects. And you should correct me on this Bas.

 

Lancer: Yes. In LeSS Huge with one product owner and lots of teams, the PO role isn’t so much of the clarification, meaning the PO’s role isn’t to discuss a developer’s question about a requirement, and then go to another building in the business and talk to whoever asked for the requirement, and then come all the way back to the development building and let them know. Bos’s advice is . . .

 

Dhaval: To connect the end user and the customer, directly with the Dev team, which essentially is the principle in the agile manifesto of business people and developers must work together daily.

Bas: Well then we started interpreting it as business people is the product owner and that’s where things went very wrong.

 

Lancer: Wouldn’t the business person be the best product owner?

<new track fades in the below>

Bas: Well, because of the difficulty of adopting Scrum, the business person ends up not being being the product owner, and somebody else gets the job because it would be too hard to involve someone from the real business side.

 

Lancer: And if they did get involved, they might not still be a businessperson, meaning they’re not involved with whatever their role was before.

 

Dhaval: Or even if you get a business person to represent from the business department to be the Product Owner, how well will that person represent the needs of the fifty other people that they are trying to channel. When the feature is to correct a problem experienced by one or two classes of end users, it’s better for the dev team to connect with those end users directly rather than have this business person interpret what they’re saying to the developers. Now this PO could be present in the room to clarify any language because they have a better working relationship with the team. But rarely should the PO be the conduit.

 

<oh oh>

Lancer: There are two forms of LeSS, basic LeSS and Less Huge. For these teams, what’s the ideal P.O.?

<acoustic noodling>

Bas: For me the ideal P.O. is somebody who brings clarity and makes decisions. One of my favorite POs would sit in the back of the room and would listen to everybody discussing a certain topic. And after 10 minutes of argument he would stand and he would say “that’s what we’re going to do.” And he would sit down and that’s basically what he did. He listened to all the input that he required. Then he made clear that he is the product owner. He made the decision. He made the direction clear to absolutely everyone without a doubt, and then he removed himself from that discussion and let it go on. So therefore everybody in the organization always knew the vision and goal for the product, and whenever there was an a relatively high level decision that needed to be made related to the product, he made it right there so that you’d never got blocked by uncertainty of where you’re going. That was one of my favorite product owners.