I won’t bother you with the already 1000 times quoted story about the failure of projects due to bad planning, missing or insufficiently defined requirements, poor quality assurance, inadequate project employees, the use of the wrong technologies or last but not least the obsession of the central purchasing department to save money - with the associated consequences. The amount of resources that are consumed and the disappointment of project staff, customers, partners etc. that goes along with it is unacceptable. If you don't see this as a challenge, but as a "must live with" situation, then stop reading at this point. You are not my target group. Sorry. I want to change something and not missionize.
I would like to write about sustainability. About sustainability in product development, where resources have to be considered and put at the centre: I am not talking about people, even if they are often referred to abstractly as such resources, but about people's work and the invested lifetime of the people involved (both as project members and as customers), the technologies used, as well as our environment and the associated future. I would like to make every project a success or at least pave the way so that it can very probably succeed.
Every project starts with a challenge. The goal is to change something, to do something better. It is always about resources, people, environment and last but not least money. Perhaps even about power in all its variations and manifestations. Not always, but often. Someone sees this challenge and would like to have it solved, or accepts the challenge themselves and works towards a solution. This also applies to software projects. With those one wants to change the current status, no matter whether it is a replacement or a change of an existing system or the creation of a new one. One wants to master a situation anew. Innovation is the word. Even then, when the Cobol programs were created. With all software systems that I know, people are always affected: Either internally in the company as those who then have to work with it, or externally as customers, meaning those who pay to be allowed to work with it. Customers who have needs. If that's the case, why don't you involve people sufficiently and continuously so that what they get is what they want and can use successfully? We want to consistently pursue this approach for ourselves in order to always deliver exactly what our customers need in the end, while conserving resources. And to further develop us and our products and services together with the lives of our customers.
That's why we always first ask and question the customer's needs, define and test them. They provide us with validated requirements for our product, which we can define as a user story in our backlog. As a method we use the design sprints created by Google Ventures, which have been adapted, condensed and improved by many as well as by us. The client is involved in this phase and allows us to use the provided resources moderately and to involve people in an appropriate way. Nothing is duplicated and nothing superfluous is created. These validated, targeted results allow us to then move on to the next phase. Only when we know exactly what the customer wants does the development team know what it has to do to produce these results and, above all, to test them adequately according to the customer's needs. The customer accompanies the development and answers the asked questions, the team cannot take a wrong path. In the end, we have the functionality that the customer wants. In this constant iteration between customer and team, sustainability is created first and foremost.
After we have used this feedback ping pong often enough, we can confidently release the provided functionalities into the world as MVP (minimum viable product). This means that the product goes into production. This step also takes place in the company of the customer, who takes over all acceptance tests. Nothing comes onto the market that has not been defined, discussed and tested with the customer in detail beforehand. Everything in small steps. Agility in whatever form is the basis for customer proximity and resource awareness.
We call this constant iteration of design sprint, development and production to the next design sprint CustDevOps. The difference to BizDevOps from our point of view is that we don't have the business in mind, but the customer, and that this must therefore be part of the buzzword: From the business (biz) we direct the focus away from the customer (cust). The results of our design sprints provide very valuable, validated user stories for development. The close cooperation with the customer in the development phase and the close support in the production lead to the fact that a validated product is created in a way that saves resources and values people and their work. Nothing superfluous is created. Everything seems to be almost magical. Theoretically. But attention, we work with people and with technologies and last but not least with methods. The team must fit in with this way of working and live and love it one hundred percent. The team must act as a team. And the customer must also see themselves as part of the team. The successes must be celebrated and the mistakes must be corrected and learned from. There is a lot to be done! But it is feasible and you can approach it like we do. The results are promising.
trendig
