Events

Here is a description of events that show how these different developers engage with each other and the challenges they face and work through together.

4.3.3.1 Process tug of war

There is occasionally some negotiation between Ivan and other team members like Karo-line, Alex and Calvin. When working in the same team, Ivan had assigned himself multiple important tasks at the same time. Team members like Karoline or Alex expressed some concern initially about those tasks being such that other tasks would be dependent on them and consequently held up. After discussion with the whole team in the daily meeting, Ivan decided to take up the two potentially bottleneck causing tasks.

When all the non dependent tasks got taken up, and the two bottleneck tasks were still in progress, preventing further work from being done, Alex and Calvin spoke to Ivan and helped him determine how to share some of the work to dissolve the bottleneck. Some of it was to convince Ivan to submit the work he had already done locally but not committed to the shared code base, allowing others to continue with some of the other tasks.

In the past, Karoline and Ivan had clashed over a similar situation, where Karoline sup-ported strict adherence to process to prevent one person working on mutliple tasks as the same time and Ivan wanted to take on multiple tasks. In that instance, the negotiation to distribute work did not occur during the sprint. At a later review of the sprint during the sprint retrospective, there was a disagreement about process, which was then resolved with third party mediation.

So later when Alex and Calvin resolved the task allocation issue with Ivan, it was a relief for Karoline to not have to attempt to manage that communication as before and see the team actively manage task allocation and balance during the sprint, and working together

to resolve issues early on.

Through these events, we see how the unwritten process evolves through experience and communication.

4.3.3.2 Team deciding work for itself

In the sprint planning team, when five new members were being added to the existing three member team and the process was being switched from Scrum, which the new five mem-bers had been using to Kanban which the existing three memmem-bers were using. A meeting was organized to discuss protocol and agree upon practices where developers shared their concerns and brainstormed solutions for effective team communication.

The Scrum Master and the software department manager shared their concerns with the team and advised them to keep a small work in progress limit to allow for true paired programming and collaborative opportunities.

The team however felt that a small work in progress limit would leave them bored and would leave gaps in the flow of work. So in spite of the advice they received, the team reminded the others that it is supposed to be a self managing team, and that it chooses to have a larger work in progress limit. This was an instance of the team asserting their vision for how they choose to operate, even though it is not the same as the manager’s vision.

4.3.3.3 Learning to work with different mentoring styles

Alex and Leon with very similar levels of experience have different mentoring styles. Alex and Leon have worked together in the company since it was established. They both have intimate knowledge of the code base and for well over a decade, they were both actively involved in almost anything to do with the primary shared code base. About two years ago, Leon started working on enhancing certain specialty features of the code through research and was not working in the main developers team anymore. Leon’s specialized research meant he was working with other collaborators and not the primary product’s regular development. Alex worked with the product feature development throughout.

The comparatively less experienced developers noticed that when working with Alex, they feel sometimes put on the spot to explain their rationale behind certain decisions or to

76

answer what their code would do under certain situations that the developer may not have considered in the original design. All the developers know that Alex does this to make their code more robust and consistent with the rest of the code base, but they sometimes still feel put on the spot. Alex says he intentionally asks questions about what the developer’s code would do in different scenarios as he doesn’t want to come right out and say "This is wrong, change this." Alex uses the question asking method to spare the feelings of the developer and to allow them to come up with the change themselves.

However, with Leon, the same type of conversation tends to be more casual, where if he wants the new developer to do something differently, he will say he likes their code and will offer a straightforward suggestion asking for something to be changed. Surprisingly, many of the less experienced developers prefer this approach, as they feel less scrutinized.

Some of this could also be a result of how Alex is almost always colocated with the de-velopers and Leon works remotely and primarily communicates over the phone, so he may feel like he does not know the developers as well as Alex.

4.3.3.4 Knowledge transfer

Among the primary development team members, Alex and Quinn have the most knowledge of the code base. There are other developers who also have as much knowledge but have moved on to other projects to use their expertise. The company has expanded in the last few years and has acquired many different customers and different types of contract work.

One of the many motivators for hiring new developers and expanding the team was to facilitate knowledge transfer from Alex to other members. Often, when Alex is working on a task with another developer, the other less experienced developer participates but is usually aware that there is a lot to be learned from that experience. There can be times when the less experienced developer may watch as Alex is coding. Typically, when Alex is part of a team, he usually does the design for most stories and shares it with the rest of the team in the design phase. With his vast experience, Alex is best suited to take the lead on the design, as he would be conscious of how the design affects other components of the software and he would also be able to implement the design fastest, as he has knowledge of the entire system and would not have to spend time looking for the most appropriate place to implement the solution.

