Software development made easy

by | 04.04.2019 | Software development | 0 comments

Software development is a great field of activity. Good software brings products to life; watches become computers on the wrist, TV sets turn into online video libraries, and cars mutate into algorithms on four wheels. Software is our new air to breathe, it is engine and energy carrier in one. It’s good when companies know how to develop good software. Better if they know how to optimize software development. A parody.

Hyperagile procedure

There is a whole range of methods and techniques for developing software. Numerous books, blogs and lectures provide orientation and great ideas on what companies in different industries and settings can do. In recent years, an agile mindset has prevailed and many organizations rave about the speed advantages. Of course, there are also always critical minds who admonish that agility is not appropriate everywhere and then mention, for example, safety-critical infrastructures, autonomous driving or the construction of complex systems consisting of hardware and software. In a way, they are not wrong, but the direction is different: the trend is away from agile to hyperagile. The agile approach is rule-intensive and not as fast as customers want. Speed is becoming the most 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 “complicated or complex”? For a long time it was regarded as an indicator for the choice of a suitable approach in software development. In short, “complicated” postulates a challenge that companies are basically familiar with and that they can overcome over time by working in a structured manner and using familiar methods. Complex, on the other hand, means situations in which both the client and the contractor do not know exactly where the journey is going, what equipment makes sense and what will happen on that journey. It is easy to deduce from this explanation that clients do not know what they want. This is very presumptuous and does not go down well with most clients. A clear vision and a creative value proposition are much more goal-oriented. And hyperagile software development promises exactly the right approach for both complicated and complex projects. In addition, it also puts numerous designs that have been used in recent years to the test, but which offer no real benefit. Here is a selection:

The top 10 of modern software development

Stakeholder management addresses the targeted, continuous engagement of a company with its stakeholders. Let’s be honest: “with its stakeholders”? How much input do you need for your software development? In practice, it is often enough for the development department to talk to the managing director or owner of the company, because he knows what customers want today and tomorrow simply from his successful past! Yes, of course you can also talk to one or the other stakeholder, but nobody needs more than three opinions when it comes to the strategy and orientation of the software to be developed. In addition, the concentrated exchange facilitates the later achievement of objectives, reduces the communication effort and the requirements are almost automatically within the scope.

Speaking of requirements. Requirements are very important for successful software development. However, since they change regularly and new requirements are added, which are always more important than existing ones and must of course be implemented immediately, it is not worth specifying all requirements in detail. Customers demand flexibility and internally a climate of short-term directional change is needed. This is exciting and varied. To be on the safe side, the prioritisation of requirements should therefore also be adapted.

The MoSCoW method is a well-known prioritisation procedure for assessing requirements. It covers 4 categories – Must, Should, Could and Won’t – but this is clearly too extensive. Much more efficient is a two-stage classification, which knows only must and won’t. There are already some voices that would like to omit the second categories and consequently the documentation of corresponding requirements. Thus there would be only “must requirements”, which in an optimal and rational world could logically then also be omitted, but to work completely without requirements with no priorities is then still too radical for many organizations. On the other hand: the world is owned by the brave.

User stories and use cases – or use case stories for the friends of Use Case 2.0 – are well-known tools for understanding the user perspective. “As a middle forward, I want to get the ball passed to me in such a way that I can easily score a goal” – the formulation of such sentences is so simple that all those involved are underchallenged. It is a value of hyperagile software development that all developers are not treated like beginners. The perspective of customers and users is important, but the satisfaction of one’s own employees is more important in case of doubt. To be on the safe side, companies should therefore not specify the system context at the start of development, as this is also obvious. And if there are changes in the course of the project, then that’s just the way it is, after all, the customer is king.

Have you ever heard of overengineering or gold plating? If not, it doesn’t matter, because both terms don’t address anything other than the exaggerated worry about features that the customer doesn’t expect at the beginning – because he didn’t specify them – but later learns to love them. Basically, every service is considered gold plating, which goes beyond the described scope of services – e.g. in the form of a specification sheet. A requirement specification? This is really old work and doesn’t fit into the agile world of documentation at all.

