Over the previous summer, I interned at a company that manufactured paint dispensers called Fluid Management. I was a part of their software engineering team. The structure of this team was a mix of one boss and all-channel network. There was an overall boss of software engineering, and underneath him, the team was split into three functions. These functions were database management, high-level software development, and low-level software development. Each of these groups operated in an all-channel network formation. The groups were relatively few people, between 2 and 5, so they did not get very held up in decision making.
The reason I say the team is a mix of one boss and all-channel rather than just one boss is that tasks were not always assigned through the boss. The project we were working on had a softly defined end goal, and many decisions were made amongst the groups on what tasks needed to be done in what order to best keep the project going. Some portions of the project have interdependence between teams as well, so sometimes tasks for low-level developers were generated and given priority by high-level developers so they could be enabled to continue their portion.
I believe the software team fit every distinguishing feature of high performing teams as defined by Katzenbach and Smith. A large part of the team's success came from the Agile Development process that they adopted.
The core of Agile development is breaking down large tasks. For our work, we did 2 weeks sprints with daily scrum. A sprint is taking a deliverable from the overarching task and working on it for those 2 weeks. At the first day of the sprint we would break this 2-week task down by hour and assign each small portion of the task to the employees. At each scrum (~30-minute meeting) following, we would talk about how we were progressing on our tasks. If there was an issue with someone's task they could draw from the collective knowledge of the team. If the issue was not fixable without some other outside work then the task was 'blocked' and the team member would work on a different small task until the block was resolved. On Friday at the end of the sprint, we would go over how each team members' 80 hours were allocated by task and talk about why some tasks may have not worked out. Then the following Monday everything would start again. I personally found this development process extremely useful in defining what I should do at work, and I think Katzenbach and Smith would agree.
The only aspect of high performing teams that was not covered by Agile is the expertise requirement. In the case of where I worked, we had a very diverse mix of individuals and I believe that helped a lot with developing the correct solution to the problems we encountered. Out of the 10 of us, we had a couple Computer Science majors that were trained in Eastern Europe in the 90s, then they did consulting work until they landed at the company. This means that they were using Java (a programming language that we used extensively) basically since its conception. With their consulting expertise, they knew how to solve a multitude of different problems, and if they ran into a block they could quickly get themselves out of it. We had some younger Computer Science majors as well. They could break down problems differently, relating them to ways of new thinking that they learned in University. For low-level developers there was a similar mix, though the older guys had been in the industry much longer and had a huge wealth of knowledge.
My work over the Summer showed me that having a large team of graduates from the top schools in CS was not the optimal solution. Having a wide mix of talent from different backgrounds and a development style like Agile will result in faster work and better solutions.
The reason I say the team is a mix of one boss and all-channel rather than just one boss is that tasks were not always assigned through the boss. The project we were working on had a softly defined end goal, and many decisions were made amongst the groups on what tasks needed to be done in what order to best keep the project going. Some portions of the project have interdependence between teams as well, so sometimes tasks for low-level developers were generated and given priority by high-level developers so they could be enabled to continue their portion.
I believe the software team fit every distinguishing feature of high performing teams as defined by Katzenbach and Smith. A large part of the team's success came from the Agile Development process that they adopted.
The core of Agile development is breaking down large tasks. For our work, we did 2 weeks sprints with daily scrum. A sprint is taking a deliverable from the overarching task and working on it for those 2 weeks. At the first day of the sprint we would break this 2-week task down by hour and assign each small portion of the task to the employees. At each scrum (~30-minute meeting) following, we would talk about how we were progressing on our tasks. If there was an issue with someone's task they could draw from the collective knowledge of the team. If the issue was not fixable without some other outside work then the task was 'blocked' and the team member would work on a different small task until the block was resolved. On Friday at the end of the sprint, we would go over how each team members' 80 hours were allocated by task and talk about why some tasks may have not worked out. Then the following Monday everything would start again. I personally found this development process extremely useful in defining what I should do at work, and I think Katzenbach and Smith would agree.
The only aspect of high performing teams that was not covered by Agile is the expertise requirement. In the case of where I worked, we had a very diverse mix of individuals and I believe that helped a lot with developing the correct solution to the problems we encountered. Out of the 10 of us, we had a couple Computer Science majors that were trained in Eastern Europe in the 90s, then they did consulting work until they landed at the company. This means that they were using Java (a programming language that we used extensively) basically since its conception. With their consulting expertise, they knew how to solve a multitude of different problems, and if they ran into a block they could quickly get themselves out of it. We had some younger Computer Science majors as well. They could break down problems differently, relating them to ways of new thinking that they learned in University. For low-level developers there was a similar mix, though the older guys had been in the industry much longer and had a huge wealth of knowledge.
My work over the Summer showed me that having a large team of graduates from the top schools in CS was not the optimal solution. Having a wide mix of talent from different backgrounds and a development style like Agile will result in faster work and better solutions.
I had to read your opening sentence twice to get that it wasn't a mistake. You might have typed xxxxxx or something like that. The first time through it was a little odd to read.
ReplyDeleteThis is question about you, not about this post. The experiences that you've written about indicate an interest in programming, which is fine. But then how does economics fit in? Or does it?
Getting to your post, I'm not expert at all in what language software for paint dispensers should be written, but I had to wonder whether there is earlier software that does this function and if so was the product that you were working on a replacement or a fundamentally new application? Part of the reason for asking this is to determine how much invention there actually was in the work being done versus how much it was reproducing already tried and true techniques. The chunking of tasks that you described makes sense to me if you can readily forecast the work to be done, but might have some limitations if there is a lot of invention. In particular, if the process drives the development entirely, a more out of the box approach won't happen. I can imagine in this case would not be wanted as far as delivering on the function. But in one way it still might be desirable, which is to increase the half-life of the application. That's the sort of thing a process-driven approach might not value as much.
Otherwise, I thought you described the teamwork well and that the decision making was distributed. (Boots on the ground in our lingo.) I do wonder what happens to team like this after the project is over. It was unclear from what you wrote whether the internship concluded before that or not. On the one hand, a well functioning teams should stick together and do other great things. On the other hand, the size and composition of a team like this might depend on the what the deliverable is. I'd be curious to know how it played out in this case.
Sorry about that! It was a mistake. I reread my post a few times before publishing but I guess my brain might have just filled in the name of the company I worked at.
ReplyDeleteThat is a great questions that I am trying to find an answer to. I enjoy software development, but I also enjoy data science. Economics would fit in much better with data science, so this upcoming Summer I am going to try to get more experience in that field. I am hoping to be able to decide what I should pursue after that.
The product we were working on what the next generation of the dispenser line. The technology behind the current line is aging and competitors are starting to catch up in terms of functionality. We could not use the old software, though, as it did not have all of the new features that were planned and would have taken too long to modify for it to be worth it. This means we were redoing several parts of the software, but there was a fair amount of invention going on for the new features. The invention type tasks did throw a wrench into planning sessions a few times, with one task in particular taking 4 weeks longer than expected. Other than that the task lengths were estimated reasonably well. In regards to increasing the useful time of the application, that was definitely taken into regard. There were tests running constantly for edge cases and normal daily use that showed the software could run through tens of thousands of tasks and not error out.
With this team in particular the majority would stay on the project to support the device through its lifetime, create new features for the device that companies ask for, and then start development on a new device when it comes the time. When I left the internship the project was still going. It had about a 3 year timeline from initial conception to first sale. This included a lot of testing and getting the device okayed by regulatory agencies. I believe it is still about a year until the first device will be sold to the first store.