My Agile Scrum Coach experience

I coached and evaluated teams of 6-9 students to successfully learn to execute Scrum and agile software development practices in six month capstone projects for corporate clients organized by Aalto University Department of Computer Science. This experience report describes and analyzes the experience from my point of view.

Background

Aalto University offers a Software Project course which is compulsory for all Computer Science students. The course consists of a software development project which is done for a real client from industry or academia. The projects are obliged to apply the Scrum framework, and carry out activities related to project management, requirements specification, design, coding, quality assurance, and system delivery. The students are organized into teams of 6-9 students each including one master’s student who is to assume the role of Scrum Master. The client organization is to provide the Product Owner. The university, in turn, provided an Agile Scrum Coach that is to help the team succeed in the project and achieve all the learning objectives.

The objectives of the course is 1) to equip students with the knowledge and skillset required for being a productive software developer in a large team; 2) to help students understand the structure and technical and non-technical challenges of software development projects, and to apply the Scrum framework in a software project; and 3) to give students an opportunity to learn and apply the development tools and implementation technologies used in the chosen project.

I included this course in the Software Engineering minor studies of my Bachelor’s Degree. In the semester I participated (2015-16) there was a lack of master’s students which is why I volunteered to become the Scrum Master of some team. We chose to take on a project in which we were to develop a tool to facilitate neural networks research in the Triton super computer that utilized the Slurm cluster management and job scheduling system.

I and my team found the project course very interesting and rewarding and indeed our team excelled in the project. After the project, I was asked by the course staff to join the team of Agile Scrum Coaches for the next instance of the course. Due to the very positive learning experience and the interesting opportunity to boost my learning, I agreed. After my first experience as Agile Scrum Coach (2016-17) for two teams I was asked to continue, and I did, twice: in 2017-18 I coached two teams, and in 2018-19 I coached three.

Goals

The objectives given for those assuming the role of Agile Scrum Coach entailed the following:

• Ensure that teams follow the Project Manual and pay attention to work methods and course requirements and processes;
• Decrease the probability of project failure and increase chances of project success;
• Increase learning related to Scrum and other work practices and tools;
• Grade the teams together with respect to their performance in their application of Scrum, work practices, and learning throught the project.

I eagerly took on the duty of Agile Scrum Coach in order to advance in relation to the following personal goals:

• Gain knowhow and practical work experience in coaching and teaching;
• Strengthen my theoretical and practical understanding related to Scrum, agile process and project management, software engineering practices, and software projects in general;
• Strengthen my practical knowhow relating to teamwork, motivation, leadership;
• Increase my social and emotional intelligence, and communication skills;
• Strengthen my skills in project and people management, coordination, organizing, presentation, and performance evaluation.
• Strengthen my general understanding of technical software development tools, languages, ecosystems and frameworks.

Retrospective analysis

To boost my learning I followed the plan-do-check-adjust (PDCA) method. Consequently, I put effort into planning my work and being intentional and systematic in the execution. I also compiled notes and data from my work behavior and its outcomes. I utilized this information in the subsequent iterations to improve my effectiveness as an Agile Scrum Coach. In this section I summarize some analysis results relating to my time use, the feedback I received, and the changes I subsequently made to my work plan.

The basis of my work plan was the very good coaching guide provided by my supervisor who lead the course and all the coaches. Throughout the three instances, I followed a sort of cyclical work pattern: Every 4-8 weeks, I performed a structured analysis of everything the team had done since the last cycle and then gave them written and/or oral feedback highlighting the areas that I felt were most important (their greatest achievements but also the areas needing improvement most urgently). Each project involved about five such cycles three of which were scheduled to match with Progress Review sessions where the teams officially showcased their progress to their client and the course staff and were subsequently graded. In addition to grading, the coaches were responsible for also reading, commenting and grading the learning diaries of the students at each progress review.

I used a set of 25 different focus areas or criteria to analyse and evaluate the progress of the teams. These are briefly described in the appendices.

The five cycles had different focus areas:

Cycle 1: Project Initialization (weeks 40-45)

Team building, roles, responsibilities and collaboration systems; time use and effort, motivation

Cycle 2: Progress Review 1 (weeks 45-50)

Scrum, Scrum Artifacts, course requirements and deliverables, teamwork efficiency

