• 21 Aug 2017
  • RE.A.L.

Agile software development

Agility in code requires agility in project management and that starts at the very beginning – with the initial briefing.

“Tell me what you want. What you really, really want.” 

We challenge the client's briefing. Because we don't just take it at face value – we dig deeper. What do you really want? And why?

Only then do we collaboratively define the big picture. Individual modules are not fully specified upfront but are refined over the course of the project. We deliver fast, often, and early. We work in prototypes, follow RE.A.L principles, and take a safe-to-fail approach.

Waste? We identify it and cut it to a minimum. We build the optimum—initially stripped of unnecessary features. 70%. Done.
This gives us clarity on how much time and budget remains for polishing and fine-tuning—and where it actually creates the most value. We document and communicate the current state. Then comes the fun part: refinement, optimization, and precision work.

Forming » Storming » Norming » Performing

This is the classic team development model by Bruce Tuckman – and interestingly, it maps remarkably well to agile software projects and the challenges they bring for project management.

1. Forming

The project begins with assembling the team. Internally and on the client side, skills and capacities are assessed, responsibilities assigned, and roles clearly defined.

Together with the client, we create a shared project vision, often in workshops. This is the phase of defining the True North—a common understanding of the goal, which might still be far off. At this point, it’s more about the what and the why than the how.

In line with our RE.A.L. principle, we carry out a raw estimation: we define modules but don’t yet specify them in detail. If timing and cost are fixed, then the scope must remain flexible.

2. Storming

The project gets going. All team members begin working on their tasks derived from the workshops. At this early stage, diverging work styles and expectations may surface—and need alignment.

Unlike traditional approaches, agile software projects start without exhaustive specifications or rigid cost calculations.
“No waste!” is the mantra—and one we all commit to.

Still, clients may wonder:
What exactly is the agency doing now? Will they act according to our vision? Was everything important discussed in the workshops?
Here, the challenge is to tolerate uncertainty. This is where agility—in the RE.A.L. sense—truly begins.

It pays off now if everyone invested in a solid shared vision early on. Based on that, user stories can now be defined.

Detailed task planning only happens just in time using a rolling wave approach—planning within sight. That means we don’t specify features scheduled six months from now based on uncertain assumptions. In the past, early comprehensive specs created the illusion of control, offering stakeholders premature “proof” of progress.

In companies with such traditional expectations, agile projects often trigger the need for cultural change. When successful, this creates space to leverage the real advantages of agile development.

Dialogue at eye level

A strong partnership mindset between agency and client is key. Continuous dialogue, transparent communication, and mutual trust are essential. Ongoing process optimization is part of agile—and should never be mistaken as a sign of failure.

4. Performing

This is where the groundwork pays off.

Each of the current four sitegeist teams of around 10 - 15 employees works autonomously and cross-functionally. The Kanban principle forms the framework for action and focuses on Flow. The agile project manager's tasks therefore include not only keeping an eye on economically measurable variables, but also ensuring that the software developers can work as consistently focused and efficiently as possible at Flow.

The requirement to implement the project as "lean" as possible is not only taken into account at the beginning of the project by avoiding "waste" in the form of KVAs and specifications.

Rather, it is about constantly questioning and sounding out the "as much as necessary, as little as possible". Here, all project participants are called upon to actively help shape the project with their skills.

This also includes, for example, maintaining an effective meeting culture:

  • Clear goal
  • Focus of all participants
  • variable participants
  • Time box

Documentation result and next step

In this phase of the project, the specification and realization of the individual modules takes place at sight. Here, too, lean ("lean" from the RE.A.L. principle) is applied by focusing on the development of the "module MVP".

The art of agile project management is not always to have all special curls implemented immediately and unconditionally. Quite the opposite: it is also possible to finish earlier, in an initially simple form.

The project manager also monitors the progress of the project and controls costs across all phases in agile project management. But how does this work without a specification sheet or requirements specification?
The close integration of the ticket system, time recording and prediction sheet (based on the module packages defined at the beginning) means that the key figures that are crucial to the success of the project are always monitored efficiently and visualized transparently.

The performing process takes place in several iterations until the final project completion - usually in the form of the online launch of a website or campaign.

Conclusion

If the highly efficient details of the RE.A.L.-concept are applied by all project participants in an agile software project, the result will be faster, cheaper and better.