All Rivers Lead to Scrum?
I recently listened to a podcast episode with that name (Hebrew) and was quite disturbed, as I had thought I would from the title.
The hosts and guests are well rounded, very experienced and deliver professionally with humor. They are joy to listen to and many episodes are excellent.
The trouble is not that they made mistakes or misled, rather inaccuracies and having too narrow a perspective, not promoting much more beneficial techniques. They may perhaps be useful for developing medical devices, but they were presented as a rather global truth.
I suspect this view is widely common for generic web SaaS companies and here’s my take, with suggested alternatives.
Scrum is the major agile methodology
According to Digita.ai’s 16th annual report, 87% of organizations using an Agile framework use Scrum. So by popularity yes, but we could very well argue that Scrum is not agile, while it can be.
The word “agile” is not mentioned in the Scrum guide (and please, use “refinement” instead of “grooming” — it was removed in the 2013 version for a good reason).
Scrum might even promote waterfallish behaviors, i.e. hand-overs:
market > business > product manager > designer > architect > developer > tester > release manager, where the business people get the market needs and transfer it to the PM who in turns generates requirements outside of the sprint and then the sprint itself is about the development, testing usually by someone else, and the release might even occur outside the sprint by someone else.
This leads to miscommunication and delays, as well as bottlenecks (“not enough QAs to test our code”), knowledge silos, low bus factor and lack of ownership. Delivery is also in question, as things are not really done in the sprint.
Alternative: use Kanban or XP, involve engineers from customers to development, testing, deployment and beyond. (Kanban is not just for “service teams” like IT, they are perfectly fine for product engineering teams).
Sprint reviews
Started with the good intention of radiating knowledge and showing progress, and in reality became a place where internal stakeholders review and criticize the output instead of the real market doing so (outcome).
Alternative: drop reviews, release to the market as quickly as possible, gather feedback and adapt.
Estimations of tickets
Besides the draining ceremony of voting, some CEOs and VPs want predictability and stability of delivery of “points”, so they could estimate when a project is done or what the version would contain. This can be quite pointless as software is not done, it evolves, and delivering small increments to the market and collecting feedback is the most important thing. What is the benefit of delivering the same number of points every sprint?
Are you promising features and dates to customers? What for? What if priorities change?
Alternative: drop estimations, break stories down to smallest value and keep working on the highest priority items.
Instead of a roadmap that is features attached to promised delivery dates, they contain only the order of problems to be worked on, not the solutions, in a “now/next/later” fashion.
Projects
Are the opposite mindset of incremental value bringing. “The next project is divided into 5 epics and takes 100 story points” — it implies that in the very beginning, when we have the least knowledge, we already planned the whole project, without considering any customer feedback. There is nothing agile about it. Projects encourage long term development in the dark and learning from it after many weeks.
Alternative: start small and deliver incremental value continuously. You might learn you need to drop the direction, change it or double down. #NoEstimations
S crum of scrums
On top, there are various types of coordinating the different teams, like PI Planning (Program Increment Planning) which is a higher objectives planning, joint weekly standup of representatives of all teams and SAFe.
Alternative: use quarterly goals system like OKRs to align, and sync no-demand or periodically between teams’ leadership.
While we’re at it — Product Owner is only a role in Scrum teams. It is not the same as product manager.
Functional teams vs. squads debate
Functional teams are split by profession, e.g. frontend developers, backend developers, testers and ops. Squads (a.k.a stream-align teams) are autonomous and cross functional, meaning, various “professions” are represented in the team and own a specific business domain end to end (may even include marketing and customer support).
The pros of functional teams: the manager manages all directs in the same exact profession, making it easier to notice nuances and improve performance and growth, also deepening the knowledge by learning from each other.
The pros of cross functional teams: they are much faster (which is crucial) as they have all needed skills in the team, not needing to coordinate and handover back and forth. It has much higher business continuity as each engineer can do other types of work, even if at lower quality and slower expertise development. Knowledge is shared quickly and it’s easier to move teams and change the org structure. It can be used as a reverse Conway maneuver.
The debate sounded out-of-time as it was discussed already 10 years ago.
Refer to the Team Topologies book for clarification about stream-aligned teams and platforms teams.
Not allowing engineers to do parts of the work (e.g. infrastructure, CI/CD, monitoring and alerting, rotating on-call) or having specific role of “tester” is counterproductive and encourages “throw over the fence” behavior. Not to mention having a separate QA organization.
Alternative: stream-aligned teams “you build it, you run it” — mobile, frontend, backend, infrastructure, quality, platform teams (SRE, data, …) to reduce cognitive load with professional guilds and knowledge sharing sessions.
Product Manager decides and assigns work
Not one single person is the smartest or “represents the customer’s voice”. If engineers and designers are not talking to customers directly and merely execute tickets that the PM wrote for them, they are mere “code monkeys” and their brains are underutilized. They take part in a feature factory, not an empowered team that prioritizes together, more engaged and accountable.
Alternative: the product-engineering team is empowered to define and prioritize work.
Only Team Lead writes technical tickets
Sounds like an anti-pattern as every work brings some value to the customer, and technical work is also product work. This introduces further silos, bottlenecks and blocks engineers from writing their own tickets. Having separate “product backlog” and “technical backlog” makes the problem more acute.
Alternative: anyone can write any ticket, find business value in “technical” tickets.
Cross functional teams can ruin each other’s work
Yes, but more often, functional teams are waiting on each other and must balance people and resources for them.
Ruining or duplicating work can be rather easily avoided by splitting to domains, with clear domain boundaries and again, offloading platform work to designated platform teams.
They are communicating via public (internal) APIs or schemas.
Having goals like OKRs and common strategy prevent teams from working on opposite targets, such as growth vs. cost reduction.
Dependencies always pop up and they are mitigated ad hoc or in advance in case they are identified. Duplication might be even a positive thing as “shared libraries have shared bugs”.
Alternative: common published goals with sync meetings when needed
Hire managers who can lead both backend and frontend
Hire anyone who could do engineering work and for managers also leadership work.
There is more than backend and frontend — mobile, infrastructure, alerting, cloud native and more. Hire engineers and managers that solve customer problems, not a “java backend developer”.
Make it very clear in the hiring and onboarding process. Yes, developers might not be happy to pair and work outside of their expertise. They might also prefer to get paid weekly instead of monthly, but it won’t happen. You need to consider the company’s needs. If they are not willing because they don’t like this work or they prefer to deepen rather than broaden their skills that’s fair and it’s not the right place for them. And it is not about full-stack, it’s about willing to do what it takes.
Alternative: hire engineers who are willing to touch more areas and set the expectation clearly.
