Most development processes are just that – development processes – and gives other important aspects short shrift. I’m sure you’ve seen those diagrams where the description of the development process starts with the first iteration and ends with the last one (if it ends at all). But before the development starts, there’s a fair bit of prep work that needs to be done in a short timeframe. Later, there will be a need for maintenance and admin for what’s already been developed. Success Line puts the “pre” and the “post” on the chart, too. Full transparency is best, because it’s easier to optimize what you can see. It also visualizes the process of maintaining and developing the cooperation as a whole parallel task.
Read also: Building innovation with custom software development
QuickStart
The first, optional phase of Success Line – used when needed – is QuickStart. In essence, it resembles preliminary analysis and the objective is indeed similar – to gather all kinds of input about the client’s organization so that the initial solution can be proposed. QuickStart makes it possible to start even if the client doesn’t have a product manager to collate the information we ask for. A top gun analyst from Helmes does that part of the job. In an average of three intense days of work, the analyst will be responsible for getting 360-degree input from different specialists from different departments, mapping the existing systems, mining the relevant data and digging into any existing client research.
Solution design
In Solution design, the service designers and solution architects are joined by infrastructure engineers who help think through the hosting and availability issues, security and monitoring needs and system performance requirements. In other words, things that can’t easily be grafted onto a built system at a later date. The Helmes infrastructure engineers have experience with business-critical solutions hosting, handling the unexpected operational issues, and thus their input in pre-empting later incidents can save a huge amounts.
Kick-off
Other non-functional requirements get the same kind of very high-level scrutiny in the course of the Kick-off meeting. At Kick-off, we sign all participants in the project to a Working Agreement, in which all understandings on cooperation and the initial principles of cooperation are recorded. It is a living, evolving document we update based on how we learn and fit the puzzle together during the project.
Development
One of the most important ways that development is different from the “other guys” is that we don’t hold retrospectives only at the end of the iteration or about that specific iteration. At Helmes, retros are held at a reasonable interval and also address teamwork and cooperation with the client. Optimization is geared to making cooperation as smooth as possible so that any hindrances to maximum productivity are quickly eliminated. In other words, sometimes we slow down a little to take a good look at what we are doing in order to speed up afterwards.
Support after live
Support after live is the period after major releases where development and infra engineers are on stand-by, ready to resolve any unanticipated situations, answer urgent questions from the customer and third parties, and provide whatever customer guidance and support it takes to keep the system running smoothly. Often obstacles crop up precisely on the third-party side, so it’s important to be in contact with them and ensure they, too, are in a state of basic readiness for rapid intervention when needed.
Aftercare
Usually, software development process diagrams end with iteration n, or in extreme cases with a triumphant deploy/launch. Yet there’s a real need to think about how the application will work later on in the live environment. Success Line puts Aftercare on the map as a separate process/field. If it didn’t, a long-term partnership might suddenly see a decline in its actual capability to develop new functionality due to maintenance and support operations taking up development resource. Aftercare should be given separate consideration and preferably set up as an agreement, because parameters other than the ones for developing new solutions often come into play in this work: reaction times, readiness, problem solution times, monitoring needs, etc.
Why is the chart even necessary? It keeps important aspects (besides developing the new functionality itself) from being overlooked. And it also makes the process of working with us transparent and understandable for those new to development. With Success Line, there won’t be any surprise items and expenses that might appear to delay the project and inflate the budget.