Rules-of-engagement-blog

Tech lead thoughts: rules of engagement

This article introduces a concept called “rules of engagement”. The rules of engagement define how we work together in a project. They are particularly important in an agile environment, which by definition is based on interaction and collaboration. By defining the scope of the project, we create a baseline for cooperation that can be helpful when our agility is about to turn into chaos.

At the start of a new project, there are many activities going on: concept, analysis, design and architecture planning. It can be bewildering for both developers and other team members. Perhaps the potential confusion is especially large in an agile environment, where there is likely to be little written documentation and verbal agreements that are not known to everyone. I have seen many developers struggling to work effectively due to lack of information about expectations and objectives.

For those who feel lost when joining a project, the rules of engagement may come to the rescue. I would like to propose an exercise to ease the initial phase. Look at the topics listed below – do you know the answer to the questions? If not, make sure that you ask your PM, tech lead or whoever is responsible for the project.

Project status/objectives

  • What will be delivered by whom?
  • Who is on the team (in what role)?
  • What are the business objectives (who is the customer, why do we do this project)?
  • Do we have internal goals (time vs quality)?
  • What is the schedule (deadline, milestones)?
  • What are the known risks?

Scope definition

  • Where is the WBS/backlog?
  • How is the scope specified (user stories with acceptance criteria)?
  • Do we have any documentation (where can we find it)?
  • How do we estimate tasks (internal or external estimate)?

Development routines

  • How is the QA process defined?
  • Is “Definition of Done” established?
  • What is the deployment process and frequency of deliverables (iterations)?
  • Are there any other routines (TDD, pair programming)?
  • What tools will we use (JIRA? Confluence?)
  • How do we report progress?

Communication and customer engagement

  • How do we communicate in the team (meetings, routines)?
  • Is a customer representative involved in our daily work?
  • Who communicates with the customer (are developers supposed to contact the customer directly)?

These are just a few suggestions – feel free to add more! The more knowledge you (and the team) collect upfront, the higher is the chance to avoid misunderstanding and limit the number of new gray hairs on your head.

Published