In a previous blog post, I described my values to better understand me and my motivation. Before discussing how AI changed software engineering in my team, I first want to describe the environment we operated in. This context is crucial for understanding why and how we transitioned.

In a nutshell, our engineering process was highly structured, collaborative, and optimized for predictable delivery quality. Those characteristics were strengths for traditional software development. But they also created friction once we started experimenting with AI-enabled engineering practices.

Team Setup

We are an engineering team consisting of one Product Owner, one Team Lead (that’s me!), and five other engineers.¹ There’s one engineering manager responsible for me and my team. I’m the proxy for the manager, but he’s also approachable by every team member.

In terms of engineering skills and domain knowledge, my team was one of the more senior teams in our stream with two senior engineers and three regular engineers. From a mindset perspective, I would describe my team as open and curious, open to trying new ideas and experimenting with different approaches.

flowchart TD
    PO[Product Owner]
    EM[Engineering Manager]
    TL[Team Lead]
    E1[Senior Engineer]
    E2[Senior Engineer]
    E3[Engineer]
    E4[Engineer]
    E5[Engineer]
%% same level leadership
    PO --- TL
%% engineering hierarchy
    EM --> TL
    TL --> E1
    TL --> E2
    TL --> E3
    TL --> E4
    TL --> E5

Way of Working

Our working mode is inspired by both Scrum and Kanban. We don’t work in fixed sprints. We have a backlog of items, while operating within a broader project setup with milestones and releases. We adopted several agile practices from Scrum, such as Daily Scrum, Refinements & Plannings, and also every other week Stakeholder Reviews and Retros.

We follow an iterative and incremental process of implementing and releasing customer features, described in user stories. I depicted the whole sequence of actions below, but I’ll focus only on explaining the Refinement, Planning and Implementation phase for now.

flowchart TD
    A[Requirements]
    B[Refinement]
    C[Planning]
    D[Implementation]
    E[Release & Maintenance]
    A --> B
    B --> C
    C --> D
    D --> E

---

Refinements

In a typical cycle, we had several refinements, where our Product Owner presented user stories to the whole team. The team then asks questions and focuses on understanding the business problem correctly, that needs to be solved. Typically, we discussed a user story two times, before estimating it and move the story on to the next phase.

Refinements are crucial, because in general this is the first touch point for engineers with a user story. It was the right moment to provide early feedback and clarify ambiguous acceptance criteria.

Plannings

Once user stories are refined, they are ready for planning. I need to describe this phase more in detail, because I think the kind of planning that we did was unique to the team.

The approach

Typically for plannings, the goal was to achieve a shared understanding among all engineers of how a solution should be built. The outcome of this process is a set of small, incremental tasks the whole team can work on.

We had a copy of our architecture depicted on a Miro board and marked collaboratively components affected by the planned changes. In the end, all marked components are translated into subtasks, that a subteam could later work on. During planning, we also considered so-called cross-cutting concerns, such as logging, monitoring, documentation, legal implications, etc.

After the planning had happened, the entire team started working on the story. Back then we had the (soft) rule to only work on a single story together as a team, if possible. In order to avoid chaos, we typically started with a mob programming session first. In this session, the only goal was to align on common interfaces and method stubs, so that people can work independently on the implementation.

For example, when a new service needs to be introduced (and we decided on the service in the planning session), we created an empty signature with all needed parameters and return type. This ensured that both the team implementing the service and the team implementing the caller (for example a REST controller) could work independently while sharing a well-defined interface contract.

Pros and Cons

This style of planning definitely had its pros and cons. First, it was mainly shaped and introduced by very structured engineers from a consultancy. It was established in an environment, when the team consisted of 10+ engineers and all engineers needed to be utilized efficiently.

The advantages were a very structured process, always achieving the same quality of outcome. You wouldn’t simply forget anything, because every single detail was decided in the planning. The disadvantages were the rigid process, allowing little flexibility, the time spent for that planning and also the very detailed, small and independent tasks. This even led to the unusual situation that even the tiniest bits & pieces had a very high test coverage.

Structure over Flexibility

Our planning process was very structured and rigid. This helped us to create high quality results in predictable timeframes. In contrast, agentic engineering workflows tend to favor rapid iteration and exploration, instead of the first named attributes.

---

Implementation

For implementation, we used the very detailed subtasks and worked in pairs together. The subtasks were designed in such a way, that they were highly parallelizable.

---

Conclusion

Our team had a solid and proven engineering process that was very rigid and did not allow much flexibility. This led to high quality results in predictable pace. As already stated above, in agentic engineering you would rather focus on exploration and fast iterations, because AI-assisted workflows introduce far more variability into implementation, making rapid feedback and iteration more important than exhaustive upfront planning.

In one of the next episodes, I’ll share process adjustments that we made in order to be more AI ready.

Footnotes

1. We’re now only four other engineers, because one engineer resigned. ↩

---