While trying to implement an Agile development environment with a new team a few years ago one of the developers said to me; "I don't like Agile, it makes the whole team mediocre. Your bad developers will bring the team down and your good developers will have to slow down to wait for the rest."
It's a comment that has stayed with me ever since.
Like many things in the Agile world it is easy to point at "Agile" and state that IT is the issue when the underlying issue has nothing to do with Agile practices/ways.
When applying Agile practices to a team/group/project it is important to remember that it isn't a cure all for any problem you have. I've seen Agile work great, taking a great team and improving their execution, communication, and collaboration. I've also see the 'other' side of Agile when a group/team of individuals are brought together for a project and nothing can help the outcome.
It takes MORE than just AGILE to have a high performing team. Agile helps with recommending different frameworks or methodologies but how they are implemented, adjusted, and stream lined is really up to the people that make up the team. If the team is not ready to ask the hard questions... I'm not talking about the hard questions related to a project, but the hard questions for people:
Agile will NOT solve the above issues! But as a manager/project lead/team lead you need to have a way of righting the ship when team members do NOT have the drive necessary to deliver. This comes in a couple different ways at different times during a project/employee cycle.
1. Hire the RIGHT people!
A line that is easier said then done. Where do you start? You can always start with the skills necessary to fill a role. Or you could look at how the current team interacts and ask what type of traits make up a good team member. At times there are soft skills that are more important than the technical skills. If i can train you up on what is needed and you have the drive and determination it might suit me well to do that vs hiring someone with that type of experience and being stuck with an under performing employee that will do the bare minimum and 'punch the clock' day in and day out.
Hiring the RIGHT developer can be tricky, you can't take a Entry level Developer and push them into a Sr Dev role, this is where the experience is necessary. You need someone in the Sr Role who can help mentor and motivate the younger developers on the team. Ideally the Sr Dev is a 'teacher' and will help the team in software architecture, design, and best practices necessary to build great applications.
But when hiring a less experienced developer if they have the skill set and know how in a specific programming language you will have flexibility to train them in another language. With the pace of technology today new languages, techniques, and frameworks are available to make the development process easier and provide an equal playing field when switching languages.
I do recommend having some level of code challenge/scenario the interviewee should run through during the interview process so you can verify they are able to do what they 'say' on their resume.
Lastly TAKE THE TIME to have all team members and folks associated with the project meet the candidate during the interview process. Everyone will have their own perception of the candidate and this is valuable feedback when determining if they are the right fit for the team AND team members will be more invested in new hires if they are part of the process and have a 'vote' in the decision.
It's a LOT easier to NOT hire someone vs dealing with PIPs and/or performance issues after they are on board. Look for the red flags in the interview process and if anything feels 'off' examine why.
2. The Legacy Developer
Teams are made up of all types of people and personalities. What do you do if you take over a team/project with members who have been involved for years and under performing?
First off don't make any changes right away! Learn how the team operates (or doesn't) See how folks interact, do they work together or in silos? Do they share information and techniques? Do they help each other? Or does that only happen when the 'manager' dictates for folks to help each other?
Talk to the team members. Start up a 1v1 at least once a month to discuss the goals and aspirations of the team members. Great book on 1v1 conversations: Behind Closed Doors: Secrets of Great Management
Sometimes employees are NOT doing what they want in their work/career. Having these conversations are hard but needed. Knowing 'what' an employee would like to be working on can help YOU put them in the right place when the opportunity arrives.
If the developer is not producing have the talk, be honest and let them know what you expect.
If the developer does not start producing after a few of these talks then it is time for a Performance Plan. Don't wait on this step! It sucks having to put anyone on a PIP but what sucks more??? Months of wasted time and effort on a project!
3. Set expectations
Set clear expectations! Ideally in an Agile 'team' the team members will be defining what they expect from themselves and others on the team. Holding each other accountable when expectations are NOT met and offering helping when needed. Different teams handle this in different ways. On some of the Scrum teams i have been a part of this happens in different areas:
1. Sprint Planning - Setting the Sprint Goal. This is an expectation for the iteration. The Team is 'committing' to the goal so a precedent is set that this will be achieved.
2. Day to Day Process - Software Development has many steps and teams handle these steps in different variations. For example; many teams have some form of code review before code is merged into 'master'/the product.
Here is a great article (which leads to other articles) on ways to set expectations and have these discussions: letsgrowleaders.com/2018/08/21/how-to-motivate-your-team-stop-treating-them-like-family/
4. Provide a way to improve/learn
As part of the feedback and expectations you will need to provide a way for them to improve. Point them in the right direction. Could be:
5. Provide the Vision
There are times in business where the day to day gets a little ho-hum and the excitement might not be there. YOU need to provide the team a vision of where you will be 'in the future'. Could be a vision for next month, 6 months, or a year. People do better when they know where they are headed. This might be a difficult task if vision and priorities are shifting within the company. If so, focus on the SHORT AND OBTAINABLE opportunities which the team can do! Things that will allow the team to brush up on existing technologies, learn new technologies, update those build/deployment plans which haven't been touched in a year. Small victories but victories none the less!
It's a comment that has stayed with me ever since.
Like many things in the Agile world it is easy to point at "Agile" and state that IT is the issue when the underlying issue has nothing to do with Agile practices/ways.
When applying Agile practices to a team/group/project it is important to remember that it isn't a cure all for any problem you have. I've seen Agile work great, taking a great team and improving their execution, communication, and collaboration. I've also see the 'other' side of Agile when a group/team of individuals are brought together for a project and nothing can help the outcome.
It takes MORE than just AGILE to have a high performing team. Agile helps with recommending different frameworks or methodologies but how they are implemented, adjusted, and stream lined is really up to the people that make up the team. If the team is not ready to ask the hard questions... I'm not talking about the hard questions related to a project, but the hard questions for people:
- Do they have the drive to go above and beyond?
- Do they execute on what they say they will do?
- Are they constantly trying to learn and better themselves?
- Are they trying to achieve goals? Both personal and business?
Agile will NOT solve the above issues! But as a manager/project lead/team lead you need to have a way of righting the ship when team members do NOT have the drive necessary to deliver. This comes in a couple different ways at different times during a project/employee cycle.
1. Hire the RIGHT people!
A line that is easier said then done. Where do you start? You can always start with the skills necessary to fill a role. Or you could look at how the current team interacts and ask what type of traits make up a good team member. At times there are soft skills that are more important than the technical skills. If i can train you up on what is needed and you have the drive and determination it might suit me well to do that vs hiring someone with that type of experience and being stuck with an under performing employee that will do the bare minimum and 'punch the clock' day in and day out.
Hiring the RIGHT developer can be tricky, you can't take a Entry level Developer and push them into a Sr Dev role, this is where the experience is necessary. You need someone in the Sr Role who can help mentor and motivate the younger developers on the team. Ideally the Sr Dev is a 'teacher' and will help the team in software architecture, design, and best practices necessary to build great applications.
But when hiring a less experienced developer if they have the skill set and know how in a specific programming language you will have flexibility to train them in another language. With the pace of technology today new languages, techniques, and frameworks are available to make the development process easier and provide an equal playing field when switching languages.
I do recommend having some level of code challenge/scenario the interviewee should run through during the interview process so you can verify they are able to do what they 'say' on their resume.
Lastly TAKE THE TIME to have all team members and folks associated with the project meet the candidate during the interview process. Everyone will have their own perception of the candidate and this is valuable feedback when determining if they are the right fit for the team AND team members will be more invested in new hires if they are part of the process and have a 'vote' in the decision.
It's a LOT easier to NOT hire someone vs dealing with PIPs and/or performance issues after they are on board. Look for the red flags in the interview process and if anything feels 'off' examine why.
2. The Legacy Developer
Teams are made up of all types of people and personalities. What do you do if you take over a team/project with members who have been involved for years and under performing?
First off don't make any changes right away! Learn how the team operates (or doesn't) See how folks interact, do they work together or in silos? Do they share information and techniques? Do they help each other? Or does that only happen when the 'manager' dictates for folks to help each other?
Talk to the team members. Start up a 1v1 at least once a month to discuss the goals and aspirations of the team members. Great book on 1v1 conversations: Behind Closed Doors: Secrets of Great Management
Sometimes employees are NOT doing what they want in their work/career. Having these conversations are hard but needed. Knowing 'what' an employee would like to be working on can help YOU put them in the right place when the opportunity arrives.
If the developer is not producing have the talk, be honest and let them know what you expect.
If the developer does not start producing after a few of these talks then it is time for a Performance Plan. Don't wait on this step! It sucks having to put anyone on a PIP but what sucks more??? Months of wasted time and effort on a project!
3. Set expectations
Set clear expectations! Ideally in an Agile 'team' the team members will be defining what they expect from themselves and others on the team. Holding each other accountable when expectations are NOT met and offering helping when needed. Different teams handle this in different ways. On some of the Scrum teams i have been a part of this happens in different areas:
1. Sprint Planning - Setting the Sprint Goal. This is an expectation for the iteration. The Team is 'committing' to the goal so a precedent is set that this will be achieved.
2. Day to Day Process - Software Development has many steps and teams handle these steps in different variations. For example; many teams have some form of code review before code is merged into 'master'/the product.
- The team defines what needs to happen to 'get' to a Code Review
- Passing Build
- Definition of code change
- Testing steps
- What is expected by the submitter
- Best Practices are met: code style, formatting, functionality, etc
- Answering questions from team
- Presenting to the team (if doing group code review/learning session)
- What is expected by the reviewer
- Pulling branch down and checking locally
- Commenting and questioning
- Overall expectations that need to be met BEFORE the code merge
- Multiple approvers
Here is a great article (which leads to other articles) on ways to set expectations and have these discussions: letsgrowleaders.com/2018/08/21/how-to-motivate-your-team-stop-treating-them-like-family/
4. Provide a way to improve/learn
As part of the feedback and expectations you will need to provide a way for them to improve. Point them in the right direction. Could be:
- google :)
- An on-line learning site like Pluralsight or Udemy .
- Your companies internal Learning system
- A colleague/mentor with experience/knowledge in the area
- A book
5. Provide the Vision
There are times in business where the day to day gets a little ho-hum and the excitement might not be there. YOU need to provide the team a vision of where you will be 'in the future'. Could be a vision for next month, 6 months, or a year. People do better when they know where they are headed. This might be a difficult task if vision and priorities are shifting within the company. If so, focus on the SHORT AND OBTAINABLE opportunities which the team can do! Things that will allow the team to brush up on existing technologies, learn new technologies, update those build/deployment plans which haven't been touched in a year. Small victories but victories none the less!
RSS Feed
