What Should You Pay Attention to in Contract Design for Development Projects?

Generally, the contractor will advocate for a service contract. But wait: I’m missing the complete legal certainty that I’ll get what I want! That may be true. But while the work contract assures you what you want, the service contract allows you to get what you need. The work contract, once concluded, delivers exactly what was specified. This requires a true masterpiece of specification. That’s exactly what we wanted to avoid. Instead of writing a specification novel for three months, let’s rather create the first prototype. We benefit much more from this:

I know whether the contractor is capable of implementing what I’m planning.

A work contract alone doesn’t guarantee me that the contractor can deliver at all or in the desired quality. Certainly tempting for people who like to spend their time in court, but a successful project looks different.

Three Months of Development Equals Three Months of Experience.

Experience that can be put into optimizing the plan. I can’t think through my software so precisely that no changes will occur. What’s often forgotten is that the software is operated by many users in different roles. To think that you can fully understand your colleagues’ jobs and deliver them the optimal tool is a typical case of overestimation.

Avoidance of Communication Mishaps.

Communication is one of the most complex processes in our lives, measured by the simplicity of communicating and the probability of misunderstanding. So why risk endangering a project by misinterpreting a written specification? Our perception is manipulated by various factors such as past, upbringing, and education. In dialogue, I can immediately eliminate such misunderstandings and thus save time and money.

So if you encounter a contractor who presents you with a work contract, you should be rather skeptical yourself. Most likely, they suffer from exactly the mentioned overestimation and develop not agile, but ‘agile’.
Agile Development Works with a Trust Advance, While Traditional Approaches Work More with Questionable Promises.

Which Meetings Should You Attend?

Once the service contract is filed away, the work begins. For the developers and for you. Because agile software development means intensive exchange. The contractor working with SCRUM will expect you to participate in the Sprint Review and Sprint Planning. Depending on the team size, this appointment can take up to a day.
Sprint Review and Sprint Planning address you, the customers, and are your opportunity to intervene in the development process. The development team asks for your opinion on the results of the last sprint (product increment) and asks what you need next.

The Sprint Review is the acceptance of the work completed in the last sprint. The team presents the implemented functionalities to you here. This gives you the opportunity to evaluate function and quality. Any problems are noted and can be fixed in the upcoming sprint or postponed. To counteract the previously mentioned overestimation, I advise you to bring along those from your company who will work most with the demonstrated features later. It will definitely be worth it, because the knowledge of the person who deals with the problem daily can turn a good end product into a very good one.

The Sprint Planning serves to plan the next sprint. A good Product Owner will have already sorted the user stories by priority together with you. The development team has previously estimated the individual efforts with the Product Owner in a grooming or refinement meeting. It’s important to know who determines how much will be done in the next sprint: The team. After all, it’s also the team that has to manage the workload in the end. With proper preparation, Sprint Planning usually takes much less time than the Sprint Review.

Sprint Review and Sprint Planning can thus be seen as small work contracts that are made between the development team and the client every sprint. They ensure that the developers don’t work aimlessly, but follow an extremely precise plan. Accordingly, active participation is important. A good SCRUM Master will certainly point this out to you.

Communication as an Important Factor in the Development Process

In addition to Sprint Review and Sprint Planning, constant communication on an equal footing is essential. This means: Reserve time when you are available for the development team. If a Product Owner has to wait a week for answers, he won’t have enough time to prepare for the next sprint.
Especially at the beginning, you will probably be bombarded with questions. Accordingly, it’s important to build a circle of people who can answer without much thought. This is where the issue of overestimation comes into play again. Questions are answered by the people who will have to live with the answer later. Usually, these are the people who can answer the question the quickest.
Frequent communication is good, communication on an equal footing is better. You won’t get far with dominant behavior. You need the developers to implement your ideas. The developers need you to work out requirements. There’s no place for hierarchy here. You don’t tell the developers what to do, they tell you what they need. Nevertheless, ‘the customer is king’ still applies. So the developers won’t suddenly develop their own plan.

Why Early Productive Use of the Software is Worthwhile

Let’s assume: The service contract is signed, you participate in Sprint Review and Sprint Planning, and there is lively communication. By doing so, you have taken all measures that help the team gain momentum. Surely, you will be asked for one or two extras. I’ll now elegantly count that as part of the communication point. However, there’s one last thing I want to draw attention to. Put your software into productive use as early as possible. By doing so, you check two things.

The Team Implements the Most Important Features First.

The goal is to quickly implement the central use cases without getting lost in details. If your software still can’t map the simplest use case after months of development, then something is wrong.

The Implemented Features are Practical.

Sprint Review and tests already contribute significantly to quality improvement. However, features are tested, not scenarios. Practicality is not checked in staged scenarios, but live. The search, performant on little data, is far too slow with real data. This animation, still so nice to look at in the test, is annoying and costs time. All points that unfortunately are not as visible in a staged test as in daily use.

We’re not building a new Mars rover here, where a real practical test would indeed be quite difficult. We often just fear presenting unfinished software. Colleagues are certainly initially irritated about why they’re being presented with something incomplete. And again, communication is the key: ‘We’re currently having software developed for X, Y, Z, and we want the software to optimally support you in the end. X is already functioning, Y and Z are not yet. Since you’re very knowledgeable in this area, I’d like you to complete scenario X with this new software and give me feedback on what works well and what doesn’t.’ The colleague feels involved in the process, valuable as a feedback provider, and has assurance that the software is meant to support, not replace them. From now on, they are significantly responsible for the success of the project. There won’t be any subsequent ‘But this doesn’t work at all.’

Conclusion

Yes, you as customers have quite a bit to do. But that’s precisely the difference from classic approaches. Instead of grappling with abstract requirements and complex contracts, we prefer to use your time to create actual added value.