People Over Processes
Dysfunctional project management often leads to stricter processes. Time to remember that agile is about people.
The Manifesto for Agile Software Development responds to cumbersome and bureaucratic approaches to software project management. Individuals and interactions over processes and tools is one of the principles that have since become the foundation for modern-day software development.
Today, we often forget these principles in discussions about improving teamwork. The answer to a dysfunctional process is often more process, more bureaucracy, more red tape. We propose templates for tickets when the requirements don’t carry enough detail, hoping the structure will nudge authors to add more detail. We create a checklist when reviewers forget to check out and test changes in a pull request. When there is no planning process at all or when it isn’t aligned across different teams in the organisation, a motivated manager steps in and instructs engineering leads to standardise the process and write extensive documentation, so teams never deviate.
Standardised and well-documented processes are appealing. If how we work is specified, we can focus on what we build. Onboarding new employees is easier because there is no ambiguity. People can quickly move between teams without the need for extensive onboarding.
But the practice is messy. Every team works differently, and each team’s practices constantly evolve. They change as old members leave a team, when one member’s role changes, and when new members join. Everyone brings a different personality, experiences, and ways of working. Teams are immutable; when you change the team, you get a new one, reflected in ever-evolving changes to ways of working. They also change with every new client or stakeholder. Some prefer to discover requirements in a face-to-face meeting, and others prefer writing. Some are highly involved in delivery; others prefer to see results every few weeks.
Excessive standardisation is counterintuitive to that dynamic, and it doesn’t necessarily solve the underlying problems of dysfunctional projects. A template for writing a ticket may be sufficient to provide initial guidance for the author. But a template won’t enforce enough context is provided for developers or that acceptance criteria include edge cases and error handling. Such details are uncovered through questions and feedback from different functions. When product, design and development interact, missing details are identified and addressed, and a complete picture emerges. Heavy processes won’t inspire interaction; only humans can.
A known cadence of rituals gives structures interactions. Daily chats about what’s moving can bring people together when work is blocked. Regular meetings to discuss and line up future work creates focus and direction. Not all standardisation is bad, as long as we use it as guardrails to creatively adapt ways of working. Standards shouldn’t lock us into a set of hard and fast rules. Agile practices are about striking a balance between ensuring communication won’t break down and giving teams enough space to explore and find approaches that work for this set of humans and their current project.
Agile principles emphasise human interaction over processes and documentation. They don’t prescribe how we should organise our teams to deliver software, how long our iterations should be, or what goes into a ticket. Agile is about giving teams the power to find the best process for a group of individuals.