Many companies or departments developing software solutions face the challenge of preparing a good and reliable implementation plan for new functionality. The problem becomes more serious the bigger and more complicated the feature to implement is. In this article I would like to show you how to make a good plan, how to prepare for it, what communication between software engineers and project management should look like and finally how to deliver big features without major failures.

Overview

During my career as a software engineer I have worked on many features, many of them I have led myself. I’ve seen large features balancing on the brink of disaster; when initial plans and estimates didn’t reflect reality. I have seen software developers trying to salvage the situation by doing massive overtime and faces of angry and desperate managers who didn’t know what else to do. I have also seen features that, despite their huge size, were implemented as expected, with assumed quality, and finished even before the final deadline.

What mainly differentiated those situations was that some features were well planned and others were not.

What is a good plan, and why do you need it?

A large part of a software engineer’s work is feature work (at least it should be). Feature work is quite a wide topic, but for me, the most interesting and important part of it is preparing an implementation plan. A plan accurate and understandable enough to be used not only by author, not only by other software developers, but also by other people involved in the feature, like for example project management. A good plan should be a kind of roadmap of what will happen and when in the nearest future.

The plan must be ready before any implementation starts. Features without proper design usually end with many unexpected tasks in the backlog, which dramatically increases their original estimate and finally leads to poor code quality, due to workarounds, that have been made to speed up the implementation.

Worth mentioning here is that delays caused by software developers usually affect a broad group of people. For example testers cannot start their work without an already working feature or at least part of it. Thus, one delay causes many others.

To create a good plan, certain conditions must be met.

Gather knowledge. Determine requirements

Each feature is a set of requirements that our program should meet. Good understating of the feature and its assumptions is a key to success. Software developer must be sure what should be done and any unclear matters or unknowns should be resolved as soon as possible. Problems left for later will be even harder to resolve during already ongoing implementation, especially in advanced phase. Some unexplained issues, clarified too late, can completely change the design of the feature, which is why it is so important to resolve them immediately.

One of the first things you should do is to gather complete knowledge about the feature: materials, specification, requirements, use cases, just everything which will allow you to determine the scope of the feature and potential set of OK and NOK scenarios. Not every scenario will be already visible, but the basic set must be defined.

But what if the specification has poor quality, materials are very limited, requirements unclear and use cases don’t even exist? It simply means that someone responsible for that forgot to finish his work. It happens, but your job here is to contact him/them and try to collect all data and information you need because your plan and your estimates will be your responsibility. If, for some reason, it is impossible to determine all requirements for the feature, then you should include such information in your plan, and estimates should be relatively higher. People from project management should know that the feature implementation will be risky, due to deficiencies in specification and provided materials.

Analyse the code. Define the scope of changes. Plan refactoring

Check the repository, and check what areas will be affected by the feature. Try to determine what kind of new classes and functions will be needed, how to connect them with existing code, what kind of internal and external interfaces must be defined and finally check what should be refactored (definitely something should be).

After such deep analysis, putting all this together, choose the best strategy to solve all problematic matters; it is a crucial moment, popular design patterns will certainly prove helpful at this stage. Ask other team members for review, additional comments may be extremely helpful, or even completely overturn your proposal. It is important before you start working on a more detailed plan. No one needs a super detailed plan that was finally rejected; only waste of time.

When draft has been accepted and overall concept has been well received, you can go to next step.

Go into details

The level of detail included in your plan should be high, but how high largely depends on the experience of the people who will be working with you. If you already know that at this stage, well, you know what details to include, if not, try to include as many details as possible. A well-developed plan at the beginning means fewer questions and ambiguities during the actual implementation.

It is not enough to simply describe the functionalities that our program must have, every good design should have all new classes, functions and interfaces named and described. Design should specify the location for these new objects in the repository. If the feature requires changes in existing code, refactoring is necessary, the plan should indicate the places that need to be changed and what will result from these changes. If the feature introduces a lot of new objects and dependencies or radically changes the current flow of execution, it is worth thinking about creating an appropriate UML diagram. Sometimes simple picture tells more than thousands of words.

Split big plan into small tasks

When the whole plan is ready and if you haven’t done it already, split it into small tasks. In my opinion, the task should not be longer than 40 h, which is one week of software developer work. When you estimate the task don’t forget about the review and delivery, it also takes some time. Remember that a good estimate helps you first and foremost, so that later you or someone from your team will have enough time to complete the task without pressure. Ask for a review; something may still be missing, maybe you are wrong about some things or perhaps the detailed version has shed new light on the design that still needs to be improved. After all, you should end up with feature split into small tasks that can be moved directly to the project management platform of your company, like Jira.

Create a document with your plan

It depends on you and your company where such document will be created, just find a good place where others can review your plan and where you can receive and respond to the comments. It can be a page on company Confluence, shared OneNote or anything dedicated for such things.

