[et_pb_section fb_built=”1″ _builder_version=”4.4.1″ background_color=”#fbfcfd” global_module=”1099″][et_pb_row column_structure=”1_2,1_2″ disabled_on=”on|on|off” _builder_version=”4.5.6″][et_pb_column type=”1_2″ _builder_version=”4.4.1″][et_pb_image src=”https:\/\/agilecoach.ee\/wp-content\/uploads\/2020\/01\/Merle-black-and-white-round-less-shiny-1.png” _builder_version=”4.4.1″ custom_margin=”-5%|||25%|false|false” custom_css_main_element=”-webkit-clip-path: circle(50% at 50% 50%);||clip-path: circle(50% at 50% 50%);||width: 75px;||height: 75px;”][\/et_pb_image][\/et_pb_column][et_pb_column type=”1_2″ _builder_version=”4.4.1″][et_pb_text _builder_version=”4.5.6″ text_font=”Source Sans Pro||||||||” text_text_color=”rgba(0,0,0,0.8)” custom_margin=”-3%|||-60%|false|false”]<\/p>\n
Merle Randlepp<\/p>\n
[\/et_pb_text][et_pb_text _builder_version=”4.5.6″ text_font=”Source Sans Pro||||||||” text_text_color=”rgba(0,0,0,0.44)” custom_margin=”-5%|||-60%|false|false”]<\/p>\n
Agile Coach<\/p>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row disabled_on=”off|off|on” _builder_version=”4.4.1″][et_pb_column type=”4_4″ _builder_version=”4.4.1″][et_pb_image src=”https:\/\/agilecoach.ee\/wp-content\/uploads\/2020\/01\/Merle-black-and-white-round-less-shiny-1.png” align=”center” _builder_version=”4.4.1″ custom_margin=”||||true|false” custom_css_main_element=”-webkit-clip-path: circle(50% at 50% 50%);||clip-path: circle(50% at 50% 50%);||width: 75px;||height: 75px;”][\/et_pb_image][et_pb_text _builder_version=”4.4.1″ text_font=”Source Sans Pro||||||||” text_text_color=”rgba(0,0,0,0.8)” text_orientation=”center” custom_margin=”-3%||||false|false”]<\/p>\n
Merle Randlepp<\/p>\n
[\/et_pb_text][et_pb_text _builder_version=”4.4.1″ text_font=”Source Sans Pro||||||||” text_text_color=”rgba(0,0,0,0.44)” text_orientation=”center” custom_margin=”-3%||||false|false”]<\/p>\n
Agile Coach<\/p>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.4.1″][et_pb_column type=”4_4″ _builder_version=”4.4.1″][et_pb_post_title author=”off” comments=”off” featured_image=”off” _builder_version=”4.4.1″ title_font=”Source Sans Pro|700|||||||” title_text_align=”center” title_text_color=”rgba(0,0,0,0.8)” title_font_size=”47px” text_orientation=”center” title_font_size_tablet=”40px” title_font_size_phone=”35px” title_font_size_last_edited=”on|desktop”][\/et_pb_post_title][et_pb_text _builder_version=”4.7.4″ _module_preset=”default” text_font=”Source Sans Pro||||||||” text_font_size=”15px” text_line_height=”1em” text_orientation=”right” custom_margin=”|||10%|false|false”]
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. <\/p>\n
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. <\/p>\n
Have you ever been in a situation where everything will start to slide downhill relatively soon from here?<\/strong> 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. <\/p>\n [\/et_pb_text][et_pb_image src=”https:\/\/agilecoach.ee\/wp-content\/uploads\/2020\/12\/kukkumine-veesuuskadel.jpg” alt=”Unexpected train” title_text=”Falling-on water skis” align=”center” _builder_version=”4.7.4″ _module_preset=”default”][\/et_pb_image][et_pb_text _builder_version=”4.8.2″ _module_preset=”96fa8149-2d7e-4fe7-bc52-734658dc4791″]<\/p>\n 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.<\/strong> In essence, both parties assume that they have common understandings, customs and work habits in absolutely everything. How likely is that? <\/p>\n 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. <\/p>\n 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. <\/strong> <\/span><\/p>\n<\/blockquote>\n <\/strong><\/p>\n [\/et_pb_text][et_pb_image src=”https:\/\/agilecoach.ee\/wp-content\/uploads\/2020\/12\/legomeeste-kokkulepe.jpg” alt=”Dilbert Cartoon” title_text=”Contract with the Lego Workers” _builder_version=”4.7.4″ _module_preset=”default”][\/et_pb_image][et_pb_text _builder_version=”4.8.2″ _module_preset=”96fa8149-2d7e-4fe7-bc52-734658dc4791″]<\/p>\n The rules of procedure will be agreed upon at the beginning of the project and will apply to all project participants during the project. 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.<\/strong> <\/p>\n 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.<\/p>\n 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:<\/a> “The most efficient and effective way to share information in a development team is a face-to-face conversation.” <\/p>\nWhat are the rules of procedure for a software project?<\/h2>\n
\n
How to conclude the rules of procedure of a project?<\/h2>\n
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. <\/p>\n