Agile project management at eggs

How do we work in small and medium-sized projects?

Totally agile - even in smaller projects

At eggs unimedia, we are agile, which means, among other things, that we work together without hierarchies. Our project teams are put together according to the requirements of our customers and organise themselves. Depending on the scope of the project, we apply one or the other agile framework or combine their best elements.

This article focuses on small to medium-sized projects that run over a defined period of time. In these projects we work with a team of 2-4 colleagues. The roles and skillsets are composed according to the requirements. A project team usually consists of a tech lead and one person each for frontend and backend development.

Agile Frameworks

At eggs unimedia, we work with various agile frameworks. First and foremost, we listen to the wishes of our customers. We currently use Scrum, Kanban and SAFe. Especially in smaller projects, we use a combination of different agile elements. It is adapted to the respective project dynamics and is subject to an ongoing improvement process. In this way, we find the optimal way of working for the team.

Agile requirements workshop

At the beginning of the project, we clarify the requirements with our customers in one or more requirements workshops. The first focus is on the vision, i.e. the question: What is the biggest driver for this project? We talk about target groups, critical success factors and who the users (authors in AEM jargon) will be. We keep a close eye on these points during implementation in order to create the greatest added value from the project. Customer journeys are developed and corresponding personas are defined. In addition to these "soft" factors, we work out the technical requirements together, clarify interfaces and possible risk factors. Ideally, we create epics and stories in Jira directly from the requirements. These can be prioritised immediately or afterwards.

Jira Board

Agile Pricing – T&M

In almost every project, requirements change over time. This is "normal" and even wanted, especially in agile work. Therefore, from the point of view of agile project management, it makes a lot of sense to choose a contract on a T&M basis. This "call-off contingent" makes the project work very flexible. At the beginning, the general requirements are defined. On this basis, the effort is estimated and the initial budget is agreed. Unlike fixed-price agreements, the budget is not fixed to the requirements. The advantage is obvious: at the time when the first requirements or the RFI are created by a customer, the technology to be used is often still unknown. The first requirements are therefore still described in a "technology-neutral" way. The advantages and handling of the respective technology only come to the fore in the course of the project - and this is often when the best ideas emerge - and thus also new requirements.

With T&M, the requirements can be easily adapted, reprioritised or even deleted in the course of the project. Only expenses that have actually been incurred are billed. So if we have set a budget that is too high, it is not a disadvantage for our clients. The overestimated budget is either not billed or is available for the implementation of further requirements.

 

You can read more about this in the blog article by my colleague Tobias Gollinger

Communication is the key to success

From my point of view, the key point in agile work - regardless of the framework chosen - is communication. This includes both the exchange within the development team and the exchange between the development team and the client. Through regular coordination, all sides understand what is currently being done, what needs to be done next, where there are successes and difficulties. Questions from the development team can be clarified directly with the responsible person on the client's side without lengthy email ping-pong and, if possible, can be viewed directly on the example. Elements from the Scrum Framework have proven themselves for successful communication.


Daily or Weekly

We hold a daily meeting together with our contact person on the client side. This is a 15-minute meeting in the morning where all project participants are brought up to date and questions can be addressed. These are clarified by the persons involved directly or afterwards, possibly also with the involvement of other stakeholders. Depending on the project dynamics and requirements, a weekly exchange may make more sense instead of a daily meeting. We decide this together with the client.
 

Review

In addition to the daily exchange, a review usually takes place every two weeks. In this meeting, finished features and the current development status are presented. All stakeholders are invited to this meeting. This gives them the opportunity to give feedback directly and to clarify any questions they may have about the feedback.


Retro

Directly after the review date, a retro takes place within the development team. This is another Scrum element. The team discusses the period since the last review without involving the customer: They discuss what went well, what didn't go so well and what should be done better/differently in the next period. This involves looking at technical issues, organisation, communication flow and anything else that is on the team's mind. All issues around the project are openly expressed. The retro is a very important element in teamwork to get the opinion of all team members. The joint definition of improvement measures promotes cooperation, processes and thus also quality.

Retro

Project goal

In most projects, the first project goal is to implement a Minimum Viable Product (MVP). This is a fully functional version with minimal features. An MVP provides the ideal basis for quickly subjecting the developed application to a market test. In this way, we receive immediate feedback that is used for future further developments of the product.

Let's Go Agile

Curious now? We look forward to hearing from you!