Perils of a Software Team

avatar

The team was probably growing a little unfocused. A few players had left in the weeks prior and there was a long and hard campaign ahead. They were definitely the underdogs here, but that hadn't stopped them in the past. The team wrapped up what seemed like a successful summer and were ready for the new season. Forty five minutes later, they were down 2-0 going into the half.

It appeared that things were a little tougher than they had appeared, but now they could make some adjustments and move forward and try to get something out of the game. They looked to the manager to provide some guidance during the fifteen minute respite they had before the second half. The manager looked at the team and told them that he didn't like their strategy and tactics and perhaps they should look into something different, scrapping what they had practiced during the summer.

The team, confused, couldn't understand the manager. The manager left the locker room and the team discussed what had just happened. Some were upset with the manager's lack of vision and others were confused from this newly uncovered lack of faith. The team went into the season confident in their training just to be doubted after all that work. The team went out to confront the manager but he was nowhere to be found.

The final score after ninety minutes was 6-0.


Tool.png

I don't play association football, but I do work on a team. This past week of work was perhaps one of the most uncomfortable and demoralizing weeks of work I have ever had. The team fell apart over the course of the week and it was hard to get anything useful out of them and to make any progress on what we were working on. But at the same time, it's hard to focus when such a heavy wrench is thrown at you.

The team has a soft deadline in April for the project that we are working on. For this project, we have been developing hardware interfaces for the past year and were ready to move onto the final application layer of the project. We had adopted a Scrum-like workflow working in two week sprints tackling different areas of the software project. Over the summer we focused on providing support to a group of student engineers testing the hardware and less on the actual software infrastructure and design.

While this narrow focus make it easier to develop and have tangible goals, being the "Scrum Master" of the software team, I bought up multiple times to the Project Lead that we would need some time to plan out the final architecture of the application layer. I was told to wait until after the summer and focus on testing. I trusted him, so I kept the team focused on the development that supported that effort. We had a few occasional meetings on the side about the application layer but little effort and progress was made in those meetings.

Testing ended two weeks ago, but there were some lose ends from that testing that the development team felt needed to be tied up before moving on development of the application layer. As the team was finishing wrapping up these changes, we had a meeting to discuss the future of the project we were working on. The Project Lead wanted to take an application layer from a different framework than the one we were currently using and use that instead of our current framework on the basis that it was more mature and had better pedigree.

This change seemed to come out of nowhere and I'll admit kind of pissed me off. Anytime any of the team had mentioned anything about future development or wanting to work in that direction, we were instead told to focus on testing for the summer. Which was fine, except for the fact that the lead was now making decisions that had major implications on the team and the software we were developing and nobody had been consulted or even really knew about the concerns the Project Lead had. A demonstration of poor communication leading to chaos.

During the larger staff meeting the fallowing morning, the Project Lead has decided to take up a chunk of our Sprint Review to give his own presentation. Again, nobody really consulted or reviewed this presentation with him although we knew that he planned on giving one as he mentioned it the day prior as he was leaving the office. He told the team that they were now to abandon the two-week sprints in front of the upper management folks and focus on doing research on the different options for frameworks that our software could use, even though the team had committed to the current framework 18 months prior and worked within the framework for 18 months.

Remember that the expectation that the software team was to deliver a finished product by the end of April. Now we were faced with needing to spend the next few weeks researching other frameworks that were likely not very compatible with the work we had already done and we were already on a tight deadline. Hell, the reason for this entire pivot was that the Project Lead was worried that we wouldn't finish on time. Doubt and worry began to spread among the software team.

The software team had another meeting with the Project Lead after the staff meeting where there was disagreement between myself and the lead between the direction that the team should move forward on. I asked the Lead why he wanted to cancel sprints and he said that he didn't want to, but wanted to make things clearer for management. I thought that was kind of stupid because I sensed that he just didn't want to commit to it, and even if that was his intent, that "barrier" of terminology between management wasn't a good thing in terms of communication.

