The Point of Process - Part 1

A software development process was very real during my time in the defense industry, but basically not taught during my time in college. I could see mixed views from the open range of small businesses and development shops, depending where one worked. There is plenty of material out there too! Manifestos, guidelines, workshops and so on, all geared to learning and following a particular software process. And all this truly has made software development better, and allowed for better software.

If one did not have varied experiences, or there was not time to do extra reading, or was just getting starting in software, they might wonder, "what is the point of all this process?" Or if one was getting frustrated with a software process, because it was too much pointless work or the process never told them anything useful, they might wonder, "what is the point of all this process?" And some people just need to be reminded, because the point of a software process is not the process itself.

Software Process Answers Two Questions

Where is the software going?
When will it be ready?

That's it. Be it waterfall or agile or something else, it all boils down to these two questions.

Where is the software going? 

Software needs a goal. The goal could be planned months ahead or days ahead but there needs to be an end state. That could be a milestone with a defined set of features or requirements, or a rolling set of features as business needs change, and the process keeps everyone involved on track. Each person can state why they are doing the things they are doing (writing code, performing tests, etc) and, to a higher level, where those things fit into the entire software system.

When will it be ready?

Schedule is important. The software process tells everyone when something must be done. This helps the business guys plan sales demos and constrains the developers to stop tinkering. If the team cannot state when the software will be ready, chances are it will not be.

Who Asks the Questions

The process is for the software and the software is for the stakeholders. Only minimally is a stakeholder the developer. Sometimes it could be Tech Lead, Scrum Master, Program Manager or CTO. Indirectly it is the end-user. The stakeholder should be the business side of the house, and very often it's the person writing the check. The stakeholders are the ones asking the questions, and the answers to those two questions (from the dev team) is sometimes their only view into the software process.

Development is not the point. In the end, process is not the point either. Keep your stakeholders happy and meet their expectations, which can be done by answering two simple questions. You might use a software process to help answer those questions, too : )