Below you can find chapters that I include in my documents:

1. Introduction – short description introducing the planned changes in the feature.
2. Preconditions – any dependencies that must be met before. Things without which the feature cannot be started or will not work.
3. References – links to all materials, pages, specification, mails on which the plan was based.
4. Tasks – all tasks required to finish the feature:
   

• Order of tasks should be aligned to the actual order of work. From the task title, reader should be able to find dependencies between tasks and tell which ones can be done in parallel. You can use some marks or numbers to specify the order, example:
  
  – Task1 [1]
  – Task2 [1] // first and second task can be done in parallel
  – Task3 [2] // third task should be started after tasks with number [1]

• Add priorities if needed.

• Task should describe the changes and point to the places in the code.

• If task implements some requirement, then link to such requirement should be added

• Estimate should cover not only the work in code, but also time for review and delivery
• Tasks with big estimates should be split in to smaller ones
  
  
  5. Open Items – things that need to be clarified, potential risks. This chapter should be short! 

DFMEA

I don’t want to elaborate on the DFMEA (Design Failure Mode and Effects Analysis) process, but I do want to point out that it is worth using it. Many overlooked issues in your plan may came out. If you don’t know what DFMEA is, you should definitely look it up.

Presentation

It is a good practice to present your plan to the entire team. It allows them to familiarize with the upcoming feature but also gives them an additional opportunity to evaluate the plan and provide some other findings.

Implementation, review and delivery

Based on the order of tasks described in the plan, developers are starting their work on it. Any unclear issues regarding feature should be explained by Feature Leader (role is described later). Any unexpected additional work, which may significantly affect the design or task estimate, should be discussed with Feature Leader. Sometimes such things end up with a small redesign of the original plan. Essential is synchronization between developers, daily is a must. During daily meeting developers can easily notice if their work will not be conflicting or if two developers are not trying to implement the same thing. Other developers should review all finished tasks before delivery. If there is any disagreement between the developer and the reviewer, Feature Leader can be asked to help in that matter.

Be a Feature Leader

I think that each “big” feature should have a leader. There is nothing worse than a feature that no software developer wants to take responsibility for. It is especially important in the communication between the development team and the people from project management.

Below I have listed responsibilities that Feature Leader should take on in my opinion:

• Preparation of plan 
• Presentation of plan to the whole team 
• Fixing findings after review (in plan) 

• Creation of tasks with estimates (should be consulted with team) 
• Participation in feature related meetings 
• Helping during team planning to properly distribute tasks and explain to them if something is not clear 
• Helping during feature implementation if something needs to be clarified or plan must be updated.

Many of above point can be done with or by other team members, the point is that there should always be someone who will take care of it.

Software Engineers vs Project Management

Software engineers are professionals who know how to do their job best. People from project management are also professionals who know how to do their job best. The problem is that these two groups have a different job to do, and yet they have to get along. Software engineers have their goals, like properly designed and implemented feature with desired quality. Project managers have different goals, like guaranteeing the completion of the feature before deadline. The idea is to find the solution in which both groups will be satisfied. A compromise is needed, and below is one example of such compromise: 

PM: Why overall estimate for this feature is so big? 

Dev: Because under this feature we have a lot of work to do. 

PM: Estimate is way too big, you should reduce it from 1000h to 500h, feature must be ready within one month, max one and a half. 

Dev: It is impossible, feature will take 1000h. 

PM: How many developments will work on it? 

Dev: Four, but not all the time, only during some stages of implementation. 

PM: What if I will give you four more? 

Dev: It will not help. Between tasks are clear dependencies and some tasks must wait for the completion of others. 

PM: Ok, but I see in your plan a lot of tasks with refactoring, maybe we can skip some of them. 

Dev: No, the whole plan forms a unified whole. Many tasks can be started only after refactoring, otherwise these tasks will have to be redefined. The quality of the feature will drop. 

PM: I can agree on lower quality 

Dev: What about “quality first” in our company? 

PM: Ok, you can improve quality later, but I need working feature faster. 

Dev: Ok, I have one idea. I can split this feature into two phases. First phase will have only necessary refactoring tasks. Second will have everything that was left out of the first phase. 

PM: Ok, it sounds good 

Dev: Yes, but I need an official mail from you that you agree on such solution and that second phase will be immediately started after the first one. Otherwise, I cannot agree.  

PM: Ok ok, I will send such mail. 

Dev: Ok, I will change current plan to be divided into two phases. 

Both sides are happy, developer will have an opportunity to finish feature with proper quality and on the other hand project manager will receive a working feature faster. 

That’s it, I hope you found this article helpful. For some, it probably won’t be anything new, since they already work in a similar way, but for others, it may be a hint on how to work on features so that they don’t end in disaster.