Skip to content

The Kartoza Scrum Approach

Our Scrum approach is intended to provide an excellent experience for our customers.

Our handbook provides three sections that explain our approach to Scrum.

  1. This document, which is a high level explanation of our approach to Scrum and how we run our sprints.
  2. The daily workflow document provides a step be step guide on how to run your work day. - https://kartoza.github.io/TheKartozaHandbook/company/kartoza/daily_workflow/
  3. The scrum workshop is a practical exercise intended to be used in a role-play situation during staff induction, to train you in following our scrum methodology. - https://kartoza.github.io/TheKartozaHandbook/company/kartoza/working_in_sprints/

What do we do differently?

One key philosophical difference in our approach to Scrum is that we treat the company as the project and the projects as subprojects of the company. This way, we can still execute Scrum in a classical way with daily standups etc., but we work at the company level—our company as the main project.

Scrum and Agile methodologies are designed around teams of eight and usually have a few larger projects with multiple teams working on them. Kartoza is a small company with many small projects where we typically have only one or two developers per project. Therefore, we have adapted Scrum to create our own custom implementation, which is well-suited to our company.

Company wide stand-up meetings

The key difference in our approach is that every day when we have our Scrum stand-up meeting, it will be company-wide for all people involved in production work. This approach has the following advantages:

  1. We reduce the impact of ‘digital isolation’ - the feeling of being disconnected from your colleagues and being ‘lonely’ in your work. By joining a company wide standup, you get to interact with all of your colleagues at least once a day.
  2. We increase accountability. Having to present your work in front of the whole company every day provides an incentive to have something to show for your work the previous day.
  3. We increase motivation. When you falter in your work, your colleagues will notice and be there to boost you. When you are excelling in your work, the whole team is going to be there celebrating your success with you.

Calibration Points - Effectiveness

The daily standup calls are intended to check in on key calibration points that allow us to measure the effectiveness of team members and to catch delivery problems early. The calibration points need to be considered together as a whole, as each adds an element to the narrative of a staff member’s productivity patterns. Each role in the company has different calibration points:

  1. Developer / Technical Staff:
  2. Story points
  3. PRs (if relevant)
  4. Lines of Code / Features Digitised / Lessons Created
  5. Hours logged
  6. Senior Developer
  7. Everything a developer needs to do as above
  8. Developers stay within working calibration boundaries
  9. Deliverable / UR completion in time budget
  10. Daily comms with customer (Communication about progress)
  11. Review and approve PRs
  12. Team Lead / Scrum Masters
  13. Did we meet all the requirements of the contract?
  14. Did we make invoicing / payment milestones?
  15. Did we complete the project within budget?
  16. Did we complete the project within timelines?
  17. Reporting to Management
  18. Review and Approve Time Sheets
  19. Act as ‘spirit guides’ for the teams doing implementation work
  20. Project Manager
  21. Takes ultimate responsibility
  22. Project managers are the linchpin in the company, ensuring a good relationship with customers, providing follow-up business opportunities, and pursuing those opportunities when they arise.

Consequences of miscalibration

During the course of a project, miscalibration will lead to client disappointment, missed deadlines, poorly implemented solutions, lost future business, staff stress and burn out etc. So it is very important that we all operate within the ranges specified. We want to take a moment to consider the financial model of a consulting company like Kartoza and where the weight of responsibility falls when a team member’s work is not within the calibration guidelines. There are three sources that can potentially bear the cost of a team member’s outputs:

Customer-funded work is the first prize! When a customer is funding our work we have a sustainable company and we are meeting our company’s value proposition: we share our team member’s skills and expertise in order to solve our customer’s problems, the customer pays us as compensation for our effort.

Kartoza-funded work. This can often be a precursor or warning that a project is going outside of its calibration envelope. If Kartoza is funding work that is being delivered to a customer, we are essentially paying to build someone else’s solution. In some cases we may choose to do this because:

  1. We have underestimated the effort needed to provide a solution for the customer.
  2. We want to do something ‘extra’ for the customer as a good-will gesture
  3. We want to contribute time for a ‘good cause’ like an open source project or a social initiative.

