Merle Randlepp
Agile Coach
Merle Randlepp
Agile Coach
Rules of procedure for an agile software project. Sample Rules of Procedure [2020]
The rules of procedure of a software project are an important part of starting cooperation with a new external partner, which unfortunately is often not discussed and concluded. Yet a lot depends on this agreement, because none of us is a telepath.
You have carried out a software development procurement, the winner has been selected and you are looking forward to working with a new external partner. You will agree on the first opening meeting, where you will get to know each other, talk about the goals of the project, your expectations, etc. The atmosphere is energetic, full of faith and hope that this will be a great and successful project.
Have you ever been in a situation where everything will start to slide downhill relatively soon from here? Or even worse, the developer works quietly and says that the work is in full swing and only a little before the deadline does the customer find out the shocking fact that in reality, the project is not even halfway through. In order for a software project to be carried out properly and successfully, faith and hope alone are not enough.
What are the rules of procedure for a software project?
The idea of the rules of procedure is to agree on how exactly the cooperation will take place, and if this agreement is not discussed and concluded, then only different assumptions remain in the minds of different people. In essence, both parties assume that they have common understandings, customs and work habits in absolutely everything. How likely is that?
When conducting software audits, I have seen that the main reason for project failure is the low quality of the work process. None of the failed projects had entered into the rules of procedure of the software project, let alone compliance with them.
The purpose of the rules of procedure of a software project is to agree on the principles of project cooperation and quality requirements to ensure the success of the project. It is an important part of quality management in software development.
How to conclude the rules of procedure of a project?
The rules of procedure will be agreed upon at the beginning of the project and will apply to all project participants during the project.
The first to propose the rules of procedure should be the developer, because the client is usually ready to adapt to the developer’s working methods. An exception to this is the public sector IT competence centres (RIK, SMIT, RMIT, TEHIK, etc.), who already include the requirements of their rules of procedure in the terms and conditions of public procurement. However, many public and private sector clients do not do this and trust the developer’s competence here. Fortunately, it can go well, but most of the time it doesn’t.
I am not at all in favor of unilateral imposition of rules of procedure by a large IT client, especially if it is deeply bureaucratic. On the contrary, the Rules of Procedure should be a minimalist agreement that suits both parties well. Regardless of whose initiative it is concluded , it is important that it is also possible to follow it in everyday life and that it is understandable to everyone and, if necessary, can be found quickly.
If neither the development company nor the client has the necessary document template, then here I will share my own example and give you some examples of more formal versions in the public sector.
The sample “Rules of procedure for an agile software project” below is made in the format of slides to make it more convenient to review and discuss it together at the project kick-off meeting. This supports the principle of agile thinking well: “The most efficient and effective way to share information in a development team is a face-to-face conversation.”
The sample is based on the Scrum development framework, but it can easily be adapted to your own needs or for Kanban projects, for example.
The process of concluding the Rules of Procedure must be simple and fast, as it must be concluded within the first weeks of the project. At the opening meeting of the project, common principles are discussed, the executing party introduces the changes and the contracting authority approves them. Both sides sign. The document must then be made quickly and easily accessible to the team. From time to time, it is necessary to check whether the rules of procedure are actually being followed and, if necessary, to make changes. In general, however, changes are rarely made.
Sample rules of procedure for software projects
Rules of procedure for an agile software project. Dec 2020. Agile Coach Merle Randlepp
DOWNLOAD EDITABLE BASE:
This document has been created as a model and has been prepared based on my personal experience. Use it as a guide and compile the end result based on your own needs.
If the sample in the form of the slides above seems too thin to you, here are some more formal examples:
- State IT and Private Sector Working Group: Standard Software Development Agreement, Version 1.0 (published 20.03.2015) – Rules of procedure
https://itpraktikud.eesti.ee/dokuwiki/doku.php?id=itari:toogrupid:erasektor:start - IT management of Äripäev Infovara: Annex 2 “Sample Rules of Procedure of the Project” (for a fee)
https://teabevara.ee/et/it-juhtimine/peatukid
Note: There are several different terms for the Rules of Procedure: “Software Development Procedure”, “Development Project Rules of Procedure”, “Information Systems Development Procedure”, etc. I use the term “rules of procedure for a software project”, which seems to be the most catchy and logical.
I am grateful for the feedback and comments!
Related topics
IT Manager Metrics: Framework + Lead Time vs Cycle Time (1/3)
A clear framework for measuring the IT team and core speed metrics from a single page: what is the difference between Lead Time and Cycle Time, how to set a start-end rule, and when to use each.
What is the RICE model in product development?
In product development, we never have enough time or resources to implement all desired initiatives. Product owners constantly evaluate which developments to pursue and which to postpone, and making the right decisions is far from easy. The RICE model helps us make faster and more accurate decisions when prioritizing tasks.
The 8 Biggest Mistakes of a Product Owner
The role of the Product Owner is the most important role in a software development team. This role is far from easy, the area of responsibility is large and varied, the workload is usually as well, and so it may happen that “the seams start to burst” somewhere. I have compiled eight of the most common mistakes made by product owners that have the greatest impact in product development.
Every new contact is an opportunity for new and exciting collaboration - write or call me, and let's discuss how I can help you.
The first consultation and proposal are always free.
