There is a classic paper on modularization called "On the Criteria to be used in Decomposing Systems Into Modules." Briefly summarized, the criteria are to make a data oriented, not functionally oriented decomposition of your project, and to use metrics to judge the success by how few modules must be touched per enhancement.
C is a structured programming language and some key concepts include creating low coupling (by avoiding globals and using parameters) and high cohesion (by grouping closely related functions and data together).
For C, what you describe for separating the .h (declaration) from the .c (definition, also called implementation) is good. Some practical considerations arise with .c/.h files, but generally .h files should include very few global variables (i.e. externs) and prototypes for only those functions that will be used outside the .c.
There are many C programmers who talk don't use structured analysis or design. Best Practices once involved making a Structure diagram that broke the problem a program was designed to solve into a top-down functional decomposition, that was transformed into a tree of modules using a technique called transform analysis. This is no longer considered best practice, because data oriented and object oriented decomposition has proven itself superior. However, C programmers often find what they do is a tough fit for object oriented design because the language features don't line up.
Team Best Practices
This is the subject of entire books. Watts Humphrey wrote a technical report called "The Team Software Process" that is a classic and a free download. Skim over just pages 4-6, and 15 to get a really fast overview of what is important for the team and its leadership. Other parts of the document also tell you a lot about the expectations of planned methodologies in terms of documentation including productivity and quality measurement.
Your team may pick a life cycle model that is either planned (more traditional waterfall, spiral, or feature oriented development) or Agile (iterative/incremental or perhaps lean). Both will have many processes that overlap, although they might not be practiced exactly the same: documentation, source control, integrated tracking and planning with databases and chart editors, testing, and some kind of peer review.
If you think
We are uncovering better ways of developing
software by doing it and helping others do it.
you should consider what the Agile guys are saying because team process centered around Scrum or eXtreme Programming (XP), is later and reacts to what people felt didn't work before.