The decision to invest Kartoza funds into the creation of a project for a customer needs to be taken by Kartoza management. Technical staff should never make this call, and they should defer to management if they see a need for this.

Staff Funded Work: Staff are paid by Kartoza to carry our assignments needed to meet our obligations to our clients. When staff work within their calibrated norms, they receive compensation from Kartoza. When staff work outside of their calibrated norms, we do not accept their timesheets. Let’s give some practical examples:

Example 1: Jane has spent 14 hours across the last two days on a ticket that is sized as 4 hours. Our norms dictate that as soon as it becomes evident that you will not complete a ticket within its allotted time, you need to raise this as an issue to the PM. The PM can decide one of four actions:

  1. Resize the ticket to give you more time
  2. Halt work on the ticket
  3. Allocate the ticket to a different developer
  4. Technical call with senior to give guidance required

Jane’s time logged in excess of the 4 hours allocated for the ticket will be rejected and she will be responsible for catching up her monthly hour quota.

Example 2: Fred has logged an 8 hour day and has closed 8 story points. When reviewing his PR’s the technical lead discovers that the 8 hours of time logged equate to a single PR with 10 lines of extremely trivial code changes. The amount of productivity demonstrated is inconsistent with the hours logged and the technical team raises this as an issue to the PM.

Example 3: Lee has logged only 5 hours on their timesheet yesterday and only closed 3 of the 5 story points they were allocated. The work they did do is of good quality, but the project is now behind schedule. The issue gets raised by the PM who requests that Lee puts in the missing time in order to bring the project back in line with the schedule.

Protecting our time

Because our work calibration process outlined above requires rigorous and careful time management, we need to “protect our time”. This means that we manage our company and our projects in a way that time is not squandered and that every hour that we log on a client project delivers the most possible value for that hour. Some key elements to protecting our time are:

  1. When holding a meeting e.g. a technical break out call, only the relevant people needed to solve the problem should be present.
  2. Critically review all meetings, especially recurring meetings and ruthlessly remove meetings that do not bring value to the company.
  3. Scrum meetings need to be strictly time boxed and run according to a tightly controlled schedule.

In the section that follows, we are going to run through the daily sequence of our two week sprints and highlight other aspects of how we do Scrum the ‘Kartoza Way’.

Terminology

  1. Deliverable / User Requirement - a key feature in the project
  2. Scrum master - Project manager who leads the project and mentors the staff to follow the Kartoza Scrum methodology
  3. Milestone - A significant point in a project timeline that marks progress and helps to track the project's status. Milestones are used to represent key achievements. These are often linked to payments and the tasks shown on the timesheets

Roles and Responsibilities

  • The Scrum master maintains the project vision and aligns it with client needs. They understand the timelines and project constraints. The Scrum master is responsible for understanding the client's needs, and ensuring that we execute according to the client's needs and the contract. The Scrum master will only maintain the epics and the big-picture items on the scrum board, the ‘detailed’ issues are managed by the rest of the team.
  • Our senior developers act as technical team leads, manage tickets and ensure they are clearly described, so developers know exactly what’s required. Senior developers dedicate time daily to reviewing pull requests, ensuring code quality and adherence to standards. This role is responsible for maintaining the tickets that will be worked on and ensuring that all work planned aligns with the architecture set out by the senior developer.
  • Developers and technical staff work to implement the solution for our client. They work through the issues they have been assigned on the scrum board. The tickets should be written such that the developer who is assigned the work is completely clear about what the requirements are and what the technical approach should be for completing that task.

Our Scrum flow

First, let’s take a look at our calendar of events through one sprint cycle:

🟢 - Team Lead, 🔵 - Senior developer, 🟣 - Developer/GIS

