Let me first ease into this topic by talking about the role of tech leads in the software engineering field. Be patient with me as this is all directly related to the main topic. I believe that the role of good tech leads is very often underestimated or taken for granted until they are removed from the equation and then you start realizing how much work goes into it. While the role of tech-lead is kind of stuck in between keeping project/program managers happy and working on low-level technical details, there are what I call unofficial/unwritten benefits of being a tech lead. You are in that special position as a leader where you are closest to all the activities on the floor and you can shape and improve things unofficially even though there are different rules and perceptions at that layer above. If you have that super-connection with your fellow engineers/developers doing the amazing work on the floor, then you are in that unique position to influence how the culture shapes up in the company and how people feel when they show up to work every day. When you reach that level of connection with your fellow developers, you know that you would jump in front of a bus to save them and you know that they would jump in front a bus to save you when it comes to your projects. In most cases, you a tech lead know the members of all teams better than their own resource managers; you are their unofficial manager and you are in the position to influence their careers in positive ways. They follow you because they respect you and that’s a huge responsibility that tech leads have on their shoulders.
This leads me into the topic of SAFe (Scaled Agile Framework) and how the role of a tech-lead gets translated to the TEAM and a new role of a solutions architect gets born which is more tied with the overall architecture, product management and program management.
What do I mean by “tech-lead role gets translated to the TEAM”?
What I mean is that the TEAM does not have an official tech lead and that responsibilities of a tech lead need to be divided into small pieces and shared by the team and then somehow all of that has to be put together and facilitated to hopefully get the same results of having an official tech lead. Yes, there are less and more senior people on the team, but one thing that should NOT be done is just appoint that one more senior person and give all the responsibilities of a tech-lead to that person. What happens when you do that? You are basically taking abilities away from that senior person to do any coding/development throughout the major part of their days. For example, if you your teams are small then you might have just lost 25% of productivity.
What you as the organization really need to is identify the unwritten checklist of what tech leads do in order to make it a successful formula. Don’t try creating this checklist if you are not on the floor. You might have had experience in other companies with this, but their floor is different then the floor in your current company. Please reach out to your leads and team members and come up with a good list and keep fine-tuning it. I will share my list with you below, but let’s first discuss how you put all these pieces together and achieve the same result as if you had a full-time tech lead on the floor. This is where a strong scrum master role is absolutely vital. Let’s assume there are ten of these items on the list which a tech lead would typically handle. Let’s assume these are split among 5 people on the team. If each one of these five people handle two items, does 5 x 2 equal “10”. It will equal “10” if your scrum master does an amazing job and if every team member puts passion into what they are doing and constantly tries to improve it. The chemistry on the team has to be at the top, and the role of a scrum master becomes that much more important. Building that level of chemistry is not easy and to be honest, I am not a big fan of specific things in the agile methodology that make things mechanical and too military-like. How many times did you hear people say “Nobody does agile properly”. First, you can’t do “agile”. The word “agile” is not a noun? I understand why the scrum organizations made the word “agile” a noun; it is because you can sell nouns and you can’t sell adjectives. I am going a bit of tangent here. What I mean is that chemistry within the team cannot be naturally achieved if you have so many rules that you need to follow. In my opinion the agile methodology is about the Agile Manifesto and the programs and certifications that came out of Agile Manifesto are just one interpretation of that manifesto. So don’t allow anybody to tell you “we don’t really do agile here”. Challenge them on that statement. I encourage creative debates on it.
This leads me to the main topic about the self-organizing teams. All of the above recommendations is what can get you closer to having self-organizing teams. I specifically said “closer to self-organizing” because in reality the teams are never 100% self-organizing; you always need a little bit of leadership involvement to keep things in check. Even though that magic 100% is never reached, the main thing is that most of the tech lead responsibilities are evenly distributed among teammates and you are avoiding a very common problem of tech leads being bottlenecks and being overworked.
Here is an example of the list that could be taken from tech leads and distributed among teammates to get closer to self-organizing team. This is the list that I came up with as I was trying to make teams more self-organizing in order to free myself up to focus on strategic architectural items:
- * Somebody who can decide at the beginning of the sprint when PAIR-PROGRAMMING is needed and on what story. This worked well in a recent projects where we paired up developers on bigger user stories. This was done selectively when needed. Both developers keep each other challenged and you are automatically doing peer-review and what I call drive-by demos.
- * Coding methodologies review: Appoint a person who needs to have in every sprint a quick session to review with architecture what the approach is and find out what further architecture involvement is needed.
- * Risk assessment on existing functionality in production due to common code changes: Somebody on the team should be made the owner on this item.
- * Ongoing special instructions as you are coding during your sprint: Somebody needs constantly check with fellow developers if anything special had to be done besides regular code checkin/commits. Having a person that keeps people honest throughout the sprint is important during busy times and this is one of those things that could save you from late finding in Stage and Production launches. Obviously if you script/automate your special instructions, then it is that much easier.
- * Quick drive-by meetings to explain to your peer how you are about to code something: You will be surprised how these “drive-by high-level technical designs” increase the quality of the software by a huge factor. Every developer should be doing and scrum master could be constantly encouraging this. This is where architecture members can be brought in if these drive-by sessions require need to be design oriented.
- * Drive-by technical demos among peers after each user story: Instead of just marking that user story completed and ready for testing, I strongly recommend that you bring over a teammate and do a quick technical demo and you may get some recommendations that will help prevent issues down the line. Every developer should be doing this throughout the sprint.
- * Peer code-review: When a developer finishes a user story, that piece of code should be given to a peer for a code-review before the code is checked in or committed to your source control. Every developer should be participating in peer code-review instead of relying on tech leads or senior developers.
- * Main contact person to collaborate with system engineers and DevOps teams: Sometimes you have changes where you need new servers set up or a new type of build. There should be a go-to person on the team to be the spokesperson when communicating with system engineers and DevOps.
- * Day-to-day support of the environments (Dev & QA): If QA teammates or somebody finds and issue in Dev/QA environments, somebody has to do the initial analysis and determine if it could be related to your teammate’s user story or it could be related to your user story. Having that one go-to person on the team to do the initial analysis saves the rest of the teammates from being interrupted. Obviously you can rotate this responsibility from sprint to sprint as any other responsibility in this list.
- * Source control (TFS, Git, …etc): Somebody on the team should be responsible for source control related things and your branching and merging strategy. For example somebody should be doing forward integration from the MAIN branch (trunk) into your development branch and deploying those changes to your Dev/QA environments and doing some initial smoke-testing if things are not fully automated.
- * Builds to Dev and QA runways throughout the sprint: Somebody on the team should be focused on doing daily builds or on-demand builds depending how automated or half-automated your builds are. If the build scripts are owned by a DevOps team outside your team, this teammate should be the focal point communicating with the DevOps team about any changes needed in build scripts as part of your sprint work.
- * Final code-review: Somebody more senior on your team should review all the code and involve architecture on need-to-need basis on implementation and definitely involve architecture for design decisions before you even get to the final code-review.
- * Launch preparation: There should somebody dedicated on your team to work with all the external teams (Change Control, DevOps, …etc) on preparation of your release to production. Obviously this person needs to understand the technical details of the release and have ability to translate that into instructions that Change Control team requires from the process point of view.
The items above are just examples of what a tech lead would handle and now the work would be divided among all teammates. Obviously teammates can rotate the responsibilities based on how the team decides.
Good luck, have fun, put passion into what you are doing and try to improve things from iteration to iteration. At a minimum, identify just one thing that you want to change to make things more flexible and do it. Repeat this from iteration to iteration. Isn’t that what agility is all about?
Almir M
#leadership #techlead #team #selforganizing #softwaredevelopment #softwareengineering #scrum #agile #agility #iteration
No comments:
Post a Comment