Team Lead is one of the best roles in a company for building value. It doesn't matter what you're official title is in the company: Software Engineer, VP of Development, Chief Architect, etc. What matters is that you lead a team tasked with something meaningful. You are responsible for the success of that team, and this article gives tips on how to use the Scrum Agile Method to lead a team successfully.
The Team responsible for fixing Clusterfucks has it all under control
Scrum is an Agile Methodology
As an Agile Methodology, Scrum is about realizing these principles:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That's all there is. By focusing on the essentials, you can be successful.
Individuals and Interactions
Your team is a unique set of individuals, and your job as a team lead is to know them, respect them, and develop them.
Know their role. Are they a developer, an architect, an analyst, a product owner, or something else? When you establish. a clear role for everyone on the team, you can be efficient by letting people do their jobs and supporting them in that endeavor. Don't try to fit a developer into an analyst role if that developer lacks the skills. Only one product owner is on the team, and their role and responsibility should be clear.
Learn their strengths. Make sure you assign or don't assign tasks accordingly. Assign stories in the critical path to individuals you know will complete the task. Leave non-critical stories unassigned and let folks who need to prove themselves pick up those tasks.
Build mutual respect. Greet everyone in the daily standup by name, and make them feel welcome. Give everyone a chance to speak in any meetings. Give everyone a chance to shine in their work. Use inclusive language. Be kind.
Working Software
If your scrum is anything like mine, your job is to release software. The more often you release quality software, the better you will get. Here are my tips.
Release weekly. I believe in scheduling a release every Tuesday and feature freezing for the upcoming release on Thursday. It gives the team several days to QA a set of features in the release before releasing. Use branching on each feature in revision control to determine what gets in. If its code is reviewed and merged by 5 pm on Thursday, do everything you can to release it the following week. Be flexible - if you miss the Tuesday release, do it Wednesday; if you miss Wednesday, do it Thursday. Work hard to make your releases weekly. It will get easier with practice.
Don't be a slave to the Scrum Methodology. Don't let a two-week Scrum cycle drive your releases The Scrum cycle is for managing tickets on a board, understanding the team's capacity, and keeping the wheels rolling efficiently. The team, the software, the customer collaboration, and responding to change are all more important than the Scrum Methodology. You don't work for the Agile Alliance to build perfect Scrum training. You work for your company to produce working software.
Customer Collaboration
An Indian colleague once brought me a Ganesh statue as a gift and told me the story of why Ganesh has such big elephant ears: They are for listening. I keep the statue on my desk, both as a reminder of my friend, and to truly listen to the customer.
A Scrum team in a dynamic company will have many customers, some internal, and some external, there will be political challenges, personal challenges, and technical challenges. Listen to the customer, respect the customer, and don't be judgmental or try to push your own ideas. Understand their needs and reach out directly if necessary. The most important job of the Team Lead is to collaborate.
Understand the release expectation of the customer. Some customers will be detailed enough on the release to want to know the weekly details of every release, some will be interested in monthly increments, and some will only be interested in the quarterly software release contents. Use release plans and roadmaps to know how to collaborate with the customer according to their expectations.
For weekly customers, be clear on stories included with every weekly release. I use the Confluence Wiki to track every story included in a release, and I communicate clearly with my customers about what stories will be in the next week's release.
For monthly customers, group stories into epics by monthly goals and plan those into a detailed roadmap so you can complete the expected software in a month.
For quarterly customers, break down the releases internally into weekly and monthly increments so that you have incrementally at every stage. Use the lag time between the first weekly releases to the last to polish the documentation and any other expectations accordingly.
Responding to Change
If you're like me, you didn't get promoted to Team Lead by being sloppy or disengaged from the stories you implement. Be ready to let go of a feature, change course in the middle of the sprint, and keep that merge request outstanding in the revision control if circumstances change.
Let the Product Owner guide the roadmap and follow that guide when priorities or requests change.
For me, one of the most challenging parts of responding to change is getting rid of code that the team worked hard to develop. Let it go. Even if you delete it from the code base, it will still be somewhere in the history of the Git repository. The act of developing is what you gained from that code that is no longer wanted, and you won't lose that.
Don't be afraid to change your Scrum Process. Scrum has many defined ceremonies, and mindlessly scheduling each step, Grooming, Planning, Refining, Retrospective, etc, works toward having a Zombie Scrum team. Most people who hate Scrum don't hate Scrum, they hate Zombie Scrum. Zombie Scrum can happen if you block change and don't adapt your development process to your current situation.
What shouldn't you change? Don't change the daily standup. If it is not a short, quality, daily meeting to get the team in sync, you should reconsider why you have a team.
What do I change? I like to do retrospectives on the monthly cycle so that I have more meat in the retrospective, and I don't particularly care for the cute corporate tools for doing retrospectives. Focus on KPI metrics for the retrospective: How many story points did we complete in the last month? What was our defect ratio? How much time did we spend supporting the functionality we previously released? Use KPIs to guide a frank discussion on how to improve for the next month.
Keep the recurrence of meetings to less than a quarter. You should plan a quarter ahead - assume your team will be different in a quarter. Change is constant.
Concluding
Scrum can be an excellent framework for your development and can also be miserable. As a team leader, your job is to make your team effective. If Scrum isn't suitable for you, do something you know well. Learn the hell out of your tools and use them to best of your ability.