I started to list some of my frustrations including having the lack of any real interface between the shareholders and the software team. The team didn't really have a Product Owner, but the Project Lead had been assigned that role prior to me becoming the Scrum Master on the team. In order to do a good job on this research and progress forward with this plan, I needed to know the higher level requirements placed on the software. The Project Lead answered that he didn't know the requirements and that the team had to figure them out.

Now that we had a Project with no higher level requirements, no Product Owner to develop them, and now we apparently had no faith in the software framework we were using as well as reverting our Scrum team back into a Waterfall team, I was stuck in a place where I had no plan. I felt like was screwed over. Having the weight of an entire project dumped inconveniently on the software team and telling us to basically pivot from the beginning all in eight months, the team was blown up.

This pass week the team attempted to do the research we had been assigned. Unsurprising, the other frameworks lacked any real compatibility with our current project and we had no real direction or leadership to move forward. As the Scrum Master, I felt like some of this responsibility fell on me, but I'll admit that my enthusiasm had been flattened and the lack of confidence made me more distant towards my team. Being an introvert it takes effort to project that focus and confidence outward and I was feeling very burnt out.

I was feeling pretty burnt out prior to this whole blow up of the team and now I had more to worry and stress out about. By the end of the week, the whole team had basically checked out of the research we were supposed to be doing and stuck not really doing anything really useful. I don't know what I am really supposed to do as I really lack experience as a leader in a moment like this. I only became the Scrum Master since half of the team left in the spring to pursue other opportunities.

Honestly, I feel like I would be more productive if I came into the office alone and could simply focus on things without worrying on the status of the team, but that's indicative that we have a real problem here. It didn't help that the Project Lead was basically out for the second half of last week and provided very little guidance at the beginning for the research he wanted to be accomplished.

There is a real lack of vision and no real goals for this project. There is no next step and there are no requirements. It seems like I am swimming into a black hole that I can't escape and it sucks.

I want to turn things around and I generally do care about the work I'm doing but the apathy and lack of faith coming from all directions is making things kind of hard right now. This is a great test of my leadership abilities and I feel like I'm failing that test pretty hard right now.

My usual coping strategy for being overwhelmed is to compartmentalize things and focus on the highest priority areas first, but having to attack the entire large nebulous project and then trying to communicate that to my team has proven very difficult. It feels like I have to redefine the entire project in context of this entire mess and that's why it has been nearly impossible to break up.

Tomorrow is Monday. I'll try to get things back on track again. The worst that can happen is failure, and honestly failure isn't that bad at all. Unfortunately, most people don't understand that. And sometimes I forget. I'll try to remember better this time.



0
0
0.000
4 comments
avatar

If it's any comfort -- you were absolutely screwed over. But it sounds like the deep digging started long before this last week, when nobody was put in charge of actually determining requirements for the architecture in the first place. And over the last eight months, no one higher than you on the totem pole seems to have decided what the actual purpose of the programming effort was intended to deliver, which is the whole point of doing the work in the first place.

