Software as a Journey – the quest for good software

Let’s be honest: software development is hard.

Project reality confirms it. According to Chaos Report by The Standish Group International Inc. – the most reliable project effectiveness study – only one in five IT projects is completed on time and within the planned budget and scope. The rest either fail, or stumble across difficulties and exceed limits.

Why is that? Can you change it and increase your chances of success?

We believe you can, and that project success depends on the approach to its implementation and the methods and tools which support it. We perceive the process of building dedicated software as a common journey with the client, during which, striving for one goal, we get to know each other better, understand and support each other. The name “Software as a Journey” accurately reflects our way of working.

Recipe for the project’s success

Fortunately, the times when after months of working on documentation and implementation, the test stage finally revealed that no one remembers why and for whom most functions have been created, or that the system is no longer needed, are becoming a thing of the past.

We have described our work methodology, which has been proved in a wide range of projects, in the “Software as a journey” concept. Is it the best? We do not claim it is but we do confirm that it is effective.

Why? Because it assumes that the crucial element is understanding the real business purpose of the software being developed – in the same way and by all project participants; and then making sure that it is still valid and making any necessary adjustments. It is supported by the iterative approach, i.e. frequent and regular development and handover of finished smaller fragments of the system in the order corresponding to business priorities.

The effect? You start the project with a certain vision and the final product may be completely different. It is something you need right now, not something which seemed necessary in the beginning. That is why regardless of the pace of changes in the company’s market environment, portfolio or strategy, the system being developed will be useful and will bring the expected benefits.

How do you achieve that? By skillfully selecting appropriate tools, methods and project techniques at each stage of the development process. In “Software as a journey”, we offer a proven set of them which supports agile work methodology in the best possible manner. Depending on the project’s nature and complexity, you can use all the tools or any combination of them.

What benefits does such approach bring? How does it change particular stages of the development process? What impact does it have on the team and communication? Read more below.

Project goal

You probably know it from your own experience: “We have a problem. We need something, a system which will address it. You go to IT, which tells you: Make a list of your business requirements. We will work on it later. We will organize a tender procedure, collect proposals, meet selected providers.”

A provider is selected and the system implemented. However, in the meantime, the market, processes or regulations have changed. The people who defined the requirements no longer work at your company. New employees do not know the purpose of some of the functionalities while the really necessary ones are missing.

“Software as a journey” offers a different way. In the beginning, it is enough to define the purpose and the overall vision of the process. At an Event Storming workshop, business and IT departments and the provider, lead by an experienced facilitator, determine the course of a business process. Step by step (and actually – one piece of paper after another), subsequent events and dependencies appear on the wall. Stakeholders add examples and definitions of related business terms. This results in creating an overall vision of the system, the purpose and scope of which is understood in the same manner by everyone.

It is also an opportunity to build a “backlog”, i.e. a prioritized list of all tasks which should be performed at all project stages (sprints) to obtain the final product.

During the project, depending on the changing business environment, you can flexibly change priorities and scope of works to be performed in particular sprints – add new necessary functions or remove those which are no longer needed.

Timeframe and project budget

The backlog referred to above including a map of users’ stories (story mapping), which are particular system functions described from the user’s perspective in detail, give you an idea about the order of creating those functions and the time needed to develop them. This is the basis for estimating the general timeframe and budget.

The crucial item in that timeframe is the deadline and scope of developing MVP, i.e. the minimum version of working software. By handing over such basic product to its real users, you can quickly check if the system meets the requirements and see what is missing and what should be improved.

Such comments are immediately taken into account when working on next functionalities.

You can see on an ongoing basis what you receive in particular sprints as part of the initially estimated amount and you see whether it goes in the right direction. You can react and make changes at any time.

Cooperation – team and communication

Close cooperation between the ordering party and the system provider right from the start blurs the division between them and merges them into one team. Everyone feels responsible for success or failure. There are no scuffles or shifting the blame.

How is that possible?

The method of work which divides the project into smaller, usually 2–3 week sprints, sets the rhythm of meetings and interactions between the parties. Each new sprint is started by a planning session during which the parties together define the purpose and scope of works (backlog) for the coming weeks. When performing particular tasks, we describe the requirements in more and more detail. Their proper understanding is fostered by examples (e.g. calculations) and screen mockups which we construct in accordance with the rules of designing User Experience. A sprint ends with a presentation of a subsequent version of a more and more functionally rich, working software. Independent of that, short daily organizational meeting are held where the presence of both parties is recommended.

A particularly important role for the entire project’s quality and dynamics is played by the ordering party’s Product Owner, who should be present at every meeting and available for the development team, and take decisions in matters regarding the functional aspects of the system being built. Such involvement may take time but it translates into building exactly what is needed.

Frequent, regular contact and knowledge sharing merges the teams into one close-knit team carrying joint responsibility for the project’s success.

Observing work progress

The assurance that the project goes at the right pace in the right direction and the system works correctly results from the fact that software is being developed in an incremental way and tested automatically. Consequently, each subsequent system version is well tested, and may be implemented immediately (also automatically) and handed over to users. The opinions or reservations of the system users make it possible to react quickly and make the necessary changes and improvements.

Daily contact and regular sessions devoted to planning and demonstrating the software being developed show you the team’s pace of work. It increases over time, as stakeholders get to know each other’s possibilities and limitations and communicate more and more effectively.

With that knowledge, it is easier to monitor progress and forecast the cost of particular releases. The budget is kept under control. It is already after several sprints that you are able to quite precisely estimate the time and funds needed for next functional enrichments, which enables you to make informed business decisions.

Summary

Good software is one that fulfills business goals. One whose implementation will enable the business to say what has improved and to what extent, or what and how much the business has been able to save.

There can be many ways to creating such solution. “Software as a journey” is one of them. How do we know that? Because by working according to these principles, we successfully implement projects for our clients.

We make no bones about the fact that good software will be built only when it is created together, with the engagement of both parties; when the experience of the ordering party and the provider blend into new knowledge, shared by all stakeholders. Translating that knowledge into the programming language gives the result everyone wants – the product which the business needs at a given time.

Extracting knowledge and translating it into a working system is supported by our recommended techniques and tools. Today it is a set which supports agile approaches in the best manner, e.g.: Event Storming, User Story Mapping, Domain Driven Design  or Continuous Integration and Continuous Delivery. You will probably get to know some of them – we have mentioned them in the text. Others are just “hard” competences of a state-of-the-art software house. Business should be aware of their existence, but does not have to know them.

[su_spacer]

Elżbieta Con
Head of Marketing