A model for organising a software company

Stefano Borini

Topics

• Basic overview
• Scrum organization
• Bug triaging and handling
• DevOps services
• Team structure
• Team productivity
• Contact with external teams
• Other

Typical scenario

Multiple Scrum teams working on various parts of your business

• Frontend applications (end user product)
• Backend
• DevOps tasks

How can we optimize

• Internal team performance
• Interaction with external company groups
• Interaction with stakeholders

Scrum organization: Sprint

Two weeks sprints
(personal preference: three, but out of phase with month and possibly other teams. Four is too long)

Regular Scrum ceremonies (with caveats, see later)
planning and prioritisation, daily scrum, end of sprint demo, retrospective, end of sprint slack.

Standup at 9:30 with Scrum Master
Traditional Scrum: self-organising dev teams, with no need for SM at standup.
Personally against it. SM must be “in the trenches” and part of the team, but must not code

Information emitter (Scrum board): Post-it or Digital
Personal belief: tactile feedback of post-it notes has a positive effect on team focus.
Sadly, requires sync effort.

Scrum of Scrums: Tue/Thu at 10:00, with Scrum Masters and Product Owners
Reduces "PO in absentia effect", if occurring, by having PO in twice a week for questions

Planning caveats - 1

Goal: Improve effectiveness of the planning meeting (sprint day 1)

• Team+PO+SM (max 1 hour):
• Present and discuss upcoming stories in order of priority.
• Team+SM (few hours):
• Fragment stories (what to do) into easy to estimate, atomic technical tasks (how to do). Look at code/use team expertise.
• Assign Story Points to tasks as follows: easy=1; medium=2; hard=3.
  If more fragment more.
• Compute Story total effort by summing the Tasks' Story Points.
• Team+PO+SM (max 1 hour):
• Select what to do according to team estimates, velocity, availability.
• Reprioritise/leave for next sprint if needed. Side effect: “accidental” refinement for upcoming sprint.

Planning caveats - 2

Expected result at the end of day 1

• The team understood problems to solve and steps toward the solution.
• The team knows exactly what needs to be done, where, and in which order.
• The team learned more about various areas of the code.
• The team knows tentatively:
• who is the person implementing a given task
• who is the reviewer
according to experience on that part of the code.

Planning caveats - 3

Consequences

• Increase productivity, reduce mistakes and “no idea what I’m doing” factor.
• Ensure at least two people know what is changing and if any code constraints must be preserved.
• Support from SM needed to ensure proper load balancing among team members and reduce chance of code conflicts.
• Team and PO see upcoming stories by backlog lookahead.

Notes

• Teams tend to overestimate tasks: Story Point inflation. Controlled by matched increase in velocity, self-adapting to the team’s definition of easy/medium/hard.

On planning poker

Rough estimate for medium/long term "rule of thumb" planning.
Backed by little evidence, unlike the numbers obtained by the procedure given earlier.

• Management/executives must understand:
• Story Points: fluctuating currency representing complexity, not days.
• Planning poker results are not a promise, only an estimate with limited evidence to back it up.

Bug triaging and handling

• One team member every sprint is designated to assess (not fix) new bugs. Team members rotate on the role.
• Bug fixing either through Scrumban or dedicated sprints, depending on urgency and business pressure.
  ...but be wary of bugfix only sprints. They are heavy work.
• Bugs are initially assigned to user-facing software subsystems. Eventually may reach internal subsystems after investigation.
• Bugs are fixed in development. Fix is tested, then ported to production.
• When using release branches, decide for either:
  • forward cherry pick (release -> master) or
  • backward cherry pick (master -> release)
    Better option. Less likely to be forgotten halfway.
  Not at random, or chaos will ensue.

DevOps services

• Mostly reactive (Kanban) but must have space for a Scrum process to optimise workflow and support tools
• Ensure minimal internal solution development. "Go shopping", don't "build your own". Deprecate "build your own" whenever feasible.
• Valid in general, but DevOps often generates homebrew solutions.
• Focus on your core business and your core products. Buy the rest. Internal solutions have a hidden, sunken cost, and can become a white elephant in the long run.

Rule of three for internal solutions: make it, use it, bin it

Team productivity

Team productivity (velocity) depends on:

• Quality and flexibility of the codebase.
• The power of their tools. Tools matter. Use the best tools available.
• Ability to retrieve and consume missing information quickly.
• Skills in the technology of choice.

