Software development made easy
10 tips for optimisation of software development – a satire
Software development is a great field of activity. Good software brings products to life; watches become computers on the wrist, TV sets transform into online video stores and cars mutate into algorithms on wheels. Software is the air we breathe, it is engine and energy source in one. It’s good if companies know how to develop successful software. Better if they know how to optimise software development.
The trend towards a hyperagile approach
There is a whole range of methods and techniques for developing software. Numerous books, blogs and talks offer guidance and provide great ideas on what companies can do in different industries and settings. In recent years, an agile mindset has become prevalent and many organisations rave about speed benefits.
Of course, there are also critical minds that warn that agility is not appropriate everywhere, citing safety-critical infrastructures as an example. In a way, they are not wrong, but the direction is different: the trend is moving away from agile towards hyperagile. The agile approach is rule-intensive and not as fast as customers want. Speed is becoming the all-important competitive factor. And a hyperagile approach is pure speed, because it is based on almost-valid experience and many best practices.
A small example:
Do you know the question of “complicated or complex”? For a long time, it was considered an indicator for the choice of a suitable procedure in software development. In short, “complicated” postulates a challenge with numerous dependencies that companies are basically familiar with and can master over time by working in a structured way and using known methods. “Complex”, on the other hand, means situations where both client and contractor do not know exactly where the journey is going, what equipment makes sense and what all will come up on that journey. Much is ambiguous, volatile and uncertain.¹
It is easy to infer from this statement that customers do not know what they want. Somewhat surprisingly, this presumptuous insight does not go down well with many clients. A clear vision and a creative value proposition are clearly more purposeful here. And hyperagile software development promises exactly such an approach, suitable for both complicated and complex projects.
Software development on the verge
The hyperagile approach puts constructs to the test that are established in agile software development but offer no real benefit, or that promise more benefits than generally assumed. Below are 10 tips for optimisation of software development:
#1 Stakeholder management
Stakeholder management addresses the targeted, continuous engagement of a company with its stakeholders. Let’s be honest: “with its stakeholders”? How much input do organisations need to develop software? In real life, it is often enough for the development department to talk to the managing director or owner of the company, because he or she knows what customers want today and also tomorrow, simply because of his or her successful past!
Of course, responsible employees can also talk to one or the other stakeholder, but nobody needs more than three opinions when it comes to the content of a software to be developed. In addition, the concentrated exchange facilitates the subsequent achievement of goals, it reduces the communication effort and the requirements are almost automatically in scope.
#2 Requirements
Speaking of requirements. Requirements are important for successful software development. However, since they change regularly and new ones are also added, which are always more important than existing ones and of course have to be implemented immediately, it is not worth specifying all requirements. Customers demand flexibility and internally a climate of changing direction at short notice is needed. This is exciting and varied. To be on the safe side, the prioritisation of requirements should therefore also be adjusted.
#3 Prioritisation
The MoSCoW method is a well-known prioritisation procedure for evaluating requirements. It knows four categories – Must, Should, Could and Won’t – but this is clearly too extensive. Much more efficient is a two-level classification, which only knows Must and Won’t. There are already calls to directly omit the Won’t category as well. This would mean that there would only be “must requirements”, which is already the status quo in many organisations today. And this would also eliminate the need for prioritisation. Great, isn’t it?
#4 User stories and use cases
User stories and use cases – or use case stories for friends of Use Case 2.0 – are well-known tools for understanding the perspective of users. “As a centre forward, I want to have the ball passed to me in such a way that I can easily score a goal” – the wording of such sentences is so simple that people involved are underwhelmed by it. It is a value of hyperagile software development that stakeholders are not treated like beginners. The customer perspective is important, but the satisfaction of the employees is more important in case of doubt. In practice, keywords and verbal agreements are often sufficient.
#5 Overengineering and gold plating
Have you ever heard of overengineering or gold plating? If not – it doesn’t matter, because both terms address nothing more than the exaggerated concern about features that customers do not expect – because they were not specified – but later learn to love. Basically, any service that goes beyond a described scope of services – e.g. in the form of a customer specification – is considered gold plating. A customer specification? That’s really old work and doesn’t fit at all with the hyperagile development of software. Surprise your customer, he oder she will most likely be happy about it.
#6 Prototyping
One construct that has no place in a hyperagile approach is prototyping. Experienced software developers can save prototyping by really listening to clients. This is easy and promotes a natural exchange between client and contractor. Recently, the term pretotyping has been heard more often in companies, but the mere fact that the term is almost unpronounceable shows the insanity of the underlying idea. And since we want to be honest: why test an idea extensively if you are convinced of it?
#7 Banana principle
There is a whole range of practices that organisations can save themselves in the course of software development: Tests and reviews, all considerations of clean code, generally working with UML or SysML models, or an elaborate architecture design – the list can be extended indefinitely.
Individually developed software is allowed to mature on site – at the customer’s premises. After all, the banana principle is not only useful for bananas.
#8 Knowledge and quality across the board
Hyperagile software development is based on quality, willingness to perform and the experience of software developers. What is the fastest way to build experience? By having every member of the development team learn as many techniques as possible. Although no one masters a subject area in detail, the team is well positioned in terms of breadth.
Many clients are also happy to have changing contact persons. Here it helps to establish a rolling system within the company so that salespeople can also take part in pair programming or new students can carry out code reviews independently. Trust is the magic word here.
#9 Feedback in a nutshell
What is the biggest advantage of agile software development? The long answer is: short feedback cycles. Unfortunately, these are very exhausting and often take clients out of their daily business. Here it is better not to overwhelm clients, and instead deliver short management summaries by email or ideally by phone. Feedback 4.0 is capitalised in the hyperagile approach.
#10 Temporary estimates
And last but not least: No customer expects a release from a supplier or manufacturer on a pre-announced date. Those who keep such commitments to schedules have usually reduced the amount of new features and customers register this.
The behavior is similar with deadlines from customers, because these are often only requests for dates that can be postponed by one or two person-months, especially if customers have already been waiting a very long time for promised features. Release dates and deadlines are merely temporary estimates, nothing more, nothing less.
Conclusion
The future belongs to hyperagile software development. It is much more flexible than an agile approach. In many companies, the trend is already being used – perhaps unconsciously – and filled with life. Presumably, many other constructs from the past of software and product development will be put to the test in the future. A lot will change – beautiful, hyperagile world!
Notes:
If you like the post or want to discuss it, feel free to share it with your network.
[1] VUCA is the term for a rapidly changing business world and the challenges it poses for companies.
This was a satire. I don’t want to recommend any of this in real terms for your software development.
Michael Schenkel has published more articles in the t2informatik Blog, including
The best process in requirements management
Eliminating requirements
The “why” in requirements engineering
Michael Schenkel
Head of Marketing, t2informatik GmbH
Michael Schenkel has a heart for marketing - so it is fitting that he is responsible for marketing at t2informatik. He likes to blog, likes a change of perspective and tries to offer useful information - e.g. here in the blog - at a time when there is a lot of talk about people's decreasing attention span. If you feel like it, arrange to meet him for a coffee and a piece of cake; he will certainly look forward to it!