11
Your asking many questions here:
component teams (platform, front end ... ):
You are correct, that goes against Scrum. If you want to lose time with handover then do this :-)
shared team members
Also goes against Scrum. Multitasking slows people down, makes them lose focus. Good for bad quality :-)
How to deal with a really large and really small team? The ...
9
TL;DR
Gamification is inherently competitive, which is contrary to the "succeed or fail as a team" concept that underlies many agile methodologies. That doesn't mean it's a bad idea; it just means it's not well-suited for use with frameworks like Scrum or Extreme Programming. Your mileage may vary with other methodologies.
Competitive Nature of ...
9
It's great to hear that Code Reviews went smoothly and you are seeing results soon, you have seen it's effective and that means the junior programmer is keen to learn (All good stuff)
Few things I would like to suggest which can be done at your end
Good code samples from existing code base - You probably have some star quality code in your existing code ...
9
Group Discussions Don't Replace One-on-One Communications
While there's a place for more leadership involvement, I certainly wouldn't replace one-on-ones with larger meetings. Especially in IT, this can be counter-productive for a number of reasons such as:
IT often attracts introverts, who may not do well in larger meetings.
Company leadership is often (...
8
Robert Austin wrote a short, devastating little book, Measuring and Managing Performance in Organizations, that neatly demonstrates why and how most personal measurement systems are doomed be either at best distortionary or at worse actively dysfunctional.
The problem is that you're introducing personal measurement. Under selected circumstances, that can ...
7
Notwithstanding my comment about the proper exchange, you are dealing with a normal problem of 1) prediction of future performance, and 2) how to attract good employees.
The first problem is a huge problem. Predictive indicators that we tend to use are not that predictive. One of them is experience. Experience is one of the most widely used criterion, ...
6
What are the key Agile points to be considered in a small startup company, with a team of 5-6 people
Getting started with Agile Project Management
What are the key points I have to consider in terms of Project Management and Agility.
Looks like you want to follow agile project management, but others
may not know what that means. Try to get at least a couple of people
trained. Scrum is the most popular agile process.
Assign the key roles of Scrum Master ...
6
I have no academic backing on what I am going to write as my answer here but am drawing on my experience plus my own predicted reaction if I were a subordinate meeting with my boss and his/her boss.
I can only imagine that the discussion would be a complete waste of time because the politics of such a dynamic would require all three of us to be on our most ...
5
Help the team to move from storming to norming, see stages of group development. You can achieve this by:
Present your observations to the team. Take care that you talk about observations and not interpretation.
Highlight the advantages you could achieve if you change your behaviour, e.g. get better results by taking more ideas into account, speed up ...
5
T think this actually marks you a s good leader even more than a good manager.
This has always been one of my favorite quotes:
“A leader is best when people barely know he exists, not so good when people obey and acclaim him, worse when they despise him. But of a good leader who talks little when his work is done, his aim fulfilled, they will say: We did ...
5
How to keep the team motivated
Ask the team.
Chances are, the team knows both:
What they want to do
What improvements to their process would help most
...far better than you (or, most certainly, strangers on the internet) ever could.
So ask them, discuss, and then ensure they're empowered to actually carry it out.
4
TL;DR
I'm not aware of much formal research in this area, but empirical results show that both models can be effective under the right circumstances. Flow and pair programming are somewhat orthogonal in the sense that they can't be performed simultaneously. They also represent practices that optimize for different things.
Different Optimizations
...
4
A good project manager is a good facilitator. Someone who can guide healthy conversations and help the team get to, remember and follow through on their commitments and decisions.
Taking a people focus I'd advise two key areas:
1- Who does what, by when: At the very basic, that's all project management is, tracking who is doing what and when it should be ...
4
TL;DR: Maybe a bit harsh, but get rid of him/her.
Most companies have a defined culture or core values. Suggested is to use your core values in the hiring process. I think the same goes for the firing process, fire to protect your core values.
Introducing Agile is a team culture shift according to the Agile Fluency Model. People blocking this culture shift ...
4
He is usually visiting friends in the company or outside smoking.
I don't think it's your personal responsibility to talk to that guy about it, as long as he attends the mandatory meetings and follows the Scrum process. It is your responsibility to support the development team to talk about improvements in the retrospective though.
In the retrospective, I ...
3
No matter what sort of benefits source-control-emails may or may not bring to your team, they are going to be strongly counterpointed by the negative feelings your team will undoubtedly have from you introducing something which they specifically requested you not to introduce.
If you absolutely cannot live without these emails, then try explaining to your ...
3
TL;DR
Since I've only heard your side of things, I'm unwilling to assume the problem is the individual you're talking about. While I agree that there is a problem, the problem is one that involves people, processes, and change management. It will require you to acknowledge this before the problem can be resolved to anyone's satisfaction.
Most likely, you ...
3
The team must address the issue. If discussions do not affect the individual, that is okay; not all are willing or able to work as a collaborative team member. Then that person needs to be removed from the team. This is the function of management in an agile organization. Perhaps there is a classic, head down project where that person can be valuable; ...
3
Any activity could be ok. I don't think it is necessary something extraordinary, simple events can be a good solution.
Probably the best would be, even before they start to work with the team, to invite the entire team (basic + 2 new members) for some drink and/or food. A relaxed and relaxing environment might help chats, some initial knowledge, some ...
3
There are three areas I'd consider when introducing new team members.
1) The Work: A week is not much time to get used to working together. Pairing or group/mob programming could be a great way to bring them up to speed on the way the team works and code practices. It may slow the team down a bit for the week, but not nearly as much as trying to onboard ...
3
TLDR: Rather than treating him as a problem, one perspective is to view his actions as an opportunity to improve your process.
Code Reviews
he refactored some part of the application without consulting with the team
Why is a developer capable of a large-scale refactoring without the knowledge and consent of the Team? My suggestion is to implement ...
3
Manage him out, sooner rather than later. The short term pain of his loss will lead the rest of the team to learn what the indispensable man knew and inspire fewer indispensable men in the future. See https://blogs.msdn.microsoft.com/eric_brechner/2018/02/01/good-engineers/
3
You have an employee that appears not to be doing work. You describe only the optics of his performance but make no mention of measurable output. Appearance of busy can be deceiving. And making it an expectation to look busy will get you just that but does not necessarily mean more production or better production. And doing so could also jeopardize an ...
3
From the university courses and companies I was at remotely / with some distance, it was common to use a Facebook Group from where we all would connect and discuss relevant content (updates from the university/company, auctions, contests (chess, cooking, ....), discussions about the general approach to solving problems, etc.). The pattern I could see is that ...
3
I'm a fan of using a web conference with video to highlight the team member's individual work environments. Kind of like an MTV Cribs-type virtual tour get together that allows each team member to showcase where they work and to interact with their teammates through stories and questions about their work environment. We do this every so often (really ...
3
Don't use money to reward quality.
Studies show that money is an excellent motivator for routine tasks that involve no thinking, and a terrible motivator for tasks that require creativity.
Experts are motivated by autonomy, mastery, and purpose [Spam disclaimer: No relation to the book nor author].
So:
Create an environment that provides autonomy, ...
2
I don't think the approach to leading PMs should be really any different from leading anyone else.
Establish Your Expectations. Set a standard that is clear and achievable.
Lead From the Front. Make sure you not only live up to that standard but excel it.
Demonstrate Trust. Trust that they can do their jobs. Delegate authority. Give them the chance to prove ...
2
Do Pair Programming. I often find that Code Reviews tend to demoralize people, because you criticize (potentially a lot of) their completed work. Even if you are good at giving feedback and the other one is good at taking it, this will be an issue.
In Pair Programming, on the other hand, you start a task together from scratch. Let him take the lead, listen ...
2
Very late answer. It won't help you, but maybe someone else.
Product A team (Consisting of 12 developers) And Product B team
(Consisting of 3 developers)
Team A is too large for effective communication. Team B could work in theory but it's very small.
because one developer is always working on the core features and on an
operating system level
...
2
In my opinion this makes you a great manager. The ability to fix the problems within the team without burdening the team with it, is something i would like to be able to do. This not only improves the work processes, it gives better morale to the team and in the end makes the managers life easier.
However, i would say that in some cases this might turn ...
Only top voted, non community-wiki answers of a minimum length are eligible