2

This is my first time PM experience. I have created a developer team and we want to work on an Angular-NodeJS project.

I have defined some tasks and divided the project into the different modules/components. For example each page of the website has a component. Also we have routing component, different services, etc.

As this is my first time project, I decided to create a basic framework of the project and put the routing component and other basic services on it. Then put it into a public repository that every developer of the project can clone and start his/her work. But also I will put it inside a private repository that other developers only can commit their tasks (send pull requests) after they done their tasks, but the only person who can see and accept and have the whole project will be me.

I'd like to follow scrum methodology but after having solved the above problem. Since I don't have previous experience, I don't know how right/wrong my idea is and I would like your advice: am I on the right track?

Improve this question
7
  • 8
    Perhaps some context would help: why do you think you want to? Is it an attempt to solve some problem you've seen? It seems risky for your organisation to put you, a first time PM (product or project, by the way?) with no experience, in charge of creating a team, defining the tasks, doing high level architecture, creating the code framework and accepting development work at a technical level; is there no support for you? It's unlikely there will be a positive outcome for anyone involved. If you want to follow scrum, what part of that is what you're describing?
    – jonrsharpe
    Commented Feb 15, 2020 at 9:48
  • 5
    Where did you hear that? Even if they do: are you working for one of those companies? Do you have the same problem they're trying to solve with that? Are you a PM, or scrum master?
    – jonrsharpe
    Commented Feb 15, 2020 at 10:00
  • 6
    From what you described, you're acting as a scrum master, a PO, a tech lead, a developer. I think you're starting in a wrong way; you should be learning about project management. Involve your more senior team members for whatever technical/methodology decisions you'll need to make.
    – Emerson Cardoso
    Commented Feb 15, 2020 at 10:10
  • 4
    @Hasani This sounds a lot like Cargo Cult thinking - to quote this website: "Cargo cult thinking is the belief that if we simply emulate the visible effects of achievement, the real achievement will follow automatically." - Don't fall into this trap! What you describe sounds like implementing a solution without having thought about the problem, or even checked whether a problem exists to be solved in the first place. Stop thinking about solutions and start thinking about problems instead.
    – Ben Cottrell
    Commented Feb 15, 2020 at 11:32
  • 5
    Hey, downvoters, if it’s OP’s idea that you don’t like, encourage this new fellow to think about it: upvote for his courage to ask; provide another answer to make him reconsider :-) This is the best way to pass the message to other new PMs around !
    – Christophe
    Commented Feb 15, 2020 at 13:25

4 Answers 4

Reset to default
23

Why you shouldn't do it from a team perspective

The most important rules of project management regarding teams are:

  1. The project can be a success only through intense teamwork.
  2. Empowered teams that trust each other are the most effective.
  3. One for all and all for one

What you are trying to do, is very different. It was called "Divide et impera" by Julius Caesar, some 2067 years ago. It's dividing the project in compartments, so that you stay in control. This immediately shows the team - nobody will be fooled here! - that you do not fully trust them. And this will impede the collective performance.

It will sooner or later collide with your intent to apply Scrum, which value teamwork to the point that it doesn't even have the term "project manager" in its vocabulary. It's an anti-agile approach:

We value individuals and interactions over processes and tools
- agile manifesto

The compartmentalized approach might deprive the project from a higher level of team engagement; It makes it more difficult for the team to reach a better mutual understanding. Of course it can work. But it might be more difficult and less fun for everybody, including you.

Why you shouldn't do it from a source code management perspective:

The role of the project management, it not to commit the code of others in a secret repository. You will become the bottleneck of your team. How will you by the way manage the merge conflicts?

Use one shared repository for you and the team (see here how Goole used this approach). Maybe establish some rules of peer review for committing code if you think it can help. If you see two products (e.g. the application and a new framework) or really independent components, you may split repositories by component.

Projects are difficult enough. Do not make it more difficult with exotic secrecy driven repository management practices.

