"Agile development is like teenage sex. Everyone says they’re doing it,
but only 10% are. And those who are – are doing it wrong"
– The Hacker Chick Blog
The above quote unfortunately describes the situation in many companies very accurately. Ever-shorter innovation cycles make decision-makers scream almost reflexively for the introduction of "agile methods". At its core, this reflex is reminiscent of Greenwashing, which was very popular a few years ago – that is, the adherence of a sustainable image, without aligning one's own actions and values.
Scrum (from English "scrum" for "the crowd") is perhaps the best-known representative of the agile working method. Here, the successful implementation of the framework hinges on three pillars: Transparency, Verification and Adaptation. Certainly, these pillars are elementary even with any other agile setting, even if they are not always called so directly.
But what are the mistakes that, despite the good will of all parties, make the implementation fail? What is certain is that changing the project manager's title to product owner is not enough and that the use of colored sticky notes on whiteboards does not lead to the desired results.
The so-called Minimum Viable Product, or MVP in short, is closely associated with the concept of agile methods. You quickly tend to see this term purely from the corporate perspective: What can I create and bring to market as a company with existing resources? It is particularly problematic when different feature scopes are already included in a phase plan and are provided with MVP 1, MVP 2, MVP 3, etc. After all: In reality, the MVP is about quickly validating the assumptions made by the company.
One of the best definitions for the MVP is provided by Jeff Patton:
"A Minimum Viable Product is the smallest thing you can do or create to make or refute an acceptance."
Agile work means learning iteratively and drawing the right conclusions from the lessons learned. It therefore does not make much sense to set the volumes for the third test in a waterfall-like manner without knowing the results of the first test. However, you should have already defined a specific goal image in the sense of a vision to be achieved at this stage. This is the only way to keep track of whether your product is developing in the desired direction across the different iterations.
The Minimum Viable Product is intended to help with the validation of the assumptions made to ensure that the later product actually meets the customer's expectations. The MVP aims to move the learning process along quickly and to conserve resources.
Often, however, the size of the MVP is too large. As a result, the company loses all the benefits of using MVPs. If the MVP is not accepted by the market, the company has already put a lot of precious resources into the product. And even if the product is positively accepted by the market, the question is whether it was really efficient or whether the same effect could have been achieved with fewer resources.
Therefore, start the design from the bottom up. Test whether the scope is sufficient to satisfy the customer's needs. If not, go for the next iteration. Or change the value proposition based on what you have learned using the last MVP. As a bonus you get highly motivated employees who generate actual increments at regular intervals.
Classic projects are often measured on the basis of the project management triangle. Then it looks like this: Someone writes a detailed specification and defines the scope of a project. Subsequently, it should then be realized in a given time and at predetermined cost. If these three parameters – scope, time and budget – are used for the incentive, the customer benefit is likely to remain on the track. The project manager may have completed the project "successfully" according to these criteria – but the produced product may still not be successful for a long time.
In the agile environment; however, the goal is to maximize customer value (for example, a product) with a given amount of time and a fixed team. It is only developed as long and to the extent that the customer benefit is relevantly magnified. Hence, the incentive has to be changed.
The successful introduction of agile methods stands and falls with the fact that uncertainties are simply part of the process. After all: The agile manifesto responds to (even unexpected) changes by following a plan. The fact is that we are moving in a complex environment in which more is unknown than is known.
The predictive security is optimized iteratively based on the knowledge gained in Scrum, for instance. If executives want their employees to have accurate information about which features will be implemented at what price in a year, they are undergoing this empirical approach. This merely obscures the existing uncertainty and creates a deceptive sense of security.
Even classic, waterfall-like change management projects suggest that the success of a specific measure can be realized within a specific timeframe. Again, the complex environment is ignored, although the reaction of complex systems is unpredictable.
Agile methods like Kanban accept existing uncertainty and help to respond to unforeseen effects through short-term adaptation as evolutionary change processes.
Many companies are reluctant to approach customers with an unfinished product to get feedback. Even if this principle is part of the methodology, as in the case of design thinking. Here's a statement we hear quite often: "Let's forget the prototyping with the customer."
The motives for this restraint are manifold: Some are so convinced of their own idea that they simply believe they don't need feedback. Others fear a negative impact on the image when approaching the customer with an imperfect solution. A third reason is the perceived lack of time for a feedback loop. Not only does this send devastating signals to the customer, it means you are going out on a limb with the product launch.
Be aware of where you are in the innovation lifecycle with your product. Go to the appropriate customer group to test your prototype. "Early adopters" will appreciate the inclusion in product development. The users of the mass market are not yet addressed at this point.
Agile is not in everyone's blood. Responsibilities and safety mechanisms learned from waterfall and classic organisational structures offer employees security and thus a comfort zone that lies in the nature of mankind to maintain. But especially in agile work this "intact" world of security and delegation of responsibility is often shaken due to the high speed of changes, adjustments and new priorities.
It is important to integrate the employees of a company into the agile process and to eliminate fears as well as to show new ways and opportunities that agility offers.
1 | BEING AN EXAMPLE
Just as in the education of children so in basic change programs: no preaching (or presentation with Powerpoint) is enough. The motto is to be a living example. This means that agility and the associated transparency should be demonstrated by the highest level of management, then gaining confidence in change will become easier and employees will take the new paths with less scepticism and more conviction.
2 | INCLUSION
Instead of hiding the employees, the employees should be involved in the change at an early stage. Time and again it becomes evident that conversations and concepts at management level are heard from floor to floor through the grapevine. There, with exclusion from the change process, reactances arise, which can under certain circumstances stir up a negative mood like an firestorm. Uncertainties and rejection are part of the change process, but can be taken up proactively by involving all employees and affected colleagues.
3 | METHODOLOGICAL COMPETENCE
The employee is familiar with the familiar world of work. Agile working methods, however, are new and different. In addition to the unfamiliar teamwork, the employee is confronted with rituals and methods that he must first learn – new rules and other cooperation models. The sooner a company starts introducing agile principles and promoting their implementation, the greater the acceptance of the agile procedure. The more consistently agile methods are taught, used and evaluated, the easier the new way of working succeeds. Successes can be experienced quickly and strengthen the feeling that agility is fun; for the team and everyone in the team.
4 | HOLISTIC
Agilization and the associated change process is a corporate issue. No separate department or project topic. If a classic process model is transferred to an agile one, the entire company and all departments are affected. Often business processes run through many areas and across various internal touchpoints. If only one department works agile, this will torpedo both upstream and downstream steps, just as this agile unit cannot really perform agilely, since it does not get the chance to develop agility through the influencing classical processes.
5 | ENCOURAGING
Where transparency is an indispensable basis, mistakes become visible and thus also the potential for growth. This requires courage and a positive and appreciative approach. Especially in phases of transformation, the new, the unknown raises question marks and gaps in knowledge. The more open these can be shown, the faster they can be clarified and used for improvements. Fail early; learn earlier. Encouraging is doubly worthwhile, because it allows committed employees to develop into committed employees.
We at diconium are firm supporters of agile approach models. Some rules have to be observed in order to exploit their potential. Experience has taught us that there are pitfalls and hurdles that come with the introduction of agile methods.
Following the motto "You never stop learning," we would like to start an open discussion on this topic. What mistakes did you make yourself; what lessons did you draw from them? What would you do differently in retrospect, what might have worked well?
Let us benefit from shared experiences – and discuss them under the hashtag #agilelearning with us and others.