Cycle 3: Product Development (weeks 01-06)

Understanding of Scrum and the role of the Scrum Master, development practices, teamwork productivity

Cycle 4: Progress Review 2 (weeks 06-12)

Application of Scrum, productivity, testing and quality assurance

Cycle 5: Final Evaluation (weeks 12-18)

Final results (the developed product), overall learning outcomes

I collected time use data via a time logging software I have developed for myself. The dataset consists of 1216 entries with a total duration of 398 hours, and a median entry duration of around 13 minutes. The dataset only contains log entries since Dec 24 2016 which means the entire 1st third of my first year of coaching is missing. However, from other sources I know that I spent more than 70 hours during the first third. The five work cycles discussed above are somewhat clearly depicted in Figure 1 below.

Figure 1: Weekly workload in hours across the three coaching instances. To smooth the curves, the hourly workload is averaged across three weeks. Note that data from 2016 is missing and in 2018-19 I coached three teams while in the two other iterations I coached only two teams in each.

Figure 2: Total workload in hours by team. Here estimates of missing hours from 2016 are included in the data to facilitate comparison. The "Other" bars account for work which benefited all teams roughly equally. The graph shows some variance in time use across teams. This is mostly because I tend to put more effort in teams where there are more challenges. However, some teams are also active in asking for my support and presence which shows in the data, although I try to serve all teams equally.

Figure 3: Time use in hours across the top activity categories in the 2018-19 iteration. Note that many meetings were organized to conduct grading and coaching work face-to-face. So in other words, the hours accounted as grading and coaching in the figure are hours spent working on those tasks remotely.

Overall, I think I was able to follow the guidelines and requirements and meet the objectives set by my supervisor in each of the three iterations. I even got praised by my supervisor for a couple of times. However, I received also critical feedback which demonstrated that there was and still is considerable room for improvement. I received feedback orally but also through the official course feedback form as well as a form I developed myself. The following provides a summary of the feedback I received from my coachees and supervisor in the three iterations as an Agile Scrum Coach, and how the input led me to adjusted my plans.

After the first iteration (2016-17) my coachees gave me the following positive feedback: According to them, I was able…

• to be very professional in my role;
• to give a lot of useful high quality feedback;
• to identify and analyze problems in the teams’ work;
• to emphasize and teach Scrum effectively;
• to communicate in a direct and honest fashion;
• to excert a high level of effort;
• to give good ideas to improve teamwork efficiency.

However, I should…

• improve conciseness and clarity in my written and oral communication (see the appendices for an example of a potentially overwhelming feedback email I sent to one of my teams);
• be less intense and more sensitive;
• be less harsh and evaluative in feedback;
• interact and give feedback earlier and more often;
• not focus on just Scrum when evaluating the teams’ work.

Also, I realized I invested about 150 hours in my work while my monetary compensation was based on a fixed workload estimate of 70 hours.

Thus, in 2017-18, I invested time before the projects started a) to further train myself and earn the Certified ScrumMaster (CSM) certification from Scrum Alliance, and b) to plan and prepare how I should adjust my working plan to improve on the identified problem areas and better stay within the my work time budget. Note that the additional time investment is visible in the Other column of 2017-18 in Figure 2.

I subsequently decided to reduce the time I spent on my remote written analysis work, especially in the third cycle, and instead spend some of that saved time working face-to-face with the teams instead. Similarly, I started to be more interactive and frequently ask the teams how they would like me to help them. Finally, while I was happy to invest a lot of time (even unpaid time) because of all the learning, I wanted to also learn to be more efficient and effective in my work overall.

These plans worked and the second interation (2017-18) was more successful in many ways. I decreased my overtime ratio from 2.14x to 1.76x (123/70 h; if we ignore time spent in CSM training and related studying). I also managed to increase my face-to-face time use ratio to 21%. Instead of being criticized for giving excessive written analyses and recommendations that were hard to digest, one of my coachees wrote in the feedback concisely as follows: “We were pushed in the right direction many times and the guidance was good.”

However, based on the experience and received feedback I made the following conclusions on how to improve my coaching in the future:

• Avoid spending too much time over analyzing; Instead, meet the teams face-to-face more often and give concrete tips and ideas;
• Ensure you have built trust and rapport before tackling tricky and challenging issues;
• Give critical feedback preferably in live-meetings;
• Optimize the timing of bringing up issues and challenges based on a) when people are most receptive and b) what maximizes overall speed of progress — ie. prioritize the issues based on urgency and preferably bring them up just as people are beginning to be able to see such problems exist and matter;
• When communicating in writing, take care that you build a friendly and positive vibe, even when you have something negative/critical to discuss;
• Be more laid back, avoid being too serious, be nicer to work with;
• Be socially intelligent; Avoid naming people in negative contexts and give feedback privately when there are issues relating to a specific person;
• Note the achievements of individuals, especially the less active/confident people.

Subsequently, in 2018-19 I continued to increase the frequency of face-to-face coaching and work sessions and focus on improving my behavior as a coach in the above listed improvement areas.

Based on the feedback I received in this third iteration, it can be concluded that I was able to keep improving. I decreased my overtime ratio from 1.76x to 1.72x, while increasing the average grade given to me by my coachees from 3.4 to 4.0. One of my coachees wrote that “Our coach was amazing and did everything to help us” and my supervisor wrote as follows: “You have always carried out your duties diligently, thoroughly, and studiously. Often doing something extra […] You actively take on difficult issues […] Great that you provide “model work” on how to deal with issues for the other coaches to see! You take the time to justify your arguments and give tips.”

However, even after the third iteration, it is clear that there is still a lot of room for me to grow. The main areas where improvement is needed include:

• Continuing to increase efficiency such as to stay within the allocated work time budget.
• Managing with the dual role: being an evaluator in addition to being a coach; Some of my coachees felt that I spent most of my limited time evaluating them and working on process improvement in “managerial” style instead of excelling as an agile coach.
• Gaining more experience in practical development, technologies and tools in order to have the ability to give the teams practical technical advice and tips such as to build goodwill, trust and respect more effectively.
• Continuing to develop in social intelligence and soft skills such as to be able to deal with difficult issues and driving change effectively.

Many of the areas where I have needed to and still need to grow and develop myself, especially related to communication and soft skills, are very tightly related to the limitations and personal growth areas associated with people who tend to emphasize the Driver and Analyzer personality styles such as myself. Indeed, this experience has taught a lot about myself and my personality; My natural strengths and limitations. I believe this has been and will continue to be important for me in my professional and personal life.

While I still have work to do, I am very happy of the working and learning experience overall. The teams I have coached have always met or exceeded the performance objectives expected of them by their corporate clients. Due to high satisfaction among clients, five (out of seven) of my teams earned grade five (the highest grade) out of the course, which reflects clearly better than average outcomes in the context of the course. In the process I have also met various interesting individuals which has made the journey fun and rewarding. Some of these indivudal can be seen from the photos below.

Through the work I gained a lot of experience and developed skills relating to coaching, teaching, Scrum, software projects, agile process and project management, software engineering practices, teamwork, conflict management and leadership. While my focus during this work has been on collaboration processes and team dynamics instead of technologies and tools the work has also provided me an opportunity to enhance my grasp of the technology landscape; Indeed, the projects have involved a wide range of different technologies, tools and services including JavaScript, React Native (for iOS & Android) with Redux, Docker containers, Node.js, Android TV, HTML5, Android, Kotlin, Vue.js, Material Design, Axios, PostgreSQL, Azure, Raspberry Pi, Amazon Web Services, AWS Lambda, Travis CI and PyTest.

All in all, I consider myself to have met all the goals I accepted as given or defined for my self. Thus the experience has been a success.

Appendices

Photos

Photo 1: A photo of the third team I coached. The Product Owner is on the upper left and the Scrum Master on the rear right. This team did excellent work throughout the project.

Photo 2: A photo of a Project Review session. In the audience one can see the professor overseeing the course, two representatives from Accenture (which sponsors the course, evaluates the top teams, and subsequently awards the Quality Award to one of the teams), the person managing the course, and the team's Product Owner.

Photo 3: A photo of the fourth team I coached. From the right, there is the Scrum Master, a technical expert from the client company, and the Product Owner. I am on the center bottom with my neon yellow cycling jersey. One member of the team is missing from the photo. It was a privilege to coach this team!