Improve this answer
4
  • I am absoloutely confused! Because I am a new PM or scrum-master and what I said in my question was what I read before about big companies like Microsoft, Aplle, etc. I read each developer only knows about his/her task and doesn't have access to rest of the projects code and it's because of the security considerations, etc. But I also heared that many big companies like them also use Scrum and Agile manner. I am really really confused!
    – user3486308
    Commented Feb 15, 2020 at 9:53
  • 5
    @Hasani I edited to complete the picture. It's normal to have this kind of ideas. But as scrum-master you need to see your role as facilitator of the team and not as controller or bottleneck. Furthermore, at the first complex merge conflict, you'll see that you are anyway not really in control anymore. If you have high security constraints, it's different: you may indeed have to compartmentize. But in this case, you'd do it per component or per workpackage. And the integration between the components of the WP are done by other teams. It's lot more resources and less effective.
    – Christophe
    Commented Feb 15, 2020 at 10:05
  • 2
    @Hasani You may be interested in this article: cacm.acm.org/magazines/2016/7/… I do not know if Google still have this single repository approach, but if it worked for Google for over 16 years and helped it achieve to be what it is, it may be suitable for you as well ;-)
    – Christophe
    Commented Feb 15, 2020 at 10:09
  • I really agree with this. It seems to me that you need to change your views on how things are shared between devs, or, use another approach entirely, e.g. not agile and definitely not scrum. Scrum is very particular about how you need to run your show if it's to be scrum, and I would encourage you to reread the agile manifesto as well as the scrum guide. Happy developing.
    – rasmus91
    Commented Feb 15, 2020 at 14:41
10

You are not Apple or Microsoft.

The reason why a software developer at Apple doesn't know about all of Apple's code is that there is a bloody awful huge amount of code and nobody can know about all of it. And there isn't one guy at Apple in charge of their repository. They have more than one :-)

What you are thinking about is just totally misguided. If you actually tried to implement it, then any decent developer working under you would do one of two things: Find a job elsewhere, or try to convince the company that you should find a job elsewhere. I'd do the second.

At Apple there are no secrets within a developent team - the exact opposite of what you suggest. There are multiple teams. Some teams do things that are secret to the outside world. But not within the team itself.

Improve this answer
6

Since I don't have previous experience, I don't know how right/wrong my idea is and I would like your advice: am I on the right track?

If you don't have experience, and you are in the role of scrum master or project manager for a scrum team, the best thing you can do is step back and let the team make these decisions for itself. Your job as scrum master is not to be a gatekeeper for the code. Your job is to remove obstacles, not add them.

So, no, you are not on the right track. Unless you are the manager of a huge project (eg: Windows, OSX, Salesforce) or high-security mission-critical applications, you should not be trying to hide code that someone might need access to. You can set up rules that require code reviews for commits if you want, but you shouldn't be hiding code from view to members of the team.

Based on your description, your project simply isn't big enough (by several orders of magnitude) to warrant such protections.

Improve this answer
1

Other answers do a great job of describing what you should do instead of isolating everything. I agree with them. What you are really asking for is extreme, however I will attempt an answer focused on the technical aspects of doing this when you find it warranted.

The assumption here is that you have found something that does need to be hidden and isolated from other components. To be clear, do not treat everything like this, unless you work in the defense industry. And if you are working on the defense industry, please for the love of God do not consult strangers on the internet about this.

Anyway, separate the sensitive thing into its own repository. Make sure you have the tools in place to enforce the proper access so only authorized personnel can see the code. Choose a technology stack that gets compiled into machine code. Distribute the binaries to other teams. Be aware you can still reverse engineer binaries, so this alone will not give you bullet proof isolation.

You also need to hire people you trust. This may involve background checks, and other legal documents like non disclosure agreements. The fact is if you don't trust the people building the system you are dead in the water. If you can't trust contractors, don't hire contractors and only hire full time employees.

If the sensitive thing does not need to run in the same process as other components, consider a web service or micro service. Not only can you isolate code, but you can physically isolate the consumers of the sensitive service such that they are different servers, and exist in different network segments. Firewall rules will govern who can communicate with whom.

Really though, any strategy is going to involve separating the code into more than one repository and only granting access to those who truly need it. You need to hire people who can be trusted and consult your legal department to ensure people have signed the proper agreements so the company has legal options if someone goes rogue.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.