Let me repeat that, because a lot of people miss that (but you don't seem to have): The reason that we do work is to accomplish an end, to achieve a goal, and not just to keep a bunch of dudes busy while you give them money. And the time to do that is before you start giving direction to those guys who have to start digging the ditches.

Now any of us can find ourselves in this position plan higher leadership has failed its job and left us holding the bag. And it sucks. Your responsibility as a leader of that group is to step up and challenge the guy who is holding the authority and title of Team Leader but is not doing the leadership of a team leader.

You have to advocate for the guys marching behind you. Sometimes that means biting the bullet and just saying, "that's not going to work, and here's why." And if they are adamant about pursuing that particular path, sometimes you just have to walk away, which sucks for an entire multitude of reasons.

"What the Hell do you mean 'research'?" is probably a phrase that should've come out of your mouth a little earlier. It's all part and parcel of that advocacy. If I'm understanding you correctly, this team was constituted to actually implement testable hardware interfaces, and the application layer had to follow suit on that. Rather than the application being solidified far enough for you to put together the hardware interfaces for it to hook up.

You've been testing over the summer. Are the hardware interfaces effectively complete as far as you're concerned? Are there hooks there for software to connect to to do the job? Do we even know enough about what the job is to make that determination? (If not, that's an even bigger, higher level problem.)

If the interfaces are effectively done, they need to dissolve the team and reconstitute them with a new, clear directive. If building the framework is the new goal, that needs to be communicated clearly and the team effectively reassembled from scratch in order to provide closure and continuity of experience.

It sounds to me like the whole software project has a bigger failing, with not enough ownership, not enough top-down direction, and not enough vision existing -- but that's something only you can find out. You're going to have to step around the current Project Lead and get in touch with people higher up in order to find out if the vision has just not been communicated or whether it doesn't exist.

The rest of the team can't really get their feet under them until that is clear to you and in turn to them.

That's just the way it is.

0
0
0.000
avatar

It sounds to me like the whole software project has a bigger failing, with not enough ownership, not enough top-down direction, and not enough vision existing

Yeah this seems to be one of the biggest issues that has come out of the past week or so of conversations and discussions the group has been having. Until the group has tangible goals contextualized in a clear vision of the Project, it is impossible to prioritize work and know what areas we should be focusing on as well as what potential areas/features we may have to abandon due to time constraints.

Luckily, I have meetings with both the Project Lead and the higher ups this week, so we should be able to hash that out or at least expose the lack of vision as a major issue.

0
0
0.000
avatar

If it's any comfort -- you were absolutely screwed over. But it sounds like the deep digging started long before this last week, when nobody was put in charge of actually determining requirements for the architecture in the first place. And over the last eight months, no one higher than you on the totem pole seems to have decided what the actual purpose of the programming effort was intended to deliver, which is the whole point of doing the work in the first place.

Let me repeat that, because a lot of people miss that (but you don't seem to have): The reason that we do work is to accomplish an end, to achieve a goal, and not just to keep a bunch of dudes busy while you give them money. And the time to do that is before you start giving direction to those guys who have to start digging the ditches.

Now any of us can find ourselves in this position plan higher leadership has failed its job and left us holding the bag. And it sucks. Your responsibility as a leader of that group is to step up and challenge the guy who is holding the authority and title of Team Leader but is not doing the leadership of a team leader.

You have to advocate for the guys marching behind you. Sometimes that means biting the bullet and just saying, "that's not going to work, and here's why." And if they are adamant about pursuing that particular path, sometimes you just have to walk away, which sucks for an entire multitude of reasons.

"What the Hell do you mean 'research?''" is probably a phrase that should've come out of your mouth a little earlier. It's all part and parcel of that advocacy. If I'm understanding you correctly, this team was constituted to actually implement testable hardware interfaces, and the application layer had to follow suit on that. Rather than the application being solidified far enough for you to put together the hardware interfaces for it to hook up.

You've been testing over the summer. Are the hardware interfaces effectively complete as far as you're concerned? Are there hooks there for software to connect to to do the job? Do we even know enough about what the job is to make that determination? (If not, that's an even bigger, higher level problem.)

If the interfaces are effectively done, they need to dissolve the team and reconstitute them with a new, clear directive. If building the framework is the new goal, that needs to be communicated clearly and the team effectively reassembled from scratch in order to provide closure and continuity of experience.

It sounds to me like the whole software project has a bigger failing, with not enough ownership, not enough top-down direction, and not enough vision existing -- but that's something only you can find out. You're going to have to step around the current Project Lead and get in touch with people higher up in order to find out if the vision has just not been communicated or whether it doesn't exist.

The rest of the team can't really get their feet under them until that is clear to you and in turn to them.

That's just the way it is.

0
0
0.000