Agile software development promises faster delivery, greater flexibility, and increased customer satisfaction. But making it work can prove challenging, and companies, teams and individuals each bring their own flavor to the process. Even among Levi9 developers, perspectives on applying Agile are different.
Levi9 developer best practices in Agile
- Use SCRUM as a starting point, but don’t let it override customer focus.
- Add a technical refinement session, with developers only, for better estimates.
- Split big story points into more manageable pieces to avoid inevitable spillover.
- Expected functionality should outweigh the story points.
- Use story points for predictability, not time pressure.
- In retrospectives, focus on what to stop doing, start doing, keep doing.
- At any stage, the key question remains: “Is the client happy?”
Agile is “a set of values and principles for software development under which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams,” explains Tiberiu Grădinariu, Mobile Tech Lead at Levi9. “It focuses on customer satisfaction by early and continuous delivery of valuable software.”
The core values outlined in the Agile Manifesto prioritize “individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.”
Agility with focus on the customer
However, agility can quickly turn into rigidity. “I think the mistake teams end up making is that they try to adhere to the Scrum principles more than to the product itself and the customer themselves”, warns Tiberiu. Not wanting to dismiss Scrum completely, he believes that, when embarking on a new project, a team needs a starting point. Scrum, which prescribes set meetings and roles, is the most common Agile framework. “I believe Scrum is a good starting point,” he said, allowing the team to assess complexity and establish expectations before tailoring the process.
Of course, once underway, the development team needs autonomy to shape the processes to best fit their needs. As the Agile Manifesto itself says, self-organizing teams should value “individuals and interactions over processes and tools.”
Technical refinements for better estimates
Estimation inconsistencies remain an ongoing frustration for many Agile teams, including Tiberiu’s. “Estimates are inaccurate, and we are not aware they are inaccurate,” he says.
To help mitigate this, Mihaela Rădulescu, Levi9’s .NET Tech Lead, has added an extra refinement step to her team’s Agile process, called “technical refinements.” Unlike typical refinements that ensure a shared understanding of requirements, these sessions only include developers.
“We try to figure out on a high-level what story implementation entails,” she said. By outlining basic ideas regarding technical parts and implementation difficulties, they provide developers with more background for estimation without getting caught up in unnecessary details too early.
Epic ownership puts developer in charge
Establishing better estimates gets trickier when they depend on another team’s backlog, for example. This directly impacts the team’s ability to accurately size its effort. “You obviously can’t work on a task that isn’t refined,” says Tiberiu. “But who goes to gather the information from the other team?”
His answer is that developer responsibilities should expand beyond coding to include gathering necessary information, especially when needed from outside partners. “Developers should not just write code,” he said. “Figuring out the details of what needs to be built, what are the dependencies, the blockers and when will those blockers be resolved is also key.”
For such situations, Tiberiu’s team has implemented a process called “Epic Ownership” aimed at giving developers more ownership over high-level work packages and associated communication channels.
“One developer takes point on the epic,” he explained. That developer is responsible for refining the stories, answering questions at refinements, gathering open dependencies, and generally serving as the point person for all things related to that epic.
According to Tiberiu, this helps build critical skills around organizing meetings, documenting discussions, and managing communication with stakeholders. By dividing up the coordination tasks amongst several team members, it also helps reduce bottlenecks.
Expected functionality outweighs story points
Codrin Băleanu, Engineering Lead at Levi9, points out that large tasks can become bottlenecks, especially during code reviews. “Task estimates of eight story points are likely to spill over,” he warns, recommending smaller, more manageable tasks to improve predictability and efficiency.
Human factors complicate estimations further. Developers may rush to complete tasks before a sprint ends, potentially sacrificing quality. “It’s human nature to avoid being the scapegoat for spillovers,” Tiberiu observes, highlighting the pressures of meeting sprint goals.
Victor Munteanu, Test Architect at Levi9, is concerned that teams are being pressured to operate in an unrealistic manner due to the emphasis on story points and sprint commitments. “You shouldn’t think about story points when committing to deliverables for the sprint,” he said. “The sprint goal and expected functionality are what matter.” In his opinion, story points only serve as a unit of measure to assess velocity—not make rigid plans.
Story points = Time pressure (or not)
“Story points equal time equals pressure,” Tiberiu said. “Although story points mean complexity, inevitably they end up being time.” At the same time, metric targets for story points completed per sprint incentivize teams “to deliver story points,” Tiberiu warned. Shortcuts can emerge, such as treating the code review stage as a deadline extension for improving code.
Others see value in utilizing story points for planning if done thoughtfully. “It matters a lot why you want to use these story points,” says Mihaela Rădulescu. “Is someone breathing down your neck if you have a spillover? Or, as a team, do you want predictability?” If focused on the latter, Mihaela believes story points can increase transparency about what is feasible to deliver within a sprint. “In my opinion, they are used for predictability, not for someone to ask why you said 30 and only delivered 25.”
Retrospectives: Stop doing, start doing, keep doing
In theory, the recurring retrospective meetings provide a forum to facilitate a shared understanding and drive process improvements. In practice, they often transform into rants. Some small changes get made quickly after such retrospectives, while more complex adjustments don’t tend to stick.
“If there’s an action that can be taken quickly, like removing a recurring meeting that we don’t find useful anymore, it’ll get done,” Tiberiu Grădinariu says. “But if it’s a longer-term change to the team’s way of working, from my experience so far, it’s hard to put this into practice.”
A scrum master sees things differently, though: “Rants sometimes bring up those little improvements that stop you from delivering more or feeling better while working as a developer,” Mihăiță Braeși, Levi9 Delivery Manager, says.
Codrin Băleanu points out the need to prioritize and simplify these reviews, making space for multiple viewpoints. “Everyone in my team needs to have those three opinions in a review: stop doing, start doing, and keep doing,” Baleanu says. The most votes surface the top priorities to tackle.
However, Tiberiu is taking a step back and ties everything to a key question: “Does the client actually complain, or is it just us?” Customer focus is directly related to the Agile Manifesto’s central goal of client satisfaction. Tiberiu argues that if the end result, no matter how unconventional, achieves that goal, the approach is worth considering. “As long as the client is happy,” he underlines once more, “always keep in mind customer focus.”
