Manager's Dream

Osman / December 30, 2023

“I bought my freedom through the skill of my hands and the labor of three of your human lifetimes.” Kuiil

Ron Jeffries once said, “I like to say that I may have invented story points, and if I did, I’m sorry now.” The conversation about story points has deeper roots. Management typically focuses on the “time” aspect of processes, which differs from technical teams’ concerns. We often hear questions like “How long will it take?” or “When will it be done?” so these questions are pervasive.

Nowadays, every company claims to be Agile, and most of them use Scrum. It is an ornament in job descriptions, making them look attractive. We tend to bond Agile and Scrum, but they are distinct concepts. Agile is a philosophy with a manifesto and clear objectives, while Scrum is a framework established by two Agile Manifesto signatories. Organizations such as Scrum.org and Scrum Inc. essentially monetize Scrum—not Agile—through certifications, trainings, books, seminars, etc. The Scrum Guide describes the Scrum process, which includes sprints, sprint planning, daily stand-ups, sprint reviews, retrospectives, and backlogs, most of these terms related to time and all attributed to Scrum, not Agile. All things considered, we should definitely differentiate between Agile and Scrum, recognizing them as separate entities.

“Real Agile is to pick the next few things to do, and do them promptly. The key question is to find the most valuable things to do, and to do them quickly. Doing them quickly comes down to doing small slices of high value, and iterating rapidly.” Ron Jeffries

This statement opposes the concept of sprints; it shifts our focus from time-boxed outputs to priority-driven efforts. A sprint is a closed box with no in-and-out. In contrast, we need a flow, similar to a film frame: flexible, evolving over time, with the priority being to organize features. Our measurement unit will shift from acceleration to velocity and pace. Within time-boxed sprints, there’s scant opportunity for reflection, as tasks fill the board—some more visible than others—pressuring developers to work mechanically rather than thoughtfully. On the other hand, flow prevents items from piling up in backlogs, there’s no staggered delivery or acceleration through sprints, and there’s less need for estimations based on item complexity.

Time constraints are predominantly imposed by customers rather than managers. On occasion, a manager who works closely with a customer may display signs of what could be colloquially referred to as Stockholm Syndrome. A PM who is able to maintain objectivity and independents from the team can effectively negotiate with customers, which is a hallmark of strong management but might cause friction with colleagues.
Customers often perceive that they are being deceived by the company. They seek to monitor progress and review timesheets to ensure that their finances are handled properly.
This issue is more ethical than organizational. Still, it is increasingly challenging to find customers who are willing to truly collaborate.

“Individuals and interactions over processes and tools” Agile Manifesto

Scrum, Jira, and other project management tools are attempts at premature optimization when working with people. They tend to prioritize processes over people. However, software development should not be organized exclusively around processes. The key element is a team culture—a culture of self-management, trust, and collaboration within an endless feedback loop, akin to ‘total football.’ The team is dynamic, with each member capable of seamlessly backing up another. A team without culture is just a group of people lacking cohesion, and without cohesion, a team becomes brittle, unlike a fluid environment. Test continually and make the code testable and modular. Cultivate a cultural practice of slicing features into deliverable segments. Such practices must be integral to the team because when the managerial approach shifts in the Scrum world, so too does the workflow.

The team should not rely on a hero programmer or leader. An environment that encourages elite performers can be alienating for others and ultimately unsustainable. Software development is propelled by people who form teams. Organizing a team with diverse skills and experience is crucial to practicing Agile, particularly in our remote-first world. Building a cohesive culture is challenging, and no amount of team-building activities or company picnics can substitute for genuine collaboration and trust. If a large company does not scale wisely, it is liable to collapse under a weight of bureaucracy and hierarchy, causing individuals to stay under the radar.

In an ideal scenario, a development team would function seamlessly; however, we do not exist in an ideal world. Team members possess a diverse range of skills and personalities. There are individuals who prefer to work simple, focusing solely on the task at hand without engaging in deeper thought because their primary motivation is to work. While this may be a valid approach from an individual’s perspective, it can create bottlenecks within team processes. Eventually, such an approach may lead to frustration among the more diligent and engaged team members. Therefore, constructing a cohesive and effective team requires a certain level of expertise and craftsmanship. This is why it’s crucial to invest more in fostering a strong team culture and carefully selecting the right candidate; it should never be considered a trivial task.

Developers should possess management skills, capable of overseeing their own work and time and discerning what what to make and what not to make. Simplicity is achieved by shedding the burden of unfinished work. Developers should work in close proximity to the product, without a middle manager serving as an intermediary. Teams should adhere to a priority list derived directly from the customer or user. As the Agile manifesto suggests, the focus should not be on negotiation but on collaboration with the customer. This approach revolutionizes our work with customers, shaping both our relationships with them and our delivery process. The team should function like an octopus—with multiple arms, precise coordination from development to customer/user, swift responses to requirements changes or shifts in direction, and the self-organizing capability to adapt to various situations.

Requirements frequently evolve during a project. Customers often have ambiguous requests and only recognize their true needs upon seeing the final product. Imagine a scenario where a customer sees their concepts actualized after countless sprints, presenting a considerable challenge for traditional managers, even when everything is factually completed. We are therefore driven to produce continuously and iteratively, placing results in customers’ hands for immediate feedback, and updating requirements and features dynamically rather than relying on static documents. When an issue arises, the team should address it without delay; avoid postponing bug fixes to the next sprint. Communication must be constant, especially in our remote world; transition from scheduled meetings to spontaneous huddles with a few team members to resolve problems swiftly.

Let’s discard the illusion of predicting the future. Estimations only add pressure on team members and inevitably give rise to comparisons within and between teams. While part of the team spends time planning, no plan can realistically be executed without discrepancies, leading to parts of the plan being lost in translation from ideas to tasks. Teams should share collective ownership over challenges, with each individual feeling responsibility.

Overall, software development requires adaptability, collaboration, and a focus on value-driven delivery rather than rigid adherence to estimations and processes. This Agile mindset supports innovation, flexibility, and a human-centric approach empowering teams to achieve their goals.