Project Managment

AGILE Methodology

Our project management is inspired by the AGILE method. The AGILE method as described at the outset had 4 main points. However, too often it is poorly applied or poorly suited to the management style of the company. Moreover, in certain cases the AGILE method has become a restrictive religion and quite simply suffocating. One of the very founders of the Manifesto 14 years ago wrote a manifesto on the failure of the AGILE method.

People and interactions must take priority over processes and tools.

Too often project managers use a platform or process when it does not suit the project or the management constraints of the company.

What happens when, in the middle of a sprint, you realize that an important part has not been ordered? Delays. It doesn't matter if you are using Jira or Asana you will have a deadline.

The ideal is to adapt the processes according to the project and the individuals and not the other way around. It should always be remembered that the individuals selected by your company are competent and honest. We must then give them as much freedom as possible. In some cases an Excel sheet may be fine, in others not. However, they must be given the freedom to choose what works best.

Large companies are often suffocated by tools that are universally used in all projects. The synergy savings are then counterbalanced by efficiency losses in project development.

Favor functional software over documentation

In the case of pure software development, documentation can become a nightmare and a monumental waste of time. A good coder will make his code easy to understand and require little or no additional documentation. They say the code isself-document. The idea of ​​the AGILE method was not to exclude all documentation. In some cases, it is necessary and insufficient. In other cases, it is unnecessary. It has to add value to the product in the short or long term.

However, some have jumped at the opportunity to dump all documentation of their project with the resulting adverse long-term effects. Others, on the contrary, we decide to adopt the AGILE method, but we kept the habit of generating impressive quantities of documents that do not add value to the product or even to the project.

Once again, you have to adapt to the realities of the current project. For example, a project requiring special certifications like SIL, will require extensive documentation while simple software will have very little.

Collaboration with clients before contract negotiation

The only constant in a project is change. Again, you have to adapt. Both parties can decide to hang on to the terms of the original contract or to adapt.

These changes should be seen as opportunities rather than pitfalls. Opportunities always lead to innovation and a better end product.

Respond to change rather than follow a plan

Again, the only constant in a project is change. Unfortunately, it often happens that teams blindly follow a plan established at the start of a project without ever questioning it. Projects are dynamic, plans must be too. This often leads employees to the brink of burnout. They work under pressure, under increasing stress as the project derails.

To be able to change a plan during the project, it is necessary that the management of the company is also AGILE. Budgets (finance), deadlines (marketing), requirements (sales) must also be questioned as the project evolves.

Codotek Method

We adapt to the business and the project! Simple! No software imposed, no special method. We use standard methods like Gantts, WBS, and Sprints your way, depending on the project.

The four foundations of the AGILE method correct several flaws in the method Waterfall by adding the key concept of adaptation to change.

WBS + Gantt

A WBS (work breakdown structure) is carried out in parallel with a Gantt chart. This allows you to have an overview of the project. In addition, the visibility of the project is greater with these methods than with a sprint. Combining the two (WBS + Gantt) allows you to see the interactions. Thus, we avoid forgetting the tasks linking the disciplines.

We adapt. A pure software project won't need the same detail or time visibility as a project with hardware. For example, a lead time 4 months on a critical part requires more than two weeks of visibility.

Gantt + Sprints

Once the high level Gantt has been completed, it is the responsibility of individuals to prepare for their sprints. To do this, they use the Gantt and add tasks to it. Often it is the project manager who does this work. However, only the person who will be doing the work can assess the time and interactions required.

Again, we adapt. Some teams use one person to do it, others do it as a team. In the end, the chosen method must bring the greatest value to the project and to the product.

In closing, you will understand that the project management method we use is hybrid. We use both the positive points of the AGILE method and those of the Waterfall method. It takes good judgment and knowing how to use the right tools at the right time.