Focus areas

I went through the following focus areas when analyzing teams. The analyses were used both to give constructive feedback on strengths and areas to improve as well as to compare and grade the teams.

Amount of effort

25 h / ECTS; 225 h for developers and usually 100 h for Scrum Masters.

Understanding and application of Scrum

Keywords: iterative, incremental, agile/flexible (vs requirements churn), holistic, close daily (face-to-face) collaboration of all team members, adopts an empirical bounded rationality approach maximizing team productivity, creativity, and reactivity while optimizing predictability and controlling risks.

Agile team

All team members (devs, SM, PO) involved, active, motivated, committed, and communication is effective.

Development team

Self-driven and self-organizing. Takes full responsibility of ensuring that each sprint goal is met with a production quality increment.

Product owner

Manages the product backlog to maximize the value of work done; A single person from the client organization (or a proxy-PO from the team);

Scrum master

Maximizes the benefits of Scrum; study/plan/teach/ensure the application of Scrum; prepare/lead the Scrum events; manage team building and communication; recognize problems and ensure they are dealt; give tips and help development if possible;

Product vision

Explains why, what (main goals, possibly quality attributes), for whom.

DoD

DoD defines when a SBI is complete at minimum by unit testing, functional system testing, and coding standard criteria; Relevant quality attributes identified; Peer team testing;

Backlog tool

Both product and sprint backlogs maintained with a dedicated tool.

Product backlog

All items have a description, order, and effort estimate; functional features follow some known US template

Effort reporting

25 h/cr; available to coach; updated at least weekly.

Sprints

At least 6 preferably equal effort sprints with student effort allocation

Sprint planning

1) What: BI estimation & prioritization; sprint backlog updated; work broken down to small SBIs; special S0 and S9 tasks acknowledged; sprint goal defined; 2) How: technical design; who, where, when; commitment vote;

Sprint backlog

SBIs for everything required to reach the sprint goal and retro decisions; SBIs have a name/description and the estimated effort as hours/story points;

Sprint review

Completed SBIs are demonstrated to the PO; Incompleted SBIs are discussed openly; It is determined and documented whether the sprint goal was achieved.

Sprint retro

Practice and DoD continuous improvement ideas are generated and discussed based on accumulated knowledge/experience; Decisions and improvement plans are documented and implemented.

Daily scrum

Regularly at least once per week; 5-15 min; Everyone prepared and present to answer what they a) did and b) will do to reach the sprint goal and c) describe any impediments identified; The SM should document the impediments and assign someone to solve them after the daily;

Technical overview

Documents the most important architectural design decisions; at least one relevant view of the design; focus on what is useful (for team, PO, future); helps task division and understanding of complicated decisions;

Process overview

Documents current work practices and tools such that everyone understands how the team works: effort and schedule, events (planning, daily, work, review, retrospective), management (backlogs, time tracking, communication etc.), development (version control, testing etc.).

Learning diaries

Lists three educational observations regarding Scrum or other practices; Summarizes one’s main contributions to the project since the previous entry.

Required artifacts

Required artifacts up-to-date and zip linked to a public web page and sent to stakeholders 24 h prior to review: product vision, product backlog, sprint goals, sprint backlogs, DoD, test session charter(s), allocated/spent effort, process overview, technical overview, progress/final report, learning diaries.

Proposing changes to Scrum

First try working in full adherence to Scrum; Later individual changes may be proposed to the coach by showing that the team has truly tried to follow the corresponding requirement and understands their purpose and by describing the problem and the proposed solution.

Project review

Preparation and presentation of progress/final report slideset: sprint results (goals, SBIs), retros, demo script and screenshots, effort (spent, remaining, per person per sprint); In the final report: peer team’s evaluation of software quality, achievements vs. original/updated product vision, complicating and simplifying factors, overall evaluation of the used work practices and tools.

Problem solving vis-à-vis potentially unique project specific factors

How quickly, effectively and innovatively does the team address and handle arising potentially unique team or project specific problems versus the perhaps extraordinary support the team gets from the client organization or other sources?

Leveraging feedback

How quickly, effectively and innovatively does the team address and improve upon failures, shortcomings and other areas of improvement that the Coach, PO or other stakeholders have identified in the team’s behaviour.

