Coffee Break

• If you’re looking to see which methodology your team should choose – it depends. Most tech companies don’t stick to one. In fact, various teams in same company may choose different ones or none at all.
• Productivity of a team often does not depend on the methodology. The alternative reasons could be:
  • Lack of vision
  • Good engineers leaving
  • Lack of transparency
  • Bad tooling
• The area where choosing a different methodology would be clearly helpful is when the intention is to shorten delivery cycles/iterations.
• A shocking insight from the article, some of the big names like FAANGs do not use Scrum. (Meta, Whatsapp, Google, Netflix)
• Couple possible reasons FAANGs do not use scrum:
  • Engineering teams are composed of senior engineers and wants more autonomy over hands-off approach.
  • Scrum has dedicated roles such as Product Owner, Scrum Master, Engineering Manager, Engineers. They each play a different role during the cycle. For organisations that don’t operate this way or want even less bureaucracy, they may see scrum has unwanted baggage.
• An analogy in the article, the writer is on the Skype team and losing marketshare to a scary competitor Whatsapp
  • Attributed project management as part of the reason of slow release cycles. Whatsapp was releasing daily, Skype was releasing every month or 2 weeks while using Scrum.
• Methodology options from Venture firms to Big Techs:
  • Plan, build, ship (Waterfall)
  • Scrum
  • Kanban
  • SAFe (Scaled Agile Framework)
  • Shape Up – (haven’t heard of this before until now, interesting)
  • RFC (Request for Comments)

Big Tech Project Management Characteristics

• Engineers lead the project. Tech Lead may handle a project, or simply another Engineer. Each team are given requirements that is vague enough to not know the implementation details for engineers to decide, but detail enough to know what the outcome is.
• Teams independently choose the project management methodology they feel fits.
• Typically no project managers, but if there are, it would be because the requirements involve multiple team coordinations. Project managers are not dedicated to a specific team, it is shared. (Also known as Program Managers)

• Most teams have backlogs, do stand ups and retro, but not formal.
• First class developer tools are created/maintained by engineers to enable shorter iteration cycles. Ex: Uber has SLATE testing, FB has 4 stage release CD pipeline, Netflix have Data Mesh.
• Companies that attempt to copy Big Techs may not be successful as organization structure can drastically differ.
  • Big Tech Engineers are more motivated to understand business problems and demands higher autonomy
  • Big Tech pays higher salary to (ideally) attract better caliber talents to be able to command autonomy.

Measuring Output

• Speaking from experience and agreeing with the article, POs, Project Managers, and Program Managers frequently look towards the completed User Story (JIRA) in a Scrum environment for reporting. Frequently, it is the wrong way to start in order to measure productivity and aligning overall goals.
  • User stories are usually too low level for POs and PMs to understand what is completed.
  • A majority of the time, User Stories are also not written/defined well enough, and this can cause bad conversations later on as well.
• OKRs, KPIs, and Goals are alternatives for reporting. It would be wise to share what these metrics represent and how a set of stories can achieve them with the team ahead of time.
• Reporting to executive levels is important, but rolling out heavy processes for the sake of reporting slows things down and decreases team autonomy. It can be a cause of concern for constantly optimizing reporting that lead to low trust environment (executives becoming less confident of the reporting metrics as it can be gamified).

How Much Autonomy Should Teams Have?

• This depends on internal team compositions and external factors.
• Internal
  • Are Engineers able to develop requirements with little to no help from technical standpoint? If not, autonomy may not work. The team would need constant directions or mentorship from a detached Software Architect or special consultants.
  • Are the Engineers able to understand the Business and the overall strategy? Sometimes Engineers are not looped into high level meetings at all. Are all Engineers new in the team? In this case, having a PO would make sense.
  • Is the team’s nature of work risk averse or risk forgiving? Most tech companies are risk forgiving as small bugs may not cause huge loss of money or loss of life. For risk averse companies, the project management may need longer iteration cycles. (Ex: Banks, Arms Defense, Finance)
• External
  • Are the teams organized in such a way that they each have clear responsibilities? Sometimes teams are too lean or not lean enough.
  • Is the team constantly overloaded with external requests that keeps coming in? An example is a Platform team that manages the entire company’s CICD. This might be fine for small organization, but can quickly run into productivity scalability issues as the number of development team head counts are much bigger than platform team head counts.

References:

• https://newsletter.pragmaticengineer.com/p/project-management-in-tech – Original Article
• https://www.atlassian.com/agile/agile-at-scale/spotify
• https://www.youtube.com/watch?v=4GK1NDTWbkY – Spotify model video