However, this also means that the relatively less experienced software developers are not able to get as much experience coming up with design. The process of distributing knowl-edge and moving away from the silo model of knowlknowl-edge is slowed down.

4.3.3.5 Minutiae disconnect

Alex will sometimes ask less experienced developers to redo a piece of working code to be consistent with how things have been done in other parts of the code or due to other overarching coding decisions.

The less experienced developers are often told to redo their code at the time of code or merge review. This often makes the other developers feel less confident about their choices or that whatever they decide now will not matter as much, as they will be asked to change it later.

Alex’s suggestions are always followed, and are often very helpful. However, when other developers are sharing their code with Alex for review, it is often at a stage that the code does what it is supposed to functionally. Often the changes that Alex is suggesting are not in functionality, but in a style or in using a different but equivalent component to perform the same task. This type of change often requires extensive rework, to accomplish the same task.

Sometimes some less experienced developers feel that their code and design choices were valid and that the suggested changes are unnecessary. That their choices are sometimes trumped by Alex’s stylistic choices, even if they are just as good.

Overall, the lesser experienced developers feel like they do not have as much ownership of the code base as Alex does, as his choices often override theirs.

4.3.3.6 The burden of onboarding

All the developers in the software development department have linux workstations. The department manager and others saw value in having at least one developer on the windows platform. Most of the clients use windows and almost all the development is done on linux. This leaves primarily the automated testing in Windows to be the only windows use and exposure the product gets in house. Having a windows development machine means that more scenarios than just those in the automated tests are exposed on windows machines. It also means less overhead when there is a windows specific feature or bug being implemented, as most developers have to perform some set up to run, develop and test on Windows.

78

Karoline was put in charge of the maintenance team when it had some new interns. This was a new experience for Karoline, to lead a team. Aurora, one of the new interns in the maintenance team then had a microsoft workstation, as was decided by the upper manage-ment. However, an intern learning the ropes on windows machines posed other challenges for both the intern and Karoline, as many standard tools and environments would not be as easily set up on windows. Most of the in house instructions for setting up and accessing different systems and tools were also only written for the linux workstations.

It often meant that even Karoline or other developers did not have helpful answers for Aurora when she encountered problems setting up her system. It also meant that the appli-cation sometimes behaved differently on Aurora’s workstation than the rest of the team’s. It made it harder for her to feel like she is up to speed as easily as others and it made Karoline feel less able to help her team member.

4.3.3.7 ‘Pair’ programming over time

It is very common and highly encouraged as part of the company culture for developers to ‘pair’ on a task. Until the year before our observation window, this form of ‘pairing’

often involved the developers discussing the task or design, then dividing up the sub-tasks between them, and they go and work separately and eventually regroup, to discuss further and divide tasks further.

Over the last year, the software development culture is starting to change. When the three newbies joined, two interns and one full time employee, some of what was considered

‘pairing’ started to be redefined. Davin who was onboarding two of the newbies asked them to look over his shoulder as he works and then he looked over the newbies’ shoulders when they tried to work on their first task. While looking over their shoulders, Davin guided them through the problem discovery process, and helped identify a solution while the newbies drove the screen navigation.

This different style of ‘pairing’ continued in the maintenance team, where two people would work on the same task together at the same workstation, while each occasionally drives. Then as the newbies started working with other developers, they followed this new model of ‘pairing’ with them as well. Over a few months, some of the existing, more ex-perienced developers also started ‘pairing’ in this new way, where they would work on the same workstation together.

4.3.3.8 Pace discrepancy

Right after Nathan’s stint in the maintenance team, when he first started working in the pre-release team with Karoline, she found that he took longer than she was used to to go through the investigation step for any bug. She found that perhaps because of his lack of confidence in knowledge of the code base, he would revisit different parts of the concerned code repeatedly, but would not confidently draw conclusions for a day or two. Karoline, who is far more conversant with the code base and the programming language would be accustomed to typically half a day of investigation at the most. In working with Nathan, she would identify the cause of the defect quickly and recommend a solution for it. How-ever, Nathan would continue investigating, unsure of the root cause or solution. He would not be confident that a subroutine being used is actually doing what it should and start in-vestigating subroutine after subroutine, even ones used extensively by many different parts of the code. Then after two days, Nathan would propose the same solution that Karoline would have proposed before. After working in this mode for a few days, Karoline carefully spoke to Nathan, and asked him to trust the code he sees and not try to question everything, especially if it has been proven to work in other parts of the code.

Eventually, Nathan asked Philip for time to learn and become more confident in his lan-guage understanding abilities. Philip encouraged Nathan to take a course for that purpose.

Some time after the course, Nathan appeared more confident in his conclusions about prob-lems in the code.