SoDa Software Development Agile is a homebrew project development method created at the technical university of Lucerne. It is a mixture of Waterfall, RUP and Scrum approaches. It uses a distorted Scrum for the concept and implementation phase[2].
The documentation was not updated the last ten years. The approach is clinically dead and should not be promoted for active software development efforts.
A similar approach exists with the official governmental Swiss project method HERMES. At least the documentation of HERMES is better than SoDa.
Both approaches are quite similar. They mix a phase-based Waterfall approach with the four phases of the old RUP project life-cycle approach. RUP belongs to the family of unified process methods.
The four phases or gates are [1]
approximate vision, business case, scope, and vague estimates.
refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates.
iterative implementation of the remaining lower risk and easier elements, and preparation for deployment.
beta tests, deployment.
If you are using DevOps approaches, you certainly do not need an inception or a transition phase.
These approaches are obsolete. Almost no industrial service companies are explicitly using Waterfall or unified process approaches.
For most of these organizations that take a hybrid approach, this is an interim step. They intend to gradually expand their agile activities beyond the development and testing stages to the rest of the software development lifecycle.
If you are forced to use a hybrid method in Switzerland, please use Hermes. Never try to use SoDa. It is obsolete and sparingly documented.
If you want to be a professional developer, please use an agile approach. Scrum is currently the most used agile approach in the industry.
HERMES fulfills the current requirements of federal and state administration.
They are mainly organized hierarchically and have to handle projects taking governance into account.
The major problem is that Hermes is mandatory for a set of governmental projects. You are forced to use this method as a software company if you want to work on some government initiatives [2].
The method is Swiss and completely unknown in Europe or abroad. Swiss commercial or industrial software development initiatives never use Hermes as a development approach.
In his mind-expanding book The Beginning of Infinity, physicist David Deutsch describes science and enlightenment as the quest for good explanations. He explains how various ideas in human history represent a beginning of infinity that allows us to cope with any conceivable relevant application of these good explanations.
This idea of infinite reach or scope is true of an agile approach to development and not true of a waterfall-based approach.
An agile approach to software development encourages us to start work on solving problems in smaller pieces. It encourages us to begin work before we know the answer to everything. This approach allows us to make progress, maybe sometimes in suboptimal or even bad directions, but nevertheless, after each step, we learn something new.
This does not mean that agile thinking is perfect or the final answer. Rather, it is an important, significant, enabling step in the direction of better performance.
|
The software product development method war is won. Agile approaches as described in Agile Manifesto and Scrum are the winners [3]. Eighty percent of all new software development initiatives are based on an agile approach. The most used agile approach is Scrum. Stop being a laggard. Start using agile approaches and the Scrum framework. |
I strongly advocate discarding all hybrid methods. No empirical evidence is available showing these methods can be applied successfully. Anecdotal evidence shows that they regularly fail.
We shall use the Scrum approach as a preferred approach for developing software application [1, 2, 3]. Scrum and various Scrum scaling frameworks provide approaches for teams of up to eighty developers working on the same product. I strongly state that 99.9% of all software initiatives have smaller teams.
| One of the founders of Scrum strongly stated the same in a famous post Unsafe at any Speed. |
I strongly recommend avoiding SAFe for the following reasons:
SAFe is complex and less agile. It contains waterfall elements. Their approach to software architecture is outdated and does not reflect the findings of OpenGroup, the steward of TOGAF.
Agile release trains should align teams to a shared business and technology mission. The ideal size of a train is between 50 and 125 people working on the same product family. Most product development initiatives are smaller. ALl members of a train shall work on the same products. Using the same technology stack is not a criteria to belong to the same train.
SAFe is not based or using Scrum. Their definition of Scrum master and product owner is different to the ones in Scrum. Their key roles of a release train engineer RTE and product management do not exist in Scrum. They are more traditional project management roles. All synergy effects are lost. You must retrain your collaborators into SAFe if you go down this path.
The planning and release cycle is a program increment. The duration is typically 8 to 12 weeks long. This is too long for agile, DevOps, or Design Thinking approaches.
If you have a choice, do not use any hybrid method. Various studies found out that agile initiatives are three times more successful than Waterfall approaches.
Business agility is not compatible with hybrid approaches. Use Lean startup or design thinking frameworks to increase your business agility and adapt to market changes. Design thinking advocates iterations of one week duration. Therefore, product increments of three months or worse and RUP phases over half a year are truly incompatible with weekly cycle-time.
We train our students and collaborators in Design Thinking, Lean approaches, and Scrum framework. We should not force them to use later obsolete methods such as V-Model, RUP, HERMES or unsupported approaches such as SODA.
|
Advocate the agile manifesto and the twelve principles behind the manifesto. |
The majority of hybrid methods I still encounter are bad rehearsal of the RUP development approach. The unified process was defined in the nineties and is now obsolete.
[2] Detecting Agile Bullshit. Marcel Baumann. 2019
[3] Scrum Master Formation. Marcel Baumann. 2021
[4] Product Owner Formation. Marcel Baumann. 2021
[5] Scrum Developer Formation. Marcel Baumann. 2021
[6] Scrum Guide. Jeff Sutherland, Ken Schwaber. 2020
[7] Cargo Cult. Wikipedia
[8] DevOps for Small Applications. Marcel Baumann. 2021
[9] Advocate Zero Bug Policy in Your Projects. Marcel Baumann. 2020
[10] What I learnt Teaching Agile Software Architecture. Marcel Baumann. 2021
[1] F. Heath, Professional Scrum Master Guide. Packt Publishing, Limited, 2021 [Online]. Available: https://www.amazon.com/dp/1800205562
[2] D. McGreal and R. Jocham, The Professional Product Owner. Addison-Wesley Professional [Online]. Available: https://www.amazon.com/dp/B07D5ZPJBY
[3] S. Ockerman and S. Reindl, Mastering Professional Scrum. Addison Wesley, 2019 [Online]. Available: https://www.amazon.com/dp/B07XTLNPTC