Back to the Beginning
I just held my tongue and observed. Over the next two weeks, I joined every Agile ceremony I could eavesdrop on, but I just sat back and watched the team dynamics.
The reality was that things weren't looking so great. Team morale was down. Multiple defects were being opened left and right. We were already behind schedule, and it didn't look like we were in a great shape to release our code.
I had just been assigned to lead a team that had been struggling in the past to deliver results. I hadn't yet joined officially as the new Tech Lead, so I wasn't yet allowed to implement any changes. But I could already see some reason why the team was struggling.
Where Is Your Focus
Anyone in their right mind who is in a high stress/high pressure environment would be tempted to go in hot and fix everything that was wrong with the code and get the product out the door. Some may take the gofer approach. “Go for this!” “Go for that!” Others may resort to the “Hold my beer” approach and say, “I'll just do it myself. It'll be a lot quicker.”
My approach was neither because my focus was a bit different. I didn't view the software as the domain that I was responsible for. The people on the team were my responsibility. A healthy team will output healthy code. And right now, the team is broken. And a broken team is what resulted in a broken software.
Yes, we do have to get software out the door. And, yes, we do have to fix all the bugs. But right now, I'm not interested in a sophisticated solution that will fix all our coding problems. I'm interested in getting the team dynamics back in a healthy state.
Be an Advocate
At this point, the immediate need is to have the stress of delivering output off of their shoulders. This included the Product Owner. She's under tremendous stress and pressure from above her to deliver an outcome. But it was the, “Get it done at any cost,” approach that go us to where we were.
I approached the Product Manager. I said, “I've been sitting in all the team's ceremonies as a fly on the wall and here are the issues that I'm observing. My analysis is that I don't think this team is currently mature enough to take on new initiatives. We need to take a breather to be able to reset expectations. I can commit to the successful release of what we're working on. But beyond that, can you give us some time before we take on new work? There's a lot of work that needs to be done with what we currently have.”
I wasn't exactly a new tech lead. I was transferred from a different team and had a reputation to get things done. Naturally, they had high expectations. I can only imagine the disappointment when I'm saying, “I can't commit to your expected pace.” But that's what the team needed. They required someone to pump the brakes and advocate for their behalf.
Bug Hunting
Where is the bug? A junior software engineer will fix the consequences of the bug without analyzing the root cause. Without fixing the root cause, the same type of issue will come up again and again. A more mature software engineer will identify why the issue exists and look to fix it on a deeper level. Ask a good tech lead what the root cause is, and he'll identify shortcomings in individual team members' technical knowledge as the root cause, and he'll fix the issue by educating the team to come up higher.
Give a man a fish and you feed him for a day. Teach him how to fish and you feed him for a lifetime
~ Lao Tzu
The reason this team was in a bad shape was because nobody took the time to teach them how to be an effective software engineer. I've advocated for the team and managed to buy some time. How, then, can we best utilize that time to build up the team to where we needed to be?
All Things Are Created Twice
Everything is created twice, first in the mind and then in reality. This is true in software development. You plan how you're going to build a feature first, break up complex parts into smaller increments, and then you start coding. Except, I'm not always smart enough to know exactly how I want things to work without putting things down on paper first. I know what the end result needs to be, but I haven't yet worked out how to get there. Sometimes, I'll just start writing code to try something and see if that will work. Then I'll revise the work if it's not quite what I want it to be. Over time, I get better at being able to do that in my head. I imagine that this is true for a great many of software engineers. But how can you teach that process to your team?
The First Creation
The next few weeks were intensely difficult for me. Because my focus on teaching the team was greater than my desire for good code, the shortest path to both was to actually do both. That meant that I needed to code everything ahead of time just so that I, myself, would know how to get there. I spent the next few weeks doing four engineers' worth of work. Simultaneously, I was doing all the other Tech Lead responsibilities. But once I was done and the solution was written, it was tempting to simply push the code up. But if I did that, the team would never learn. So while the final output (quality code) was important, even more important was the teams' journey in building the solution. And I couldn't rob them of that experience!
Wouldn't it have been easier to just define what the final outcome should be and let the team create their solution? Sure, it would have been easier. But when the team was given freedom to come up with their own creative solutions, the outcome didn't scale well. It may work for that one particular use-case, but they weren't thinking long-term. I could have pointed that out in the code review process, but they would have had to do it all over again. And at that point, I would've demoralized them so much, they may have just thrown up their hands in frustration and said, “I don't know! Why don't you just show me!”
Instead, I wanted to give them the feeling of autonomy, when in reality, they were very much restricted in how they were to solve for the problem based upon the guardrails I've placed.
The Result
So what happened when all things were literally created twice? Nothing. There were no confusions of what the expectations were, there were no complaints that the requirements were unfeasible, and more or less, our actual sprint completion numbers were very close to sprint commitment numbers. In short, it was a success.