Recent Posts
Archives

Posts Tagged ‘Agile’

PostHeaderIcon [DevoxxFR 2024] Staff Engineer: A Vital Role in Technical Leadership

My former estimated colleague François Nollen, a technical expert at SNCF Connect & Tech, delivered an engaging talk at Devoxx France 2024 on the role of the Staff Engineer. Often overshadowed by the more familiar Engineering Manager position, the Staff Engineer role is gaining traction as a critical path for technical leadership without management responsibilities. François shared his journey and insights into how Staff Engineers operate at SNCF Connect, offering a blueprint for developers aspiring to influence organizations at scale. This post explores the role’s responsibilities, its impact, and its relevance in modern tech organizations.

Defining the Staff Engineer Role

The Staff Engineer role, rooted in Silicon Valley’s tech giants, represents a senior technical contributor who drives impact across multiple teams without managing them directly. François described Staff Engineers as versatile problem-solvers, blending deep technical expertise with strong collaboration skills. Unlike Engineering Managers, who focus on team management, Staff Engineers tackle complex technical challenges, set standards, and foster innovation. At SNCF Connect, they are called “Technical Expertise Referents,” reflecting their role in guiding technical strategy and mentoring teams.

A Day in the Life

Staff Engineers at SNCF Connect enjoy significant autonomy, with no fixed daily tasks. François outlined a typical day, which begins with monitoring communication channels like Slack to identify team challenges. They contribute code, conduct reviews, and drive strategic initiatives, such as defining best practices or evaluating technical risks. Unlike team-bound developers, Staff Engineers operate at an organizational level, collaborating with engineering, HR, and communication teams to align technical and business goals. This broad scope requires a balance of technical depth and interpersonal finesse.

Impact and Collaboration

The influence of a Staff Engineer stems from their expertise and ability to inspire trust, not formal authority. François highlighted their role in unblocking teams, accelerating projects, and shaping technical strategy alongside Principal Engineers. At SNCF Connect, Staff Engineers work as a collective, amplifying their impact on cross-cutting initiatives like DevOps and continuous delivery. This collaborative approach contrasts with traditional roles like architects, who may be disconnected from delivery, making Staff Engineers integral to dynamic, agile environments.

Is It Right for You?

François posed a reflective question: is the Staff Engineer role suited for everyone? It demands extensive technical experience, organizational awareness, and strong communication skills. Developers who thrive on solving complex problems, mentoring others, and driving systemic change without managing teams may find this path rewarding. For organizations, Staff Engineers offer a framework to retain and empower experienced developers, avoiding the pitfalls of promoting them into unsuitable management roles, as per the Peter Principle.

Hashtags: #StaffEngineer #TechnicalLeadership #DevoxxFrance #FrançoisNollen #SNCFConnect #Engineering #Agile

PostHeaderIcon [DevoxxBE 2023] Introducing Flow: The Worst Software Development Approach in History

In a satirical yet insightful closing keynote at Devoxx Belgium 2023, Sander Hoogendoorn and Kim van Wilgen, seasoned software development experts, introduced “Flow,” a fictional methodology designed to expose the absurdities of overly complex software development practices. With humor and sharp critique, Sander and Kim drew from decades of experience to lampoon methodologies like Waterfall, Scrum, SAFe, and Spotify, blending real-world anecdotes with exaggerated principles to highlight what not to do. Their talk, laced with wit, ultimately transitioned to earnest advice, advocating for simplicity, autonomy, and human-centric development. This presentation offers a mirror to the industry, urging developers to critically evaluate methodologies and prioritize effective, enjoyable work.

The Misadventure of Methodologies

Sander kicked off with a historical detour, debunking the myth of Waterfall’s rigidity. Citing Winston Royce’s 1970 paper, he revealed that Waterfall was meant to be iterative, allowing developers to revisit phases—a concept ignored for decades, costing billions. This set the stage for Flow, a methodology born from a tongue-in-cheek desire to maximize project duration for consultancy profits. Kim explained how they cherry-picked the worst elements from existing frameworks: endless sprints from Scrum, gamification to curb autonomy, and an alphabet soup of roles from SAFe.