Another construct that has no place in a hyperagile procedure is prototyping. As an experienced software developer, you can avoid prototyping by listening carefully to your customer. This is simple and promotes the natural exchange between client and contractor. Recently, the term “pretotyping” has come up more often in companies, but the fact that pretotyping is almost unpronounceable alone shows the insanity of the underlying idea. And since we want to be honest: why should you test an idea if you are convinced of it?

What is the biggest advantage of agile software development? The answer is: short feedback cycles. Unfortunately, these are very exhausting and often tear the client out of his day-to-day business. It is better if you don’t overtax him and sometimes just deliver a short management summary by e-mail or even better by phone. You may need some experience to do this, but you and your colleagues will be able to gather it quickly.

Speaking of experience. The quality of a software development depends directly on the skill, motivation and experience of the software developers. Quality is often the result of experience. And what is the quickest way to build experience? Each member of your development team learns as many techniques as possible. Although nobody masters a subject area in the very last detail, you are very well positioned in terms of depth. Maybe you need to convince your clients to recognize the advantages in changing contact persons. Don’t hesitate, it’s worth it. And if you also establish a rolling system internally, so that a sales representative can sometimes take part in a pair programming, or a freshman student independently conducts a code review, then you are on a very good path. You have to believe in it, then it will work out.

There are a number of practices that you can save in the course of your software development: Tests and reviews, any code coverage considerations, working with UML or SysML models in general, or an elaborate architectural design – the list can be extended at will. If you don’t burden your clients with prototypes or short feedback cycles, they will most likely be happy when the software matures on site. After all, the banana principle does not only make sense with bananas. Of course, hyperagile software development requires a certain amount of communication, but you can compensate for any dissatisfaction by changing contact persons. Young employees particularly stand a good chance here, and since they can learn a great deal in such situations, it automatically becomes a win-win situation.

And last but not least: don’t worry too much about promises. No one expects a tool manufacturer to release a tool on a preannounced date. Those who meet such deadlines have usually reduced the amount of new features and customers register this. The situation is similar with the deadlines set by customers, because these are often only requests that can be postponed by one or the other man-month, especially if the customer has been waiting a long time for a promised feature. To be on the safe side, you should create a very comprehensive changelog in which each option of a function is shown in detail – preferably with the help of a screenshot.

Best Practices are better than Good Practices

How long has your company been on the market? One year, five years, 20 years? Of course, a long existence is no proof of how well your company will work in the future. But it is definitely a sure indicator that much was right in the past. If you take ten minutes to reflect on your company’s success factors, you may also find that there are best practices that are better than just good practices – a fool who claims otherwise – and that are like a blueprint for many customers and projects. Perhaps it helps if instead of a compact benefit argumentation you first present the internal work structure with the division of the areas – e.g. Business Intelligence, Business Analysis, Project Management, Requirements Engineering, Web-Development as well as Frontend and Backend Development – on your website. It’s important for customers to understand how you work, probably even more important than the benefits you can deliver.

One last thought: have you already gained experience with your own manifesto? Publishing a manifesto on your website is very professional for most customers. If you use version numbers in combination with the title, your customer will know at a glance that you are evolving as an organization. Let’s just do a quick test: How does “Software development made easy 2.0” look to you?  

 

Note:

This was a parody. I don’t really want to recommend any of this for your software development. If you are interested in serious and detailed backgrounds, e.g. on stakeholder management, dealing with requirements and prioritizing with the MoSCoW method, working with user stories, use cases and use case 2.0, on the consequences of overengineering and gold plating, on the creation of requirement specifications, on the development of prototypes or pretotypes, or working with best or good practices, etc., please take a look at our Smartpedia section.

Michael Schenkel
Michael Schenkel

Head of Marketing, t2informatik GmbH

Michael Schenkel is a graduate business economist and is passionate about marketing. He has a certificate for excellent hiking characteristics, Odenwaldtour in classes 6a/6b and since 1984 the Seahorse. He likes to blog about requirements engineering, project management, stakeholders and marketing. And he will certainly be delighted if you meet him in the real world for a cup of coffee and a piece of cake or for a virtual get-together.

Share This