Day Communication Action
1 Sprint Meeting (with client) Daily standup (internal) Client feedback Client update email with meeting notes Prep: 🔵🟣 Breakdown parent tickets into smaller tickets. 🔵🟣 Ensure tickets are sized 🟢🔵 Ensure any new tickets are added to the board 🟢🔵 Assign tickets to resources (if not already done) 🟢 Ensure board is up to date 🟢🔵 Prioritise the tickets for “This sprint” and “Next sprint” 🟢🔵Assign tickets to resources (if not already done) 🔵Breakdown parent tickets into smaller tickets. 🔵Ensure tickets are sized 🟢Ensure any new tickets are added to the board Prep: 🟢 Go through the PR list. 🔵Review PRs What tickets were closed/worked on yesterday? What tickets are being worked on today? Any blockers? 🔵Senior dev to send client daily update with new changes highlighted. 🟢To be sent by PMO
2 Daily standup (internal) Client feedback Prep: 🟢 Go through the PR list. 🔵Review PRs What tickets were closed/worked on yesterday? What tickets are being worked on today? Any blockers? 🔵Senior dev to send client daily update with new changes highlighted.
3 Daily standup (internal) Client feedback Prep: 🟢 Go through the PR list. 🔵Review PRs What tickets were closed/worked on yesterday? What tickets are being worked on today? Any blockers? 🔵Senior dev to send client daily update with new changes highlighted.
4 Daily standup (internal) Client feedback Prep: 🟢 Go through the PR list. 🔵Review PRs What tickets were closed/worked on yesterday? What tickets are being worked on today? Any blockers? 🔵Senior dev to send client daily update with new changes highlighted.
5 Daily standup (internal) Client feedback Prep: 🟢 Go through the PR list. 🔵Review PRs What tickets were closed/worked on yesterday? What tickets are being worked on today? Any blockers? 🔵Senior dev to send client daily update with new changes highlighted.
6 Daily standup (internal) Client feedback Client update email Prep: 🟢 Go through the PR list. 🔵Review PRs What tickets were closed/worked on yesterday? What tickets are being worked on today? Any blockers? 🔵Senior dev to send client daily update with new changes highlighted. 🟢 To be sent by PMO
7 Daily standup (internal) Client update email Prep: 🟢 Go through the PR list. 🔵Review PRs What tickets were closed/worked on yesterday? What tickets are being worked on today? Any blockers? 🔵Senior dev to send client daily update with new changes highlighted.
8 Daily standup (internal) Client feedback Prep: 🟢 Go through the PR list. 🔵Review PRs What tickets were closed/worked on yesterday? What tickets are being worked on today? Any blockers? 🔵Senior dev to send client daily update with new changes highlighted.
9 Daily standup (internal) Client feedback Prep: 🟢 Go through the PR list. 🔵Review PRs What tickets were closed/worked on yesterday? What tickets are being worked on today? Any blockers? 🔵Senior dev to send client daily update with new changes highlighted.
10 Sprint Retrospective (company wide - this may not align with the end of sprint) Daily standup (internal) Client feedback 🟢🔵🟣 Prep: Fill out retrospective board What went well? What didn’t go well? What should we continue? Prep: 🟢 Go through the PR list. 🔵Review PRs What tickets were closed/worked on yesterday? What tickets are being worked on today? Any blockers? 🔵Senior dev to send client daily update with new changes highlighted.

Our work planning is in two week sprints. Let’s break down the key activities that happen during the sprint cycle.

Backlog Generation

Before the sprint begins we are continuously grooming our backlog of issues. Every staff member involved in a project is responsible for, and expected to develop tickets and add them to the backlog.

  1. Tickets may be raised organically (e.g. a developer realising something needs to be taken care of while working in a particular area of the code base),
  2. systematically (e.g. the PM writing tickets based on the deliverable requirements) or
  3. externally (e.g. our customer is very engaged with the project and likes to add tickets to the board).

Writing a ticket is not a commitment to actually do the work, it is a marker to show that there is something that can or should be done to move the project forward.

Sprint Planning

Throughout the sprint, all team members are expected to groom the ticket queue by creating new tickets for the next sprint. The day before the sprint planning meeting, the senior developer on the project will review the backlog and create / identify all the issues that are (in his/her opinion) needed to achieve the next iteration of the project. The senior developer will also estimate initial sizes for each ticket and assign a developer to each ticket.

The sprint planning meeting should happen the day before the sprint starts and is a 45-minute commitment from each developer on the project, the project technical lead, and the Scrum master. It may include the client if they are engaged at the sprint level. The sprint planning call is used to assign tickets to developers and address any immediate questions. Any further technical discussions are scheduled separately.