Example feedback email

The below is a feedback email I sent to one of my teams after having studied and graded students’ learning diaries submitted for the first Progress Review. It deals with Scrum related issues and misunderstandings which are quite typical among teams in these projects.

Hi team X!

Here’s the feedback message I let you know was coming!

First of all, apologies for the delay! I hope you have taken this time to exercise critical retrospective thinking to reflect yourselves on the experiences you collected during the first third of the project and the feedback you received via email before the project review during the very first sprints of the project and orally during the first project review. During the month of January I hope you have achieved a rhythm and set of rules, tools and practices that you feel comfortable and effective such that they have become somewhat stable (not completely revamped after each Sprint).

In this message, I attempt to contribute towards solving the major issues identified in your learning diaries. I hope you discuss these recommendations and use during the month of February to try to bring your team performance to the next level.

I made a list of the problematic issues, challenges or negative feelings mentioned in the diaries. The list ended up having many items that dealt with Scrum and its different components. Such items included f. ex. the following:

• Scrum, artifacts and backlog maintenance takes time and is not very useful in our project; Scrum is more fit for professional full-time work contexts.
• Scrum incurs overhead: artifacts and adhering to principles took time from development; little perceived project and educational value.
• Scrum invents unnecessary terms (artifact vs document), instills harmful processes (f. ex. dailies & estimation).
• While Scrum ensures everyone has a good overview of everything it does not seem to benefit the team which makes work unmotivating; with frequent collaboration (pair programming etc) updating the sprint backlog/kanban does not seem worth the effort. Thus they end up to the sideline;
• The role of Scrum master is different from project manager and thus the lack of top-down leadership might lead to some people contributing a lot and others less; It is very difficult to get Scrum applied properly.
• Multiple POs and participants, and lack of structure in meetings made meetings and decision making inefficient (at least during the start of the project).
• PO is responsive but sometimes unclear with requirements; prioritizing the backlog and creating items is left to the team.

Here are some of my points which I consider to be key in solving these challenges:

• Scrum is difficult to master: While it is relatively simple and lightweight when compared to other much used methodologies, Scrum is also fragile in the sense that an attempt to implement Scrum fails very easily when even just one aspect of its implementation fails. That is why it is written in the Scrum Allaince’s guide (https://www.Scrumalliance.org/why-Scrum/Scrum-guide) that “Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety …”
• Thus I believe helping your PO assume the role of the PO more exactly would solve many of your problems and frustration regarding backlog management. If your PO does not give clear tasks and prioritize them, backlog management is more difficult and less worthwhile. The backlog/kanban should feel like a very useful and practical tool to help every developer stay focused and work on the most important tasks. It should not feel like an overhead but if it does and it really consumes time it usually means that a) the selected tool is suboptimal, b) people are not skilled/experienced enough to use it, or c) the system, process or extent of use is suboptimal. In your team’s case it is most likely more about (c) in that it might be because the PO fails to act as a proper PO and thus the sprint planning sessions fail or at least lose meaning such that the backlog seems insignificant for the team, especially when task planning, prioritization, distribution and control is dispersed out of the sprint planning meetings and into the everyday teamwork sessions. I believe the solution requires improvement of the cooperation with the PO. You should invite the PO to your next retrospective and openly discuss the challenges you have identified and teach him/her how to be a better PO (study the backlog, lead the story prioritization work, define the sprint goal with the team, assume responsibility of the prioritization decisions but leave the responsibilities of the estimation and delivery work to the team, etc.).
• I also believe that the overhead you feel regarding artifacts such as the process and technical overviews and the DoD are mostly due to inexperience: When you get more experience with Scrum the feeling of overhead should diminish. Each team needs to find the working practices that serve them best but after a few sprints they usually begin to approach the “optimum” asymptotically such that further changes to the practices are no more so frequent and big that keeping the process and practice documentation could be thought of as a big overhead anymore. The same applies to other artifacts like the technical overview and the DoD. When you have been building something for a few months already, updating the architecture diagrams should no longer take much work since the changes made in any future sprint are likely to be small and incremental.
• As explained in the guide, every implementation of empirical process control (such as Scrum) is founded (also) upon inspection. Inspection is not very reliable/effective when there is no reference (such as an artifact). Teamwork practices and technical design decisions often start to slip toward some inoptimal direction when the team is busy and only focuses on getting the short term work done during each sprint. It can only be prevented by frequent mindful inspection during which any variances observered between the reality (how the team actually works and what it actually does in the heat of battle) and the reference (process and technical overview, DoD – how they decided to work when they last stopped to really think about it) are noted. These variances, their root causes and solutions to minimize the variances in the future should then be discussed in the formal Scrum events (mostly the sprint retro events).
• The fancy words and concepts like “Artifact”, “Definition of Done”, “Scrum Retrospective”, “Scrum Master”, “Product Owner” and “Scrum Team” may feel unnecessary to you. Nonetheless, I believe they are warranted. I believe they constantly remind all stakeholders that Scrum involves specific definitions for each of these concepts and everybody should study them well and know them roughly by heart in order for communication and teamwork to be effective. It is important that all developers for instance understand that they form “The Development Team” which is structured and empowered by the organization (Scrum) to organize and manage their own work optimizing overall efficiency and effectiveness and is the core of not just any team but a “Scrum Team” which involves other stakeholders with other important roles designed to find an optimal balance of flexibility, creativity, and productivity and with the aim to deliver products iteratively and incrementally, maximizing opportunities for feedback and adaptation.
• I believe all Scrum events are important, including the dailies and I am willing to debate over them live. For example, I believe the interruptions dailies cause are a small price to pay in relation to its contribution to team building and communication. In fact, dailies are often thought to reduce interruptions as everybody gets an update of everyone’s situation each morning (or start of development session) and thus no interruptions in the pursuit of updates are rarely needed for the remainder of the sessions.
• I agree that workload estimation is difficult but I also believe that it is necessary in most contexts where there are several stakeholders (that is, pretty much all of the business world). I also believe that while it is difficult, we can become better at it through trial and error (practice). Especially the analysis of past estimation attempts and realizations is valuable when trying to become better at it. It would be very hard to decide how many ECTS worth of courses you attempt to do next period unless a) the teachers have tried to roughly estimate the workload totals for each course, and b) you have took note of your ability to handle courses in the past. Estimation is an essential component of almost any planning/management task despite it being very difficult and error prone.
• Estimating work much of the goal of which is to come up with a solution through brainstorming or idea generation work is especially tricky, since coming up with a clearly formulated idea might sometimes take anywhere between an hour to tens of hours. In such situations, it might be wise to allocate the work iteratively: Decide that today (or during this sprint) one person spends 3 hours on idea generation and we review the results and plan accordingly at the next planning session; If nothing came out of the brainstorming work, we can choose to cancel it or allocate more resources to it.
• You must not let Scrum and its artifacts and practices to fall on the sidelines as they won’t work if they do. The application of Scrum is a core learning goal in this course and a core criteria for evaluation as well. I believe that when you are able to successfully apply Scrum, it will no longer feel frustrating and cumbersome but a useful framework for getting complex products done effectively in a team.
• To ensure everybody stays on the same page it is important not only to maintain a diary of meeting notes but also make sure people follow it; This can be solved f. instance simply by posting the notes of the meeting on a shared discussion forum when the meeting ends thus making it extremely easy for the absent to check what happened / what was decided.
• Managing a teamwork project where the team consists of individuals that did not know each other before and might not be interacting with each other after the project and where they have different resource (skill, time), motivation, and ambition levels is indeed challenging. Scrum requires that the development team consists of roughly equal professionals motivated to and able to self-organize to maximize productivity. This can not always be thought to be the case in settings such as those in this course. It is also often challenging to students when there is such a big team but no “project manager” who delegates work down to team members. In this kind of a project few people can contribute without being proactive and very interested to challenge themselves and learn new (often difficult) stuff. It might be thought that lack of top-down leadership leads to differences in contribution levels (be it due to motivation, skill or other differences). The role of the Scrum Master must be properly understood by everyone and the team should learn to lead itself.

I hope you get to read this message and we get to debate on any of the things that raised your eyebrows as soon as possible! Much of the above may be a bit abstract, but I am willing to try to come up with more concrete ideas for improvement together with you when we meet.

Yours,
Your coach,
Samuel