Their critique was grounded in real-world failures. Sander shared a Belgian project where misestimated sprints and 300 outsourced developers led to chaos, exacerbated by documentation in Dutch and French. Kim highlighted how methodologies like SAFe balloon roles, sidelining customers and adding complexity. By naming Flow with trendy buzzwords—Kaizen, continuous disappointment, and pointless—they mocked the industry’s obsession with jargon over substance.

The Flow Framework: A Recipe for Dysfunction

Flow’s principles, as Sander and Kim outlined, are deliberately counterproductive. Sprints, renamed “mini-Waterfalls,” ensure repeated failures, with burn charts (not burn-down charts) showing growing work without progress. Meetings, dubbed “Flow meetings,” are scheduled to disrupt developers’ focus, with random topics and high-placed interruptions—like a 2.5-meter-tall CEO bursting in. Kim emphasized gamification, stripping teams of real autonomy while offering trivial perks like workspace decoration, exemplified by a ball pit job interview at a Dutch e-commerce firm.

The Flow Manifesto, a parody of the Agile Manifesto, prioritizes “extensive certification over hands-on experience” and “meetings over focus.” Sander recounted a project in France with a 20-column board so confusing that even AI couldn’t decipher its French Post-its. Jira, mandatory in Flow, becomes a tool for obfuscation, with requirements buried in lengthy tickets. Open floor plans and Slack further stifle communication, with “pair slacking” replacing collaboration, ensuring developers remain distracted and disconnected.

Enterprise Flow: Scaling the Absurdity

In large organizations, Flow escalates into the Big Flow Framework (BFF), starting at version 3.0 to sound innovative. Kim critiqued the blind adoption of Spotify’s model, designed for 8x annual growth, which saddles banks with excessive managers—sometimes a 1:1 ratio with developers. Sander recounted a client renaming managers as “tech leads,” adding 118 unnecessary roles to a release train. Certifications, costing €10,000 per recertification, parody the industry’s profit-driven training schemes.

Flow’s tooling, like boards with incomprehensible columns and Jira’s dual Scrum-Kanban confusion, ensures clients remain baffled. Kim highlighted how Enterprise Flow thrives on copying trendy startups like Basecamp, debating irrelevant issues like banning TypeScript or leaving public clouds. Research, they noted, shows no methodology—including SAFe or LeSS—outperforms having none, underscoring Flow’s satirical point: complexity breeds failure.

A Serious Turn: Principles for Better Development

After the laughter, Sander and Kim pivoted to their true beliefs, advocating for a human-centric approach. Software, they stressed, is built by people, not tools or methodologies. Teams should evolve their own practices, using Scrum or Kanban as starting points but adapting to context. Face-to-face communication, trust, and psychological safety are paramount, as red sprints and silencing voices drive talent away.

Focus is sacred, requiring quiet spaces and flexible hours, as ideas often spark outside 9–5. Continuous learning, guarded by dedicating at least one day weekly, prevents stagnation. Autonomy, though initially uncomfortable, empowers teams to make decisions, as Sander’s experience with reluctant developers showed. Flat organizations with minimal hierarchy foster trust, while experienced developers, like those born in the ’60s and ’70s, mentor through code reviews rather than churning out code.

Conclusion: Simplicity and Joy in Development

Sander and Kim’s Flow is a cautionary tale, urging developers to reject bloated methodologies and embrace simplicity. By reducing complexity, as Albert Einstein suggested, teams can deliver value effectively. Above all, they reminded the audience to have fun, celebrating software development as the best industry to be in. Their talk, blending satire with wisdom, inspires developers to craft methodologies that empower people, foster collaboration, and make work enjoyable.

Hashtags: #SoftwareDevelopment #Agile #Flow #Methodologies #DevOps #SanderHoogendoorn #KimVanWilgen #SchubergPhilis #iBOOD #DevoxxBE2023