During the sprint planning call, the PM and senior developer will check that they are in alignment with regards to what needs to be built next. The developers on the project will confirm they are able to carry out the issues that have been assigned to them.

⚠️ Most importantly, each person who has been assigned tickets will negotiate the size allocation for each ticket and ultimately agree to complete the work in the allocated time.

Story points for each ticket are collaboratively determined during sprint planning. The sprint technical lead provides initial estimates, and developers can negotiate adjustments. Once agreed, this becomes a mini-contract between the company and the developer. Any deviation from the agreed time allocation without prior approval from the project Scrum lead will result in timesheets not being approved.

The Sprint

Now the sprint is underway. Team members work through the issues in the ‘this sprint’ column of the scrum board and generate pull requests.

The daily PR Review

Senior developers will, as their first task every day, carry our PR reviews. This is again a time boxed activity expected to take 15-20 minutes.

Developers are expected to structure their PR’s in a way that makes it easy to review. For example code should already be Black formatted, and follow our coding conventions.

The daily standup

Each day, everyone that is involved in project delivery will meet for a single 15-20 minute daily standup. This event is in person, on-camera and is mandatory. During this call, the PMs will work sequentially through each project board, taking feedback from the team members and reviewing the tickets closed during the previous day’s activity. This meeting is strictly time-boxed so no ‘chit chat’ is allowed. Neither is any deep technical discussion - those discussions can be taken offline as 1:1 calls by the relevant team members.

Our company operates on a "hours logged for story points" basis. If you are an employee and have been allocated a number of story points, your timesheet needs to be coherent, meaning that the logged hours should accurately reflect the effort put into each story point. This ensures that the workload is balanced and properly documented, aligning with our operational model. We use a calibration approach (see start of this document) to ensure that there is a fair accounting for all effort going into each project.

It's the developer's responsibility to identify any potential deviations from the expected delivery timeline early, ideally around the halfway mark. If it's apparent that the task won't be completed within the allocated story points, they must immediately inform the Scrum master. This could result in changing the story point sizing, pausing the work, or continuing for the remaining allocated time, with further evaluation afterward.

During the daily stand-up, the Scrum master will move tickets into the "In Progress" column, and once the tasks are completed, the developer will move them into the "Needs Review" column.

When a developer deviates from the expected norms, the first instance results in a warning from the Scrum master or team leads. The second time also warrants a warning. From the third instance onward, no further discussion will be held, and the timesheet for that day will be rejected. It's the developer's responsibility to adhere to expected work practices to avoid impacts on timesheet approval.

To calibrate our work properly, tickets must be properly created, assigned, sized, and allocated to developers. Daily stand-ups provide insight into completed work, while the pull request (PR) queue serves as a secondary calibration tool. A senior developer reviews PRs daily, rejecting those lacking passing tests, not following coding standards, or being unreasonably long without pre-approval. This ensures compliance and provides an opportunity for peer review, catching potential oversights.

Developers are expected to produce work that aligns with the ticket sizes and allocated days. While performance isn't measured solely by the number of PRs, the amount of work submitted should be proportionate to the time spent. This helps the technical lead and Scrum master gauge productivity effectively.

When there is little question from the stand-up about productivity, for example, the developer has demonstrated that they closed their allocated share of tickets and moved the project forward substantively, the team lead and the Scrum master do not need to do further probing into the productivity of that developer. If there is a question, then they will go and review the PRs and the timesheets submitted by that developer for that day and understand if there is a disconnect between the work that should have been produced and the work that was claimed for on the timesheets and the work that was closed in the tickets.

Company-Wide Sprint Retrospective

At the end of each sprint, there is a company-wide sprint retrospective meeting lasting one hour, with all staff present. During this session, achievements are celebrated, and feedback is shared. The meeting consists of two parts:

  1. the first 30 minutes for highlighting achievements of the past sprint by each project or developer,
  2. and the second 30 minutes for reviewing the sprint using a review board. The review may include classic questions like what to start, stop, or continue doing, or other engaging questions. Outcomes of the sprint review include acknowledgment and motivation for staff, cross-project knowledge sharing, and stimulation of ideas and inspiration. This also helps with rapid onboarding for staff moving between projects.