The development process part 2!

Dear reader,

Yesterday I wrote about the top level of the product development process, today I am going to focus on the project execution model. This part is the core part of the product development process but I will not work without the business process.

The project execution model is divided in 3 parts as well.

1. The before execution phase


2. The execution phase


3. and the maintenance phase

In the before phase is where you decided what kind of product you would like to develop. Agile purist might say that that 1 and 2 should be one and that you can start with just a few user stories and from that build the product sprint by sprint. However I have yet to see any product being built like that. Even if you are very agile, product management need to have a vision for the product already from the start and product management probably have to have a business case and wanted delivery date etc. If not top management will not spend any money on the project. So most of the time you must have most of the framwork for the product given, a maximum budget and a delivery date even before your start any of the project execution. If we agree on this, then you need to do no 1 as a pre-study and possible a deeper design an system analysis (even if you are very agile) to be able to at least set an optimal system architecture, high level requirements estimates etc. When you have your top level requirements stack ranked and guesstimated the effort i.e. the product backlog (see my other blog post on how to do the stack ranking with for example focal point), you now have a good top down view of the overall project.

Now you have an high level time guesstimated and a wanted delivery date, a budget and a product backlog (i.e. your system requierments). Now it is time for the business decision on the top level business process to make a decision on the possible bright or dark future for the product. If it is a bright future it is time to start the execution phase (2) using for example an agile method like Scrum. I think Scrum is very good to use for the execution phase of most SW development projects (more indepth evaluation of Scrum and best practice in a later blog post).
In my opinion an agile project should only be agile in two parts or maybe only one (it depends on how much money you have :-). But normally you should only be agile on the requirements because the delivery date, the quality and resources /cost should or is almost always fixed. Now execute your project sprint by sprint to reach your targets.

If you have a very mature organization with a good test organization and test cases, daily builds etc. You might be mature enough to release your product after the last sprint, if not always plan the last sprint with new features as a beta release and try to learn how many/long you stabilization sprints should be.

I use this mix of a business and execution model since no one model often give you all what you need. This way of working is a mix of the waterfall model and the agile project execution model.

This is it for today…

Kind regards
Anders