When Natalie was part of the Maintenance team following Kanban, it consisted of only three developers, of whom two were newcomers. Initially, most of the work was done together, and the newcomers frequently consulted with the third, more experienced devel- oper on most bugs. At least two of the developers would work together all day and the third would be in discussion with them on multiple occasions. The three developers sat close enough to talk to each frequently.
We see in the interaction diagram in figure 4.12 on page 103 that Natalie worked very closely with Nathan who was the other newcomer, and Davin, who was the early onboarder developer in the Maintenance team and was helping onboard both Natalie and Nathan. The connections between Natalie and Philip depict the daily stand up meeting that they were part of where Philip was the Scrum Master. The other connections indicate communication where Natalie and Nathan consulted with other developers on different bugs. As we see from figures 4.17 and 4.19 on pages 108 and 110 respectively, the typical work for a bug or the typical day of work in the maintenance team included programming alone, pair programming, occasionally a consult with other more experienced developers, attending stand up and presentations for some of the bugs.
In a team so small that worked together all the time, the daily stand up meeting was a practice that the developers felt was more for the benefit of their Scrum Master, Philip, who was also the software department head. In the daily stand up meeting, Philip would sometimes even advise the newcomer developers on which other developers they could consult with.
Daily Stand up meeting: When the team changed from the Maintenance team to the Pre- release team and three to five other developers were added to the team, the Daily stand up meeting became very useful. It was a great way for the developers to update each other on progress and plan, to decide who will work together, who wants help and what needs to be done. In the larger Pre-release team, the daily stand up served its original intended and prescribed purpose. Even though, Kanban with daily stand up meetings were followed in both teams, the change in team size and dynamics made the same practices more meaningful.
WIP limit: In the Maintenance team, as two of the three developers were newcomers, the throughput of the bugs resolved in the team was lower than it would be for three fully operational developers. In this slow progress mode, the ’Work In Progress’ or WIP limit, which is a core aspect of the Kanban process, is not something the team ever had to consider or change. It did not affect the team’s ability to work in any way, as the two newcomers
spent their time learning the system.
When the Pre-release team was formed from the Maintenance team, with a larger number of developers coming in, and the two newcomer developers from the Maintenance team, able to contribute fully, the need for considering terms like WIP limit to determine flow and manner of work completion arose. The team discussed at length about different options for the WIP limit and decided on one where they felt they would be able to work at a brisk pace, with the understanding that they would revisit it when necessary. The team discussed and set their WIP limit at least once a week to keep up with changes in the number of developers and the type of bugs they were working on.
Customer demo: In the Maintenance team, the developers would conduct an open demo for bugs they worked on once every couple of weeks. However, the sentiment in the team was that the demos were not very useful, as presenting fixed bugs did not seem as inter- esting as presenting newly built features to customers. Often in the Maintenance demo, the developers would be demonstrating normal and common uses of the product, some- thing customers are typically familiar with. As the bugs demos were usually demonstrating the bad behavior followed by the fixed, normal behavior; the demos felt lackluster when compared to sprint demos where interesting, new features were demonstrated. The demos served as good practice tools for the newcomers in presenting their work, but did not seem very useful as demos to the customers or other developers.
When the Pre-release team was formed, the work still came into the team in the form of bugs, but the developers felt that the work seemed like medium sized user stories disguised as bugs. The team decided that it was important to conduct customer demos before closing a bug and considering it resolved, especially considering that the bugs were more involved and elaborate than the normal crop of maintenance bugs. This led to a process where the developers would capture and document requirements with the customer or customer proxy for each bug and would confirm resolution of the the bug with the customer through a demo, and would eventually also demonstrate the resolution to the larger developer and mechan- ical engineering community at TAI during the common demos. In their more accelerated and involved mode of work, where bugs were elaborate and often resolved core issues be- fore the major product release, the customer demos seemed more useful and meaningful. We also observe from figure 4.13 on page 104, that in the pre-release team that Natalie’s in- teraction changed from how it was in the Maintenance team. She did not work with Nathan anymore, she worked with a lot of different developers, and this working together was no longer just in small consult sessions, it involved more extensive pair programming sessions. Natalie now worked with Karoline, Alex, Moss and Douglass. Philip’s interaction with the team changed to an intermittent supervisory role and Natalie and the team worked more closely with Steve, the Product Owner.
When the team started working on user stories in Scrum style sprints, the involved pro- cess of customer requirements capture, deliberate design and implementation and multiple customer demos, was the norm. The customer demos were more elaborate and substantial as they were often demonstrating new functionality which elicited a lot of questions, dis- cussions and revisions. In this format of development, customer demos were a crucial and essential part of the development process and felt appropriate and necessary to all devel- opers, and was no longer considered a perfunctory practice. As we see from figures 4.18 and 4.20 on pages 109 and 111, the per bug process in the Pre-release team has evolved to include gathering requirements and customer demos or presentations, along with the pro- gramming activities. In addition, the team attends the Stand up every day - a practice that suits their evolving team needs now.