Code quality management

Emergent design

• Isolate useful functionality in separate code packages as soon as they appear as isolated conceptual units.
• Do not wait. It will be too late if you do.

Enhancement proposals

• Study a feature and its effects before processing and prioritising for implementation.
• Not epics, not specs: like Python Enhancement Proposals

Code quality management - Technical debt

• Refactoring rarely happens as part of a user story
  Quick and easy wins the day today, but piles up tomorrow.
• Developers are customers too.
  Want improved development efficiency. Not addressing this costs time, hence money.
• User stories: add positive value. Technical stories: remove negative value.
• Sprints keep a 20% SP allocation to address relevant technical stories.
• Team (not PO) prioritises tech stories.

Team productivity and flow - 1

• Establish flow.
• Ensure quiet working condition from external disruption.
• Ensure no other meetings during the sprint. End of sprint day for Lunch & Learn/training/cleanup
• Ensure the team can communicate within itself, but not disrupt other teams. (Open spaces are terrible on this regard. Signal/noise ratio problem)
• Ensure colocation and uniform, reduced, focused communication channels.
• Train developers on new tech with exploratory projects
  You become confident in a new technology after three usages of it

Team productivity and flow - 2

• Ensure that process and tools don’t break flow:
• No to obsolete/limited tools (svn, gerrit).
• Yes to well-integrated, well-structured, all encompassing solutions (bitbucket, github, gitlab).
• Ensure tests success is quiet. Failure is noisy, punctual, and clear.
• Ensure CI failures are delivered only to the involved developer.
• Use linters to remove “style fights” among developers.
• Guarantee quick response from CI machines.
• Guarantee always green master.

Team structure - 1

• Reduce “bus factor”: spread knowledge, but...
• ...developers are not interchangeable or relocatable on a whim. Some people excel in some techniques/parts of the code, are less efficient in others.
• Reject “tragedy of the commons”/“Someone else’s problem” effect. Developers should have loose ownership of code (not strict, not common).
• Make developers feel excellent, dependable, consistent, aware, expert, but not a single point of failure.
• Prevent the blame game by ensuring pre-merge review and mitigating strategies.

Team structure - 2

• Every software subsystem should have a designated “owner” that is the contact for inquires.
• Import members from other teams as needed: e.g. for the duration of the sprint, borrow someone from the core team to tackle API extensions to the core in parallel to frontend changes.
• Teams are built around goals. They are generally fixed because the goals are fixed and the required expertise is fixed. But that’s a coincidence that may not always hold.
• Team members should be interviewing and approving new employee candidates if the team is expanding. They will work together, so they must understand each other.

Interaction with external teams

• Interaction generally relative to the interface their code presents (or needs to present) to others.
• Define interface extensions together with the external team. (however, one has to ensure the external team Scrum process can accept these change requests)
• Better: create cross functional team to address the sprint goal, or import one member from one team to the other.
• Software architects must be involved and direct the process. Disagreement chaos always arises at the interfaces.
• Address fundamental technical issues early if possible (e.g. spooling, atomicity, etc). Use best practices and tools from the start.
• If the external team is on a different timezone, factor it in the process. If the external team exhibits a language barrier, favour written communication (slower, but safer).

Organisation changes

• Reorganise work/management in steps.
• Do not disturb mechanisms that have proven to work.
• Disturb mechanisms that have proven not to work.
• Disruption should be gradual. Throwing a “reorganisation grenade” in a team organisation brings everyone to a standstill, as they have to relearn the process flow while coping with the remnants of the old style and the technical work pressure.
• Be aware of Systemantics (ISBN: 978-0812906745) and well-known management pitfalls (Mythical Man Month, ISBN: 0-201-83595-9)
• Be aware of “eternal September effect” when adding new members.
• Be aware of “death by a thousands papercuts” for team members or teams that have become/are/may become too central for operations.

Documentation policies

• Keep documentation near the code, checked in the version control
• Do not overdocument
• Team must learn to speak a common language: class names, library names, design patterns. This language must be simple and uniform, or confusion and onboarding complexity arises. Pick the right name early.
• Archivist: some people excel at rationalising, reorganising, rephrasing, remembering and directing others to documentation. Nurture this figure.

Other

• UI design and Human Interface Guidelines: interaction with a visual design team.
• Interaction with UI translation team or contractors for language localisation.
• Effective use of project management tools.

End