The purpose of this project was to help a group of students to start using the Scrumban method. This chapter covers each step of the first implementation of Scrumban method to an ongoing project by students.
4.1 Planning and Implementing Scrumban
The development team started working on an internal project with a deadline and re-searching existing Agile methods and choose one of them to implement. Kanban was first implemented, a more flexible style of working to get a faster start to the project. It is necessary to have some guidelines for the team and Kanban’s methods bring them.
The next step was to create the product backlog, tasks, and task labels (for example,
“Frontend” or “Backend”) for what had to be done to get the project going and giving each member a task to start working on. if any task were too time consuming it would be divided into smaller tasks. No issues came up while creating tasks because planning for the continuation of the project was done. The planning included new possible features, improving existing features and requirements for releasing the product.
The team created a Trello board for the product backlog, an easy-to-use digitalized board, where all newly created tasks were put on a column called ‘Product Backlog’.
Other columns were added soon after tasks were added and those were ‘To Do’, ‘Work-ing’, ‘Test‘Work-ing’, and ‘Done’.
The ‘To Do’ column had all the tasks that were priorities for a while forwards, reason for this was because the team was not able to predict how much each task would take time.
The ‘Working’ column had only the task each member was working on, it was agreed that only one task per person, except if the tasks were connected to each other or there were some tasks that had to take priority. Product features and accomplished according to the member working on it would be moved to the ‘Testing’ column. These features needed to be tested before adding to the production version of the project. Tasks that were tested or which were not product features could be moved to the ‘Done’ column, which meant the task was done and next task could be moved to working phase.
23
Once the product backlog was implemented one of the team members heard of the method Scrumban and collected basic information about it. The team decided to use this method and take scrum tools that add more predictability to the project. These Scrum tools were team roles, sprints, daily scrums, sprint review and retrospective.
Scrumban method was decided to be the agile method used by the team. Next steps were to select who would fill the roles of Scrum Master and Product Owner for the project.
The roles were quickly decided, PO would be the product manager and SM was decided to be someone who would help others when needed.
It was necessary to clarify the tasks for each role. SM was responsible for establishing the Scrumban method into the working environment, upholding the agile tools used, find-ing new ones to make the team more efficient, and workfind-ing on project tasks. The PO had the final say on the tasks and giving them priorities, and rest of the team became the development team members mainly responsible for improving the application.
SM and the development team started working on the old product backlog and changing it to match the tools they were using. This included changing all the columns except the product backlog one. Starting by adding the sprint element to each column, the product backlog would have to do, working, testing, and done columns for each sprint. Also, adding a missed column for tasks that were not done during the sprints was necessary, because there were tasks that did not get completed during the sprints. These columns would leave a trail on how the team has managed during each sprint. Image 6 shows the result of the product backlog.
24
Image 6. Trello product backlog of the Scrum Team, the columns are from right to left Product Backlog, Sprint 9 (week 17 & 18) To Do, Sprint 9 (week 17 & 18) Working, Sprint 9 (week 17
& 18) Testing, and Sprint 9 (week 17 & 18) Done, and Sprint 9 (week 17 & 18) Missed.
The next step was to organize the daily scrums; each daily scrum was held every morn-ing at 8:30 and lasted the maximum of fifteen minutes. Durmorn-ing daily scrums, each team member told others what he or she had done since the previous scrum meeting, what to do next and finally, if there had been problems with the tasks.
If for any reason a team member would start talking during someone else’s turn about the subject at hand or anything unrelated to the subject, the SM was responsible to jump in and get the daily scrum back on track. First by defusing the situation by telling the members who were having a conversation “This seems like an important subject and you both have knowledge about it, could you take a moment and continue after the daily scrum” or something along those lines. Then the SM asked the person whose turn it was to continue. SM recommended that people take notes during daily scrums and once the daily scrum is over, talk about the problem or even hold another meeting on the subject.
Facing new technologies, the team saw it necessary to create new tasks whenever it was needed during a sprint.
These four tools of Scrum, namely the daily scrum, product backlog, daily scrums, and sprints, made it easy to follow the progression of the project. Anyone could look at the product backlog, which was up-to-date, and see what the team was working on.
25
4.2 Interviewing Agile qualified engineers on Kanban and Scrum
Since the project team was using the Scrumban Method, three qualified Agile profes-sionals were interviewed by the SM, each one separately. Two of them were certified scrum masters, while the third was a certified SAFe DevOps Practitioner.
First part of the interview was about Scrum methodology: whether they had used Scrum, what the roles in it are and what the responsibility of each role are. Also, whether they were familiar with the tools used and how they had used them, and what are story points, were discussed during the interviews. The three had used Scrum and the tools used were daily scrums, scrum of scrums, sprints, retrospective, and sprint review.
The roles were PO, SM and Development team. PO being the bridge between the de-velopment team and stakeholders. When planning the product backlog, the stakeholders might be too active in the project leading to every stakeholder wanting different priorities and the POs task will be to decide the priorities [20]. SM could be a person with no technical expertise, but some thought they had to have technical expertise. The tasks for SM were basically planning the product backlog with the PO and afterwards with the Development team. Tasks for the development team would be reworked according to the vision of PO into smaller tasks in the product backlog, by the development team and SM. The development team would also be responsible for developing the product. An optimal development team would be full stack developers, but because it would be very expensive, as a team they would cover all the areas needed to complete a project. [20]
[32] [33]
Daily scrums were held for fifteen-minutes every morning with the questions, what the team had accomplished, what they will continue working on and do they have any prob-lems. Scrum of scrums was a higher level of daily scrum where scrum masters gathered and answered the same questions, another difference is if another team had a problem, other SMs could elaborate if they have had same kind of problem before and arrange a meeting on the topic between the teams [20]. If for some reason a team member could not make it, the team could post on Teams or Slack, these are tools used by software development companies, what they have accomplished [20] [32].
26
Story points are a measurement decided by the team, it can be a day, the team could decide that one SP is the easiest task and scale SPs for other tasks accordingly [32], or individual work for each person working on a task [20]. There is a tool that can be used for the team to measure together the worth of a task called Planning Poker, it is a way for each team member to vote the number of SPs each task is worth [33].
Sprints were two weeks, where each sprint focused only on one functionality. Each task needed to be completed and thoroughly tested [20] [32] [33]. Planning was the first and last thing each sprint, where the sprint backlog was completely planned [20]. If any new tasks were necessary to add would mean the sprint would ‘overflow’ and have too many tasks, which could lead to the halt of the sprint and require to plan a new sprint [20].
These would happen only in extreme exceptions [32].
Retrospective, planning and sprint reviews or sprint demo were a combined event that could take up to a whole workday [20] [33]. These tools included reviewing of the product with the stakeholders and having the team go through the last sprint if anything needed improving and the planning of the sprint.
Second part of the interview was about Kanban, how it works and how it differs from Scrum. Kanban is a method that is more flexibility with no other strict deadlines than the product release date. It is a method that requires a lot of communication between the team and not many tasks are worked at once and PO is responsible, like in Scrum, to priorities tasks. But instead of sprints there are weekly meeting with the PO and possibly with the stakeholders, where the team demonstrates the completed work [33].
The accomplishment of these interviews was the expansion of agile knowledge for the team and increasing the understanding of methods and tools that were commonly used by other software development teams and companies.
4.3 Updating, Upkeeping, and Improving Scrumban
At the beginning there were some issues on the upkeep of the product backlog, forgetting to add tasks, moving the tasks from one phase to another or forgetting its existence were the typical once. Daily Scrums were always held normally and afterwards a short meeting
27
if anyone had anything to add to the project, new ideas, next priorities that had to take place, and problems with tasks.
Scrum’s retrospective and sprint review tools were then implemented to improve each sprint. Holding the first session with both the tools where all team members and SM had to attend and speak about the project, essentially making the team strive for the same goal together. Retrospective gave the team a way to freely communicate on the ups, downs, and improvement ideas on the sprints, it also became the sprint planning where everyone planned the number of tasks that they thought could be managed, what the priorities were for this sprint and was any of the missed sprint tasks still high priority, could the members start working on the tasks next or should they be moved back to the product backlog column.
Having too many tasks on the product backlog during sprint was common, the team needed a way to make it more predictable. An estimation was created and marked as Story Points (SP) being a weeks’ worth of work, or story marks being a days’ worth of work.
Story Points were mentioned by all three interviewed engineers in chapter 4.2. SM cre-ated a system which would include SPs and planning poker, removing the story marks completely. On the next Retrospective, the team decided together to test these methods.
Once story points were decided on the next step was to plan what each tasks value would be. The scrum team (PO, SM, and development team) decided to test planning poker to vote for story points required for each task on the next sprint. In Image 7, only SM and the rest of the development team voted. It was done this way because the PO was unsure how to evaluate the tasks. This made it easier for the team to discuss about each task and each member would be heard.
28
Image 7. First try for the teams Planning Poker.
After one try planning poker became a part of every sprint review, the more it was used by the development team, the less tasks were missed. It became a lot easier to plan each sprint knowing the approximate amount of work that could be done.
Another finding concerning the tasks was the size of them, if there were bigger tasks, for example something closer to a user story, it had to be split into smaller tasks. Having encountered this during a Retrospective session a recommendation to keep the large tasks but creating small tasks that were then linked to a task, an example in image 8.
This would continue to leave a trail when each task was completed.
29
Image 8. Larger task with phases given SPs for the work for each smaller task and what the smaller task number is.
Scrumban made it possible to build a method in an image that supports the development team to stay on track during the project and bring value to the stakeholders.