In the article “Why an MVP?” I described what an MVP is and what the development process looks like. This is based on the idea that there should be no assumptions without data to support them. The same holds true during the development process.
Rigid Methodologies
Before the advent of agile software development methodologies the usual practice was to acquire all requirements beforehand and plan for all eventualities that may arise during the development of the actual software product.
This method had its merits in manufacturing processes of physical products, where the cycle from inception of an idea to holding the artifact in hand is quite long and trial and error would be very expensive.
Example: Waterfall
An example for such a rigid process is the waterfall model: The client sits down with the development team and creates a document with all requirements before development begins. This allows for estimation and discussions. During development the client is not involved.
The usual steps are:
- System and software requirements are captured in a product requirement document.
- Analysis of the requirements result in models, schema and business rules
- Design of the resulting software architecture
- Implementation of the software
- Testing via systematic debugging
- Operations: installation, migration, support, and maintenance of complete systems
The waterfall model states that one should not move to the next phase unless its preceding phase is reviewed and verified.
The Agile Model
Agile models introduce the same ideas that we discussed in the “Why an MVP?” article. You might not know how the finished product should look like. So you want to be kept in the loop repeatedly during the development to adjust the direction of the development.
Thus, agile methodologies proclaim an incremental development model. Essentially the phases of the waterfall model are incorporated in a cyclic iteration in which you go through all the steps:
- Initial planning of the project
- Communication to refine software requirements
- Analysis of the requirements, incorporating new findings into the planning
- Design of the resulting software architecture for the upcoming iteration
- Implementation of the iteration’s milestone
- Integration of the iterations increment
Within this cycle step 2 to 5 are to be repeated until “finished”.
Iteration
An iteration is an interval of fixed length to work on the core values of the product. A successful iteration produces a working increment of the software product which moves you closer to your desired outcome.
Planning
The length of such an iteration depends on the size of your team and the speed of the development. The shorter the intervals, the larger the meeting overhead, since you would have to discuss upcoming and retrospective iterations more often. In the beginning it might be useful to have a shorter interval, to allow for quicker changes in direction. After a few iterations you can increase the interval length as your business goals should be more clear to the all team members.
Before an iteration begins, you would have to describe the tasks that should be done. These become part of your “backlog” from which we can choose a certain amount of tasks for upcoming iterations.
As described previously, each iteration should produce an increment that can be deployed to actual users, so you would have to prioritize tasks that can be done within an iteration. If you have large features that might not be doable within one iteration, try to split them up, giving the user a smaller version of the desired functionality. This way you are thinking in terms of “launchability” from the get-go.
When planning the upcoming iteration you sit with a developer and discuss which tasks can be done within the next iteration. As with every estimate, this is not to agree on strict outcome, but to find a shared understanding of what to expect in the end of the iteration.
This expectation should be described in a “definition of done”. For that we like to use the Gerkhin language, which is a “business readable, domain-specific language” that lets us describe software behaviour without detailing how that behaviour is implemented.
Integration & Testing
When a task is done the work should be integrated into a running environment. At first for testing purposes this might be a staging environment, where you can manually test the functionality of your software.
If the work does not meet the “definition of done”, you can give feedback for the developer, so she can adjust accordingly. If it does match the “definition of done” you can create a new task in the backlog, that describes your changes necessary in upcoming iterations.
It may happen, that you find bugs when testing. If you do, you create new tasks describing the issue. The description should provide details of the expected behaviour, the actual behaviour, the steps to reproduce the issue and the specific acceptance criteria that the behaviour violates. Usually you could reference a specific scenario from the feature definitions.
In the end of the iteration, when everything is tested and the work has been approved for the increment, the software can be deployed to the production environment.
TL;DR
To ensure the success of your project and to stay in budget, you should iterate towards your goals in managable steps. Working with a team that focusses on good practices and is able to adjust to your needs is essential.