How to manage the team efficiently in my new position as an inexperienced lead?

Congratulations on the new exciting role. This is a great opportunity for you to grow as a leader. As a developer with 7 years, you have the technical skills and it sounds like you have some of your major tasks already defined.

• Introduce Agile working practices.
• Move the existing windows application to Web.
• Develop your leadership skills
• Overall goal: Increase of revenue

Initially: Are your priorities aligned with the business?

The above summary list is by no means a small endeavour. And like all plans, it will change. I would meet with my line manager use the above points as a starting point and provide some detail of what it would involve. Practical things such as do you have the JIRA licenses in this year's budget? Are you able to get funding for training for the team?

You need support from senior management and start building your working relationship with other leaders in your organisation. You would need to work with the Operations and Service desk managers to implement your changes.

To expand on your goals:

Introduce Agile working practices:

How familiar are your team with Agile concepts? Do they understand the product backlog, daily stand-up meetings etc? Would you be able to coach them? With the existing team size, you can look at Kanban perhaps. Scrum would work if you do expand the team and are able to create 2 teams, one focussing on the current BAU tasks, and another for the web project.

Moving the existing windows application to Web:

How much existing BAU work do you have, if you need to retrain the existing team you would need to define your tech stack, and then retrain them. It would help if you can get a senior web developer in that would be tasked to upskill the rest of the team in the technology, unit testing, and making use of pair programming.

Develop your leadership skills:

Start with the basics, I recommend the book 'How to be an even better manager' by Michael Armstrong. This will help you how to cope with the challenges such as developing people, management skills and personal skills you would need to develop in your new role.

Look at the concept of servant leadership.

Listen to podcasts such as John Maxwell's Leadership podcast.

Think of volunteering, it is valuable in experiencing leading people outside the workplace. Or to see how other leaders achieve it, this can be with a sports team or even a church group.

Good luck!

You have the right idea about observing their work processes for a few weeks before beginning to make changes. You want to build a good rapport with the team so they work with you and are willing to follow where you lead. You won't achieve this by ripping everything up and starting fresh on day 1.

In terms of actually making the changes: you want to show that you're making them for a sensible reason and not solely to assert your authority. Identify bottlenecks, quirks or out-dated tooling in their process and question them. Why do you do it this way? Would it be easier if you tried [this] instead? Then gradually make the changes. One thing at a time.

If you are moving to scrum, the Sprint Retrospective is the perfect forum to get these changes through since the purpose of the session is to help the team adapt and improve. Present a problem/challenge, ask the team's opinion around how to improve on it and steer them towards the solution you had in mind. (Or perhaps the team will come up with a better idea). The team will feel they have a real voice in how things are done and, in not being dictated to, they will feel a real sense of ownership of (and responsibility to) your evolving process.

In terms of leading a team, when I started my first team lead role I concentrated on the following simple points:

• What's the next step? I asked myself this constantly. What's the next step needed to get this work done? Do you need to do a proof of concept? Does somebody need to research something? Do you need something from the customer? Identify what that thing is and the person responsible for it. Agree a time for delivery and touch base regularly with them to see if the time is slipping. Never assign a task to "the team" because everybody will wait for somebody else to do it - and it will never get done.
• Figure out the personalities. Different people respond to different stimuli. Some will need an arm around the shoulder, some a kick in the backside. Some excel with praise and "attaboys" and others want to know they have some input into decisions etc.. Figure this out and you'll know how best to deal with individual team members. This is half of the key to the conflict resolution challenges facing you - the other being...
• Be decisive. Don't appear too dithering. Your team need to have confidence in you - make decisions, make them confidently and make them reasonably quickly. That's not to say rush into it - that would be foolish. If you need to, get the right people into a room. Let them talk. Listen. Ask intelligent questions. Then make a decision - and stand over it.
• Protect the team. You are the umbrella that shields the team from all the external goings on. The project managers, product owners, customers, sales and support. Distil their input down to what the team need to know and communicate this, keep the team informed and you'll be letting the team get on with their job.
• Don't be afraid to change things back to the way they were. You won't always get the decisions right. Some changes won't work. The key to scrum is observe and adapt - admit when something is not working and roll it back. This can be used to your advantage when implementing changes the team might be resistant towards. Introducing alterations on the basis of "let's try this for 2 sprints and see if it helps us... we can always change back later" can help overcome that reluctance since the team know the process will be revised should the changes prove ineffective. (However don't use this approach to introduce something you have no intention of changing - do this once and you'll struggle to get buy in to the "we can always change back later" idea).

Your job as a lead is not to do all the things.

I need to get rid of those customer/project management tools and establish JIRA service desk

I need to introduce Agile practices

After I make the existing software stable, I need to convert the windows application as a web application

Trying do accomplish everything alone will burn you out. Your job is to break those goals into small pieces which your developers can accomplish, help them with any unexpected issues, and plan for future work based on the current progress.

Also be mindful about how you introduce Agile and JIRA. If the team feels their process works well there will be some resistance. Process changes work best when they have buy in from the people who have to live it out. Otherwise you might be hit with the line "if it ain't broke don't fix it".

I hope this helps, good luck Lushan!